Archlinux op usb drive sda, na reboot ineens sdb?

[Red devil]

Beste tweakers,

Archlinux op een Pogoplug gezet. Eerst owncloud erop gezet maar dat werkt nog niet erg lekker.

Onlangs een externe 1TB WD eraan gekoppeld (ext4, 1 grote partitie gezien als sdb).

Omdat ik niet wil dat de pogoplug niet wil opstarten als er geen harde schijf gekoppeld is, heb ik geen entry in FSTAB toegevoegd en mount ik de harde schijf manueel.

Echter, bij een reboot was de opstart flash disc sdb geworden (was eerst sda) en was de WD schijf sda (was eerst sdb).

Nogal irritant eigenlijk, kan ik Archlinux dit gedrag afleren?

[Hero of Time]

Nee, dat gaat niet zo makkelijk. Maar, waarom niet in fstab? Heb je de man-page wel gelezen over manueel mounten via fstab? Want met noauto wordt-ie niet on-boot gemount. Handig als-ie dan nog niet bestaat

Daarbij, het boeit in beide gevallen niets, want mounten kan je via device node, label, UUID en path doen. Als ik een stick in m'n PC steek, wordt deze automatisch gemount adhv z'n label. Kan je zelf ook regelen via udev rules.

[Red devil]

ah ok dus dat zou een optie zijn. Het is me vroeger wel voorgekomen dat linux bakjes niet door gingen met booten omdat er iets in fstab miste. Met een server en beeldscherm kom je daar wel achter, maar met een scherm loos pogoplug ding is dat iets moeilijker :-)

[edit]
Blijft het probleem dan trouwens niet dat mijn boot flash drive al gezien wordt als sda? M.a.w., dat het feit dat ik de usb hd met noauto in de fstab gooi, geen invloed heeft op identiteit van de boot flash drive?

[ Voor 30% gewijzigd door Red devil op 05-01-2013 20:27 ]

[Raynman]

Red devil schreef op zaterdag 05 januari 2013 @ 20:01:
[edit]
Blijft het probleem dan trouwens niet dat mijn boot flash drive al gezien wordt als sda? M.a.w., dat het feit dat ik de usb hd met noauto in de fstab gooi, geen invloed heeft op identiteit van de boot flash drive?

Hero Of Time schreef op zaterdag 05 januari 2013 @ 19:01:
Daarbij, het boeit in beide gevallen niets, want mounten kan je via device node, label, UUID en path doen. Als ik een stick in m'n PC steek, wordt deze automatisch gemount adhv z'n label. Kan je zelf ook regelen via udev rules.

label of UUID kun je ipv device node gebruiken in fstab, en die zijn niet/minder dynamisch.

[Mijzelf]

Red devil schreef op zaterdag 05 januari 2013 @ 20:01:
Blijft het probleem dan trouwens niet dat mijn boot flash drive al gezien wordt als sda? M.a.w., dat het feit dat ik de usb hd met noauto in de fstab gooi, geen invloed heeft op identiteit van de boot flash drive?

Wat je in fstab zet heeft natuurlijk geen invloed op de identiteit van de boot partitie. De boot partitie wordt immers eerst gemount, en pas dan kan fstab worden gelezen.

[Red devil]

Mijzelf schreef op zaterdag 05 januari 2013 @ 22:03:
[...]
Wat je in fstab zet heeft natuurlijk geen invloed op de identiteit van de boot partitie. De boot partitie wordt immers eerst gemount, en pas dan kan fstab worden gelezen.

Precies, dus als ik nu een nieuwe install doe (want na een reboot blijft de flash op sdb) de fstab instel, kan net zo goed de boot flash drive weer op sdb staan. Dus geen garanties. Er is dus geen manier om de boot flash partitie altijd op sda te laten mouten.

[Mijzelf]

Waarom zou je dat willen? Je systeem start, dus ik neem aan dat er een initramfs is die de juiste partitie mount op basis van een UUID of zo, of dat de bootloader een UUID meegeeft. En verder boeit het toch niet welke device naam je boot partitie heeft?

[Hero of Time]

Red devil schreef op zaterdag 05 januari 2013 @ 22:27:
[...]

Precies, dus als ik nu een nieuwe install doe (want na een reboot blijft de flash op sdb) de fstab instel, kan net zo goed de boot flash drive weer op sdb staan. Dus geen garanties. Er is dus geen manier om de boot flash partitie altijd op sda te laten mouten.

Er zijn zat posts/weblogs op 't internet te vinden die aangeven dat je geen device nodes in fstab moet zetten, maar met UUID of desnoods labels. Een herinstall zal je huidige situatie niet veranderen. Om het even aan te geven hoe 't werkt.

Je PC BIOS checkt alle schijfcontrollers op aanwezigheid van schijven. Het zal starten van de eerste schijf op de eerste controller, tenzij anders aangegeven. Maar niet elke schijf reageert even snel. Het BIOS geeft het OS, in dit geval Linux, een lijst met gevonden schijven door in volgorde van detectie/reactie. Dit betekend dat per boot het niet gegarandeerd is dat de eerste schijf op de eerste controller altijd sda zal zijn. Als deze schijf net een milliseconde later reageert dan de tweede, zal het sdb worden.
De computer kan alsnog prima starten, want 't start pas van de schijven nadat alles is gedetecteerd.

