[Ubuntu 10.04 server] DVD-speler niet fysiek te verwijderen

[Robkazoe]

Ik heb hier een server staan waarop ik Ubuntu 10.04 server (64 bits versie) wilde installeren. Ik had eerst de image gedownload en wilde deze installeren via een USB-stick op de SSD-schijf. Dus ik had via pendrivelinux.com het programma gedownload om een bootable USB-stick te maken. Telkens bleef hij hangen op de "CD-ROM" check die hij voor het installeren uitvoerde.

Ik besloot om de software maar via een CD-RW te branden een DVD-speler uit mijn huidige computer aan mn server te koppelen. In mijn server komen vijf harde schrijven te hangen en voor het installeren heb ik een harde schijf ontkoppeld en de kabels gebruikt voor de DVD-speler. Het installeren is gelukt en Ubuntu draait ondertussen prima.

Toen wilde ik het systeem uitschakelen, stroom eraf halen en de DVD-speler eruit halen. Dus de SATA-kabel eruit gehaald en stroom ontkoppeld en het systeem opnieuw opgestart. In het BIOS is geen DVD-speler meer bekend. Maar bij het opstarten blijft hij opeens hangen: "alert! /dev/sdd1 does not exist. Dropping to a shell." En dat is nogal een vreemde melding want /dev/sdd (de harde schijf waarop Ubuntu Server staat) is wel gewoon aanwezig. Duw ik vervolgens de SATA-stekker en power-kabel in mijn DVD-speler + reboot, dan boot het systeem gewoon weer netjes alsof er niets aan de hand is.

Blijkbaar staat er nog ergens een verwijzing naar de DVD-speler en dat blokkeert het systeem. In de /etc/lilo.conf (bootmanager) kan ik geen verwijzing vinden naar de speler. Ook /etc/fstab kan ik niets over een DVD-speler vinden. Waar zou ik nog meer kunnen kijken of er een verwijzing naar staat?

Ik heb al op Google zitten kijken maar als je met dit soort zoekopdrachten of dit aankomt, dan krijg je veel verhalen te horen hoe je spelers moet mounten, unmounten, schijfjes die niet gepakt worden en regio vrije spelers maar niet over het daadwerkelijk fysiek verwijderen van een speler. Kan iemand mij hier op weg helpen?

[Freedom]

als de dvd-speler een sdX naam had die lager lag dan sdd kan het zijn dat /dev/sdd automatisch is hernoemd naar iets anders, dus wellicht moet je in lilo.conf de bootschijf aanpassen.

[MacGrumpy]

Normaal werkt ubuntu met UUID voor de harddisk. (misschien met server niet)

De truuk is, als je in de shell bent in dmesg controleren wat nu het device node van de harddisk is.
fstab aanpassen, en reboot (en).

Vervolgens kan het handig zijn om even te zoeken naar een guide hoe je dit kan aanpassen naar UUID's.
Ik heb zelf een server die bij iedere opstart de IDE controllers in andere volgorde vind. (sommige zitten op pci kaart). Hier heb ik ook alles doormiddel van UUID's moeten regelen om niet gek te worden.

[Robkazoe]

Daar had ik natuurlijk nooit aan gedacht. De schrijfletters zijn waarschijnlijk allemaal eentje opgeschoven. Ik ga vanavond hier meteen mee aan de slag. Bedankt voor deze informatie.

[Hero of Time]

