| 1 |
On Sat, Jun 25, 2016 at 2:33 PM, Helmut Jarausch <jarausch@××××××.be> wrote: |
| 2 |
> |
| 3 |
> I don't understand the 'root=' option on the boot line like |
| 4 |
> kernel /boot/vmlinuz-4.7.0-rc4 root=/dev/sda1 |
| 5 |
> |
| 6 |
|
| 7 |
It is pretty simple. If you're not using an initramfs, the kernel |
| 8 |
attempts to find the device you list and mount it as /, and then it |
| 9 |
runs whatever you pass in init=, or the canned list of init locations |
| 10 |
it has stored inside if you don't pass that. If you're using an |
| 11 |
initramfs, the kernel mounts it as / and runs its init, passing the |
| 12 |
root= parameter over to it. |
| 13 |
|
| 14 |
> |
| 15 |
> Having booted by SystemRescueCD from the cdrom device, my root device is |
| 16 |
> labelled /dev/sda1 |
| 17 |
> BUT trying to use that on the kernel boot line fails (the kernel cannot |
| 18 |
> find the root file system) |
| 19 |
> |
| 20 |
> By trial and error I've found that I have to use root=/dev/sdb1 |
| 21 |
> |
| 22 |
> but if I plug in an external drive (via USB) this doesn't work any more. |
| 23 |
|
| 24 |
As you've no doubt figured out, the issue is that these device names |
| 25 |
are assigned dynamically, and if your configuration changes (which I |
| 26 |
suppose might even include changing the boot device depending on your |
| 27 |
firmware), then these names can change. The kernel's logic is pretty |
| 28 |
basic and prone to these kinds of failures. |
| 29 |
|
| 30 |
> |
| 31 |
> So, I came up with root=UUID=uuid_number of the root file system. |
| 32 |
> |
| 33 |
> But to my surprise I now got a kernel panic |
| 34 |
> syncing: VFS: unable to mount root fs on unknown block(0,0) |
| 35 |
> |
| 36 |
> So, please tell me what I'm missing? |
| 37 |
|
| 38 |
The linux kernel doesn't have any concept of device UUIDs. It can |
| 39 |
only accept valid device names. |
| 40 |
|
| 41 |
The bit you're missing is that the kernel only interprets the root= |
| 42 |
parameter if you're not using an initramfs. If you're using an |
| 43 |
initramfs then the kernel just lets the initramfs mount root. The |
| 44 |
initramfs is basically a mini linux distro that can do just about |
| 45 |
anything it wants, and most have a way to handle devices identified by |
| 46 |
UUID. |
| 47 |
|
| 48 |
I'd suggest using dracut, which seems to be the most robust initramfs |
| 49 |
out there. To use it (or any other initramfs) there are basically a |
| 50 |
few steps: |
| 51 |
|
| 52 |
1. Create an initramfs image in /boot (the syntax varies by tool). |
| 53 |
2. Configure your bootloader to load the initramfs (the syntax varies |
| 54 |
by bootloader) |
| 55 |
3. Pass an appropriate root= line to the kernel (the syntax varies by |
| 56 |
initramfs implementation, but most handle the syntax you gave, as well |
| 57 |
as the various udev paths that are based on UUIDs and labels and |
| 58 |
such). |
| 59 |
|
| 60 |
For dracut #1 is: |
| 61 |
dracut "" version (ie dracut "" 4.7.0-rc4) |
| 62 |
|
| 63 |
For grub1 #2 find the kernel line in your grub config file, and add a line: |
| 64 |
initrd <filename> (ie initrd initramfs-4.7.0-rc4.img) |
| 65 |
|
| 66 |
Use the same path in that as your kernel, so if your kernel has some |
| 67 |
kind of preceding directory path use the same for the initramfs. |
| 68 |
|
| 69 |
While you can often get away without using an initramfs, in general |
| 70 |
they tend to make the boot process more robust and they don't really |
| 71 |
have any impact on the system once it is running. They're loaded into |
| 72 |
a ramfs, and they typically delete themselves out of ram right before |
| 73 |
execing the real init. They just give you a LOT more options while |
| 74 |
booting (especially with dracut ; you'd probably be able to mount root |
| 75 |
off of iscsi over a vpn using it). |
| 76 |
|
| 77 |
-- |
| 78 |
Rich |
Archives