Grub zet de schijf waar 't op staat, en dus 't systeem van start, altijd vooraan, als (hd0) (zoals dat in Grub legacy wordt genoemd). In je grub config staat dat 't de initramfs zal laden van de partitie met een specifiek pad. Dit kan een device node zijn, maar ook een UUID. Gebruik je device path, dan kan het voorkomen dat 't systeem niet kan starten door de volgorde van detectie in het BIOS. Wordt er UUID gebruikt, zal 't /boot altijd vinden, initramfs laden en het boot proces initiëren van het OS.

Hoe het hierna precies zit met het vinden van fstab weet ik niet, maar Linux kan pas opstarten als / correct gemount kan worden. Als je device nodes gebruikt, zal 't systeem falen als het niet de benodigde onderdelen kan vinden, zoals device modules van de kernel voor aansturing van alle hardware. Ook het starten van processen zal niet lukken.
Bij gebruik van UUID in fstab is de garantie dat / correct gemount zal worden vele malen groter, tot praktisch 100% (er is altijd een mogelijkheid dat je file system corrupt is).

Het boeit dus niet of /boot op sda1, sdb2 of desnoods op sdq38 staat. Als de bootloader het maar kan vinden. Als initramfs eenmaal is geladen, is /boot niet meer belangrijk. /boot komt alleen bij het opstarten kijken, en als je een nieuwe kernel installeert, of iets aan je huidige configuratie wijzigt mbt opstarten t/m initramfs.

[Red devil]

Mijzelf schreef op zaterdag 05 januari 2013 @ 23:09:
Waarom zou je dat willen? Je systeem start, dus ik neem aan dat er een initramfs is die de juiste partitie mount op basis van een UUID of zo, of dat de bootloader een UUID meegeeft. En verder boeit het toch niet welke device naam je boot partitie heeft?

[edit] onderstaande niet meer relevant na uitleg van hero
Nou, als het nu de boot schijf op sdb staat, wie geeft mij de garantie dat ie bij een andere reboot niet op sda staat?

Hero Of Time schreef op zaterdag 05 januari 2013 @ 23:49:
[...]

Er zijn zat posts/weblogs op 't internet te vinden die aangeven dat je geen device nodes in fstab moet zetten, maar met UUID of desnoods labels. Een herinstall zal je huidige situatie niet veranderen. Om het even aan te geven hoe 't werkt.

Je PC BIOS checkt alle schijfcontrollers op aanwezigheid van schijven. Het zal starten van de eerste schijf op de eerste controller, tenzij anders aangegeven. Maar niet elke schijf reageert even snel. Het BIOS geeft het OS, in dit geval Linux, een lijst met gevonden schijven door in volgorde van detectie/reactie. Dit betekend dat per boot het niet gegarandeerd is dat de eerste schijf op de eerste controller altijd sda zal zijn. Als deze schijf net een milliseconde later reageert dan de tweede, zal het sdb worden.
De computer kan alsnog prima starten, want 't start pas van de schijven nadat alles is gedetecteerd.

Grub zet de schijf waar 't op staat, en dus 't systeem van start, altijd vooraan, als (hd0) (zoals dat in Grub legacy wordt genoemd). In je grub config staat dat 't de initramfs zal laden van de partitie met een specifiek pad. Dit kan een device node zijn, maar ook een UUID. Gebruik je device path, dan kan het voorkomen dat 't systeem niet kan starten door de volgorde van detectie in het BIOS. Wordt er UUID gebruikt, zal 't /boot altijd vinden, initramfs laden en het boot proces initiëren van het OS.

Hoe het hierna precies zit met het vinden van fstab weet ik niet, maar Linux kan pas opstarten als / correct gemount kan worden. Als je device nodes gebruikt, zal 't systeem falen als het niet de benodigde onderdelen kan vinden, zoals device modules van de kernel voor aansturing van alle hardware. Ook het starten van processen zal niet lukken.
Bij gebruik van UUID in fstab is de garantie dat / correct gemount zal worden vele malen groter, tot praktisch 100% (er is altijd een mogelijkheid dat je file system corrupt is).

Het boeit dus niet of /boot op sda1, sdb2 of desnoods op sdq38 staat. Als de bootloader het maar kan vinden. Als initramfs eenmaal is geladen, is /boot niet meer belangrijk. /boot komt alleen bij het opstarten kijken, en als je een nieuwe kernel installeert, of iets aan je huidige configuratie wijzigt mbt opstarten t/m initramfs.

Ok bedankt voor je uitleg. Het is in overeenstemming met opmerkingen in tutorials over usb flash discs die niet zo snel worden gevonden zodat je soms meerdere keren moet rebooten.

Het lijkt erop dat het een soort van kans proces is, wie is er sneller aan en komt daardoor hoger in de queue. Als ik het goed begrijp kan ik met een UUID fstab vertellen dat die schijf naar een bepaalde mount point moet worden gebracht. Als dat eenmaal ok is, dan maakt het idd verder niet uit wie er nou sda of sdb is. Eenmaal opgestart werk je toch met de mounted folders.

[Hero of Time]

Precies. Als de schijven toch altijd verbonden zijn, kan je 't net zo goed al laten mounten bij 't opstarten.

Bij de detectie kan je bijvoorbeeld denken aan USB media. Je hebt een externe harde schijf die pas op spint als het een USB link heeft. Dit kost even tijd, waarbij de interne flash media al gevonden kan zijn. Maar met een reboot kan de schijf direct reageren, waardoor het voor de interne media kan worden gedetecteerd.
Vroeger had je dit met trage IDE schijven en controllers. Niet elke schijf ging even snel aan en niet elke controller reageerde even snel op de query van het BIOS.