Mocht je je server ooit eens opnieuw installeren, kan je je stick bootable maken en als je er ook nog op kan schrijven, de ISO erop laden. Deze ISO kan je later namelijk als installatie source gebruiken. Voordat Ubuntu namelijk kijkt naar je CDROM, kan je een ISO laden. Je dient wel naar Expert Mode te gaan (via F6 bij 't keuze menu).
Je kan ook naar een TTY gaan voor de installatie en de stick op /cdrom of /media/cdrom mounten. De installer zou dan gewoon door moeten gaan.

[Robkazoe]

Ondertussen weer wat dingen gedaan maar nog steeds niet heel veel verder gekomen.

Het probleem wat ik hierboven bescheef is met een aantal reboots op te lossen. Dat houdt in dat waarschijnlijk met stom geluk de juiste schijf de juiste letter toegewezen krijgt en dan boot hij wel normaal. Ik kan dan inloggen en alles doen en laten wat ik wil. Herstart ik de server opnieuw, dan moet ik maar weer met gods gratie hopen dat de juiste letter wordt toegewezen aan mijn SSD met Ubuntu server erop. Ik besloot mijn overige vier harde schijven maar eens te partitioneren. Als dan de SSD niet de juiste letter meekrijgt, krijg je nog meer foutmeldingen want hij kan mappen niet vinden (raar als je op een lege harde schijf kijkt).

Nu heb ik mijn harde schijven weer leegegooid en ben weer opnieuw begonnen met de installatie van Ubuntu Server. Dit keer lukte de USB-installatie wel in een keer. Dus ik dacht verlost te zijn van mijn SDA = DVD-ROM speler verhaal. Maar nu ziet hij mijn USB ook aan als schijfbaar geheugen en wat kent hij toe? Juist SDA.

Al met al word ik doodongelukkig van Ubuntu Server. Ik heb de installatie nu al 25 keer doorlopen denk ik (met de installatie's van Debian erbij) en het werkt nu nog niet zoals het hoort te werken. Ik heb een aantal vragen en ik hoop dat jullie die kunnen beantwoorden:

- Waarom pakt Ubuntu tijdens het booten de dobbelstenen erbij om te bepalen welke schijf welke letter krijgt? Je zou juist verwachten dat "serversoftware" juist niet variabel wilt zijn maar stabiel en berekenbaar.
- Werkt de GRUB bootloader uberhaupt wel? Ik heb de LILO variant meerdere keren al aan de praat gekregen maar met GRUB werkt hij niet.
- Is mijn werkwijze wel juist?

Het volgende rideltje heb ik nu telkens gedaan:
- Ubuntu installeren
- Tijdens installatie proces LILO geinstalleerd ipv GRUB (valt weinig aan in te stellen).
- Naast LILO ook meerdere malen GRUB geinstalleerd. Dit automatisch laten doen of handmatig en dan plaatsen op /dev/sd($drive-letter waar mijn SSD net aan toegekent is).
- Is het misschien verstandiger om al mijn harde schijven behalve de SSD te ontkoppelen en later pas toe te voegen? Of blijf ik dan het probleem houden van de variabele letters toekennen van Ubuntu/linux?

Ik hoop dat jullie mij hiermee kunnen helpen. Ik had verwacht dat Linux niet zo makkelijk zou zijn als een Windows-installatie. Maar dat het zo moeilijk en ingewikkeld is...

[Crakie]

Volgens mij ligt het probleem niet zo zeer bij Ubuntu, maar bij je Bios. Ik heb precies hetzelfde gehad, met verschillende distro's. Wat bij mij hielp, was de bootvolgorde van de harddisks aanpassen. Dus niet bootvolgorde van hd, cdrom, floppy, etc, maar echt de hd's zelf. Zet je SSD op 1, zeg maar.

[DeKaerften]

Ik weet niet hoe het zit met LILO (LILO wordt gezien als verouderd en alleen te gebruiken in het geval GRUB echt niet aan de praat te krijgen is), maar met GRUB kun je gewoon UUID's gebruiken, zoals MacGrumpy ook al aangaf.

De makkelijkste manier om dit probleem te verhelpen is door met UUID's te werken in plaats van device nodes. In tegenstelling tot device nodes zijn UUID's namelijk statisch per partitie. Als je eenmaal je configuratie zo ingesteld hebt dat je UUID's gebruikt om bootschijven aan te geven heb je nergens meer last van.

[Robkazoe]

Crakie schreef op woensdag 11 augustus 2010 @ 10:12:
Volgens mij ligt het probleem niet zo zeer bij Ubuntu, maar bij je Bios. Ik heb precies hetzelfde gehad, met verschillende distro's. Wat bij mij hielp, was de bootvolgorde van de harddisks aanpassen. Dus niet bootvolgorde van hd, cdrom, floppy, etc, maar echt de hd's zelf. Zet je SSD op 1, zeg maar.

Die volgorde heb ik al aangepast.
Heb bij bootable devices enkel de SSD staan en de rest gedisabled. Hij kan dus nooit een andere schijf pakken.

GuitarWeed schreef op woensdag 11 augustus 2010 @ 10:23:
Ik weet niet hoe het zit met LILO (LILO wordt gezien als verouderd en alleen te gebruiken in het geval GRUB echt niet aan de praat te krijgen is), maar met GRUB kun je gewoon UUID's gebruiken, zoals MacGrumpy ook al aangaf.

De makkelijkste manier om dit probleem te verhelpen is door met UUID's te werken in plaats van device nodes. In tegenstelling tot device nodes zijn UUID's namelijk statisch per partitie. Als je eenmaal je configuratie zo ingesteld hebt dat je UUID's gebruikt om bootschijven aan te geven heb je nergens meer last van.

Ik had al door dat LILO verouderd was maar itt GRUB werkte hij vaker wel. Maar hoe zou ik GRUB aan de praat kunnen krijgen? Als ik hem automatisch installeer, dan blijf ik tijdens het booten met een zwart scherm en een knipperend _ hangen? Handmatig installeren op bv /dev/sdb pakt hij ook niet (als op dat moment de /dev/sdb verwijst naar de SSD). En erg veel instellen kun je niet tijdens de installatie dus ik snap niet zo goed wat er fout kan gaan en wat ik fout doe.

Ik zal sowieso aan de slag gaan met het UUID verhaal. Al zou het dan wel handig zijn als mijn bootloader het doet.

[ Voor 3% gewijzigd door Robkazoe op 11-08-2010 10:44 ]

[DeKaerften]

Als je een knipperende cursor krijgt na het booten, betekent dat dat je eerste bootdevice geen grub bevat. Dit kan komen doordat grub niet geïnstalleerd is of doordat de device waarop grub geïnstalleerd is niet als eerste bootdevice staat.

Dit laatste kan dan weer komen doordat grub niet op het door jou gewenste device is geïnstalleerd of dat je boot-device volgorde niet staat op een dusdanige manier dat de bootpartitie als eerste voorbij komt.

Welke opties kies je allemaal tijdens de installatie van grub? Misschien dat we daar nog iets aan kunnen zien.

[Robkazoe]

GuitarWeed schreef op woensdag 11 augustus 2010 @ 14:20:
Als je een knipperende cursor krijgt na het booten, betekent dat dat je eerste bootdevice geen grub bevat. Dit kan komen doordat grub niet geïnstalleerd is of doordat de device waarop grub geïnstalleerd is niet als eerste bootdevice staat.

Dit laatste kan dan weer komen doordat grub niet op het door jou gewenste device is geïnstalleerd of dat je boot-device volgorde niet staat op een dusdanige manier dat de bootpartitie als eerste voorbij komt.

Welke opties kies je allemaal tijdens de installatie van grub? Misschien dat we daar nog iets aan kunnen zien.

Zoals eerder aangegeven heb ik een harde schijf in de boot sequence staat en dat is mijn SSD welke Ubuntu bevat. Als je GRUB standaard installeert (de automatische optie), dan zag ik snel voorbij flitsen dat hij dat doet op /dev/sda. Nu was dat in mijn geval de USB stick dus daar was ik niet erg blij mee. Toen stond Ubuntu op de /dev/sdb schijf. Haal je de USB weg, dan start hij dus niet op.

Toen ik Ubuntu daarna opnieuw installeerde, stond de SSD op /dev/sdd. Toen had ik bij GRUB gekozen voor manual installation. Dan kun je een pad opgegeven waar je hem op wilt plaatsen. Daar vulde ik netjes /dev/sdd in en na een reboot knalde hij alsnog op het zwarte scherm met het knipperende _ teken. Dus dat leek ook niet te werken.

Heel veel meer kun je dan niet instellen bij de standaard installatie. De expert-installatie heb ik nog niet gebruikt.

[Robkazoe]

Er is witte rook uit de schoorsteen gekomen (en gelukkig niet uit mijn computer).

Gisteravond een nieuwe installatie van de server gedaan met slechts drie harde schrijven erin (twee andere schijven zijn losgekoppeld). Installatie uitgevoerd op de SSD (/dev/sdb1 partitie) en GRUB geinstalleerd handmatig op /dev/sdb. Na een herstart pakt hij in een keer het inlogscherm.

De overige twee harde schijven in EXT4 geformateerd en gemount op /mnt/raidhd1 en /mnt/raidhd2. Vervolgens in /etc/fstab de UUID toegevoegd, de mountpunt en de variabelen (defaults) en na een herstart werkte alles. Af en toe een configuratiefout gemaakt in /etc/fstab maar hij bootte altijd wel als eerste op de SSD.

Het duurt even maar dan heb je ook wat. Ik dank jullie allemaal voor de hulp. Vanavond de overige twee harde schijven terugkoppelen, formateren, mounten en opnemen in /etc/fstab. Dan maar eens kijken of RAID5 draaiend te krijgen is.

[deepbass909]

Mooi dat het opgelost is, maar ik blijf het wat vreemd vinden. De sATA poorten zijn als het goed is gewoon hardware matig genummerd. Je boot-schijf hang je normaal gesproken op de poort met het laagste nummer, en die krijgt dan normaal ook sda toegewezen. Het lijkt er bij jou juist op dat je BIOS rare dingen doet...

Verder kan naast UUID's, ook gebruik maken van labels in grub. Dat werkt nog makkelijker (geen moeilijke lange strings), al is het installeren van Ubuntu dan iets lastiger, want de standaard schijfindeling gebruikt geen labels (maar deze kan je achteraf altijd nog toevoegen of wijzigen met bijv. tunefs).

[Hero of Time]

deepbass909 schreef op donderdag 12 augustus 2010 @ 16:25:
Verder kan naast UUID's, ook gebruik maken van labels in grub. Dat werkt nog makkelijker (geen moeilijke lange strings), al is het installeren van Ubuntu dan iets lastiger, want de standaard schijfindeling gebruikt geen labels (maar deze kan je achteraf altijd nog toevoegen of wijzigen met bijv. tunefs).

Ligt er aan. Als je de guided partitionering gebruikt niet, maar doe je 't handmatig, dan kan je al direct labels laten aanmaken e.d.

[Robkazoe]

deepbass909 schreef op donderdag 12 augustus 2010 @ 16:25:
Mooi dat het opgelost is, maar ik blijf het wat vreemd vinden. De sATA poorten zijn als het goed is gewoon hardware matig genummerd. Je boot-schijf hang je normaal gesproken op de poort met het laagste nummer, en die krijgt dan normaal ook sda toegewezen. Het lijkt er bij jou juist op dat je BIOS rare dingen doet...

Verder kan naast UUID's, ook gebruik maken van labels in grub. Dat werkt nog makkelijker (geen moeilijke lange strings), al is het installeren van Ubuntu dan iets lastiger, want de standaard schijfindeling gebruikt geen labels (maar deze kan je achteraf altijd nog toevoegen of wijzigen met bijv. tunefs).

Ik had gisteravond mijn twee overige harde schijven toegevoegd aan het systeem. Raad eens welke letters ze meekrijgen? SDA en SDB. Mijn SSD-schijf met Ubuntu Sever was nu op SDE te vinden. Eén voordeel is wel dat door GRUB, de juiste boot-sequence en /etc/fstab dat het booten nu altijd wel lukt. Dus daar ben ik al blij mee.

Waar het nu precies aan ligt, weet ik niet. Ik vermoed aan mijn moederbord. Tijdens de POST en het BIOS-opstarten zie je de harde schijven wel voorbij komen. Je ziet dat de SSD gekoppeld is aan de eerste SATA-poort. Maar blijkbaar stuurt het systeem een commando als: Wake-Up SATA harddrive *. Vervolgens sturen de harde schijven allemaal een signaal en is de SSD langzamer dan de overige schijven. Zoiets vermoed ik.

Maar mede dankzij UUID werkt nu alles goed. Moet niet vergeten dat mocht ik ooit een schijf aanpassen of formateren, dat ik het /etc/fstab bestand moet aanpassen. Maar gezien de tijd die er nu in is gaan zitten door de problemen, zal ik dat niet meer snel vergeten denk ik.

De labels had ik ook nog voorbij zien komen maar ik denk dat ik het nu laat bij de UUID's. Het werkt en ik ben er tevreden mee.

[Hero of Time]

De benaming van de schrijven in /dev komt door Grub. Die maakt een index van de schijven en geeft daarvan /dev/sda door aan Linux aan de schijf die als eerste antwoord op z'n scan sweep. Dit kan dus SATA poort 3 zijn, dan weer eens 4 en dan weer eens 1. Bij mij is het gelukkig wel allemaal hetzelfde, maar dan nog is het geen probleem omdat ik UUIDs gebruik, zoals standaard wordt gebruikt.
Er is iig op Ubuntu forums, de documentatie en andere plaatsen op het net te vinden waardoor je schijven een andere node krijgen.

[deadinspace]

Hero Of Time schreef op vrijdag 13 augustus 2010 @ 19:21:
De benaming van de schrijven in /dev komt door Grub. Die maakt een index van de schijven en geeft daarvan /dev/sda door aan Linux aan de schijf die als eerste antwoord op z'n scan sweep.

De BIOS maakt een opsomming van de schijven; grub gebruikt alleen informatie die hij van de BIOS krijgt.

En wat grub (en de BIOS) doen heeft geen invloed op de volgorde van de schijven in Linux; Linux scant de controllers zelf en bepaalt daarmee ook de volgorde zelf.

Doorgaans is de volgorde van de schijven in Linux hetzelfde als aan de controller; een schijf aan het eerste channel zal dus sda worden, een schijf aan de tweede controller sdb, etc. Door de schijven in een handige volgorde aan de controller te hangen kun je hier dus een beetje rekening mee houden.

Ik snap overigens niet waarom Ubuntu (en Debian) niet standaard UUIDs gebruiken; het probleem van veranderende device namen komt naar mijn idee vrij vaak voor, en wil soms wel eens willekeurig zijn ook (usb, verschillende sata controllers die in willekeurige volgorde geinitialiseerd worden).

[Hero of Time]

Ubuntu en Debian gebruiken al standaard UUIDs. Hierdoor vind ik 't ook al vreemd dat de TS dit niet al gebruikte (misschien zelf vervangen toen hij de extra schijven in fstab zette?) of dat de installatie dit niet heeft ingesteld. Dat laatste zou het meest vreemde zijn.

[daft_dutch]

"alert! /dev/sdd1 does not exist. Dropping to a shell." En dat is nogal een vreemde melding want /dev/sdd (de harde schijf waarop Ubuntu Server staat) is wel gewoon aanwezig.

Met deze melding kan je wat. Dit komt van lilo/grub. Lijkt wel dat je PC je disken door elkaar gooit. uuid zou dat moeten oplossen. (vreemd). Maar met die shell zou je je root disk kunnen vinden mounten. en door de temp shell af te sluiten moet ubuntu verder gaan met het boot process.

[deadinspace]

Hero Of Time schreef op vrijdag 13 augustus 2010 @ 23:35:
Ubuntu en Debian gebruiken al standaard UUIDs.

Debian niet in ieder geval.

Van Ubuntu dacht ik dat ook, maar het systeem van de TS blijkbaar niet?

daft_dutch schreef op zaterdag 14 augustus 2010 @ 11:53:
"alert! /dev/sdd1 does not exist. Dropping to a shell." [...]

Met deze melding kan je wat. Dit komt van lilo/grub.

Nee, die melding komt van het initramfs, niet van de bootloader.

[deepbass909]

De TS gebruikt Ubuntu Server. Ik dacht dat die verder niet echt afwijkt van procedure, alleen dat er niet standaard een GUI geïnstalleerd wordt, maar wel diverse server apps (die bij de desktop dan weer niet geïnstalleerd worden). Blijkbaar niet...

Ik vind persoonlijk het gebruik van de UUID's nogal een ramp... de strings zijn lang (waardoor je fstab en menu.conf nogal onleesbaar worden) en de kans op een fout in een lange string is nogal groot. Daar komt bij, dat als je een schijf moet vervangen, je alle UUID's eerst moet aanpassen, terwijl met labels, je gewoon de oude schijf eruit trekt, de nieuwe erin en gaan. Bij labels moet je alleen wel oppassen dat deze case-sensitive zijn.

"alert! /dev/sdd1 does not exist. Dropping to a shell." [...]
Deze melding is nogal berucht, ook leuk als je nieuwe hardware hebt, en je hebt de harddisk-controller niet goed geconfigureerd in je kernel. Hij start op, laad de kernel (dus de schijf kan blijkbaar gelezen worden), en knalt dan naar de shell met de fout dat die schijf niet gelezen kan worden. Ik gebruik dan wel geen initramfs (waarom zou ik?), maar zo vreemd is die fout ook weer niet.
De complete willekeur van schijftoekenningen, dat is wat vreemd is in dit verhaal... Het zou me niks verbazen dat de bios gecompileerd is met een Microsoft compiler, ipv de intel. De MS-compiler haalt wel meer rare dingen uit (kijk maar naar de problemen van een paar jaar terug met de AMD64's en de cpu snelheid... moederborden waarvan de bios met de MS-compiler gemaakt waren hadden dit probleem, als de intel compiler was gebruikt, was er niks aan de hand)