Re: [gentoo-user] booting - I don't anystand how the (Linux) world works anymore

[Tom H]

On Sat, Jun 25, 2016 at 4:24 PM, Helmut Jarausch  wrote:
> On 06/25/2016 10:19:12 PM, Tom H wrote:
>>
>> You can use "root=PARTUUID=partuuid" where
>>
>> on an msdos-labeled disk:
>>
>> # findmnt / -o TARGET,SOURCE,PARTUUID
>> TARGET SOURCEPARTUUID
>> /  /dev/sda1 0006c8d7-01
>>
>> on a gpt-labeled disk:
>>
>> # findmnt / -o TARGET,SOURCE,PARTUUID
>> TARGET SOURCEPARTUUID
>> /  /dev/sda3 41e9268f-484a-43e2-ae81-54d8c84119e0
>
> Yes, thanks, that did it,

You're welcome.

The
ENV{ID_PART_ENTRY_UUID}=="?*",
SYMLINK+="disk/by-partuuid/$env{ID_PART_ENTRY_UUID}"
udev rule creates symlinks under "/dev/disk/by-partuuid/".

There's no need for findmnt :)

Re: [gentoo-user] booting - I don't anystand how the (Linux) world works anymore

[David W Noon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, 25 Jun 2016 22:18:39 +0200, Helmut Jarausch
(jarau...@skynet.be) wrote about "Re: [gentoo-user] booting - I don't
anystand how the (Linux) world works anymore" (in
<pIgoU9n+PTyazMfaAjTflI@P0zLLCmfwy+atNuDbwD3I>):

> On 06/25/2016 09:39:32 PM, David W Noon wrote:
[snip]
>> I always statically link the driver that operates the controller
>> that connects the root device and modprobe the drivers that
>> operate the other disk controllers. This ensures that the
>> controller for my /dev/sda device is probed first and its drives
>> get "a", "b" and "c" in /dev/sd?, and those letters are assigned
>> in device address order on the controller.
> 
> Thanks Dave, but I do statically link the corresponding device
> drivers, as well.

I should have been more clear: only 1 driver for disk controllers
should be statically linked; the others should be modprobed, usually
by naming them in /etc/conf.d/modules.

> But I don't understand why my only hard drive is named sdb?

Another drive, presumably on another controller, has been hardware
probed first.

The reason I use a mixture of static and dynamic linking is to control
the sequence in which the hardware probes are run. If you statically
link everything, the kernel can have the drivers run their hardware
probes in whatever order it chooses. When they are dynamically linked,
the hardware probes occur in the sequence in which the modprobes occur.

The upshot is that the drives controlled by statically linked drivers
are probed first, then the drives controlled by dynamically linked
drivers are probed in the order in which the modprobes occur.

Therefore, I configure my kernels so that the drives get probed in the
order I want.

> It looks as if my kernel named my built-in CDROM device as /dev/sda
> .

An optical drive should be /dev/sr0 or the like. Are you sure it's the
CD-ROM drive grabbing the hard drive address? That seems like
something the old IDE drivers used to do; if you are using the long
obsolete IDE kernel modules, you should really upgrade to the libata
drivers.

> And if I have plugged in an USB drive it seems to influence the
> naming scheme, as well.

Your USB controller's driver appears to be statically linked. This is
a seriously bad idea.

> And, to make it even more complicated, once the system is up, it
> has a different naming scheme. E.g. now my internal hard disk has
> the name /dev/sda but if I tried to boot by this name it fails.

That could well be udev/eudev renaming devices during its start-up.

> For a normal human as me, this is just crazy!

Well, Gentoo was never meant for normal humans. ... :-)
- -- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAldu8j8ACgkQRQ2Fs59Psv8T1gCgtZ76X/QGLPchCKnQ0v5Yoeyf
CogAn0EDnbSzGZrdHLLwF1SkO4gqH+yz
=BR6C
-END PGP SIGNATURE-

Re: [gentoo-user] booting - I don't anystand how the (Linux) world works anymore

[Helmut Jarausch]

Yes, thanks, that did it,
Helmut


On 06/25/2016 10:19:12 PM, Tom H wrote:
On Sat, Jun 25, 2016 at 2:33 PM, Helmut Jarausch   
wrote:

>
> I'm a dino since I still use grub-1 but I prefer recent kernels  
(currently

> 4.70-rc4)
>
> I don't understand the 'root=' option on the boot line like
> kernel /boot/vmlinuz-4.7.0-rc4 root=/dev/sda1
>
> Here my bad experience:
>
> Having booted by SystemRescueCD from the cdrom device, my root  
device is

> labelled /dev/sda1
> BUT trying to use that on the kernel boot line fails (the kernel  
cannot

> find the root file system)
>
> By trial and error I've found that I have to use root=/dev/sdb1
>
> but if I plug in an external drive (via USB) this doesn't work any  
more.

>
> So, I came up with root=UUID=uuid_number of the root file system.
>
> But to my surprise I now got a kernel panic
> syncing: VFS: unable to mount root fs on unknown block(0,0)
>
> So, please tell me what I'm missing?

Are you using an initramfs? You can't use "root=UUID=uuid" if you  
don't.


You can use "root=PARTUUID=partuuid" where

on an msdos-labeled disk:

# findmnt / -o TARGET,SOURCE,PARTUUID
TARGET SOURCEPARTUUID
/  /dev/sda1 0006c8d7-01

on a gpt-labeled disk:

# findmnt / -o TARGET,SOURCE,PARTUUID
TARGET SOURCEPARTUUID
/  /dev/sda3 41e9268f-484a-43e2-ae81-54d8c84119e0

Re: [gentoo-user] booting - I don't anystand how the (Linux) world works anymore

[Helmut Jarausch]

Thanks Rich for the explanation.

Yes, I don't use an initramfs as it's not necessary in my simple case.

Fortunately, Jeremy's hint to use  root=PARTUUID=  works just fine  
(if one knows about it)


Helmut


On 06/25/2016 09:46:21 PM, Rich Freeman wrote:
On Sat, Jun 25, 2016 at 2:33 PM, Helmut Jarausch   
wrote:

>
> I don't understand  the   'root=' option on the boot line like
> kernel /boot/vmlinuz-4.7.0-rc4 root=/dev/sda1
>

It is pretty simple.  If you're not using an initramfs, the kernel
attempts to find the device you list and mount it as /, and then it
runs whatever you pass in init=, or the canned list of init locations
it has stored inside if you don't pass that.  If you're using an
initramfs, the kernel mounts it as / and runs its init, passing the
root= parameter over to it.

>
> Having booted by SystemRescueCD from the cdrom device, my root  
device is

> labelled  /dev/sda1
>  BUT trying to use that on the kernel boot line fails (the kernel  
cannot

> find the root file system)
>
> By trial and error I've found that I have to use   root=/dev/sdb1
>
> but if I plug in an external drive (via USB) this doesn't work any  
more.


As you've no doubt figured out, the issue is that these device names
are assigned dynamically, and if your configuration changes (which I
suppose might even include changing the boot device depending on your
firmware), then these names can change.  The kernel's logic is pretty
basic and prone to these kinds of failures.

>
> So, I came up withroot=UUID=uuid_number of the root file system.
>
> But to my surprise I now got  a kernel panic
> syncing: VFS: unable to mount root fs on unknown block(0,0)
>
> So, please tell me what I'm missing?

The linux kernel doesn't have any concept of device UUIDs.  It can
only accept valid device names.

The bit you're missing is that the kernel only interprets the root=
parameter if you're not using an initramfs.  If you're using an
initramfs then the kernel just lets the initramfs mount root.  The
initramfs is basically a mini linux distro that can do just about
anything it wants, and most have a way to handle devices identified by
UUID.

I'd suggest using dracut, which seems to be the most robust initramfs
out there.  To use it (or any other initramfs) there are basically a
few steps:

1.  Create an initramfs image in /boot (the syntax varies by tool).
2.  Configure your bootloader to load the initramfs (the syntax varies
by bootloader)
3.  Pass an appropriate root= line to the kernel (the syntax varies by
initramfs implementation, but most handle the syntax you gave, as well
as the various udev paths that are based on UUIDs and labels and
such).

For dracut #1 is:
dracut "" version (ie dracut "" 4.7.0-rc4)

For grub1 #2 find the kernel line in your grub config file, and add a  
line:

initrd   (ie initrd initramfs-4.7.0-rc4.img)

Use the same path in that as your kernel, so if your kernel has some
kind of preceding directory path use the same for the initramfs.

While you can often get away without using an initramfs, in general
they tend to make the boot process more robust and they don't really
have any impact on the system once it is running.  They're loaded into
a ramfs, and they typically delete themselves out of ram right before
execing the real init.  They just give you a LOT more options while
booting (especially with dracut ; you'd probably be able to mount root
off of iscsi over a vpn using it).

--
Rich

Re: [gentoo-user] booting - I don't anystand how the (Linux) world works anymore

[Tom H]

On Sat, Jun 25, 2016 at 2:33 PM, Helmut Jarausch  wrote:
>
> I'm a dino since I still use grub-1 but I prefer recent kernels (currently
> 4.70-rc4)
>
> I don't understand the 'root=' option on the boot line like
> kernel /boot/vmlinuz-4.7.0-rc4 root=/dev/sda1
>
> Here my bad experience:
>
> Having booted by SystemRescueCD from the cdrom device, my root device is
> labelled /dev/sda1
> BUT trying to use that on the kernel boot line fails (the kernel cannot
> find the root file system)
>
> By trial and error I've found that I have to use root=/dev/sdb1
>
> but if I plug in an external drive (via USB) this doesn't work any more.
>
> So, I came up with root=UUID=uuid_number of the root file system.
>
> But to my surprise I now got a kernel panic
> syncing: VFS: unable to mount root fs on unknown block(0,0)
>
> So, please tell me what I'm missing?

Are you using an initramfs? You can't use "root=UUID=uuid" if you don't.

You can use "root=PARTUUID=partuuid" where

on an msdos-labeled disk:

# findmnt / -o TARGET,SOURCE,PARTUUID
TARGET SOURCEPARTUUID
/  /dev/sda1 0006c8d7-01

on a gpt-labeled disk:

# findmnt / -o TARGET,SOURCE,PARTUUID
TARGET SOURCEPARTUUID
/  /dev/sda3 41e9268f-484a-43e2-ae81-54d8c84119e0

Re: [gentoo-user] booting - I don't anystand how the (Linux) world works anymore

[Helmut Jarausch]

On 06/25/2016 09:39:32 PM, David W Noon wrote:

On Sat, 25 Jun 2016 20:33:31 +0200, Helmut Jarausch
(jarau...@skynet.be) wrote about "[gentoo-user] booting - I don't
anystand how the (Linux) world works anymore" (in
<YseLVsRteFjBS+5CTTP64t@7zc0huhpDvqcKwT48Q8b0>):

[snip]
> So, I came up withroot=UUID=uuid_number of the root file
> system.
>
> But to my surprise I now got  a kernel panic syncing: VFS: unable
> to mount root fs on unknown block(0,0)
>
> So, please tell me what I'm missing?

How are you configuring the kernel modules to operate your disk
controllers? This situation is usually typical of having more than one
set of disks from which the system can boot.


Yes, or several partitions on a disk.


I always statically link the driver that operates the controller that
connects the root device and modprobe the drivers that operate the
other disk controllers. This ensures that the controller for my
/dev/sda device is probed first and its drives get "a", "b" and "c" in
/dev/sd?, and those letters are assigned in device address order on
the controller.


Thanks Dave,
but I do statically link the corresponding device drivers, as well.
But I don't understand why my only hard drive is named sdb?
It looks as if my kernel named my built-in CDROM device as /dev/sda .
And if I have plugged in an USB drive it seems to influence the naming  
scheme, as well.


And, to make it even more complicated, once the system is up, it has a  
different naming scheme.
E.g. now my internal hard disk has the name /dev/sda but if I tried to  
boot by this name it fails.


For a normal human as me, this is just crazy!

Helmut

Re: [gentoo-user] booting - I don't anystand how the (Linux) world works anymore

[Rich Freeman]

On Sat, Jun 25, 2016 at 3:51 PM, Alan McKinnon  wrote:
>
> [1] It's also one of the reasons persistent device naming came into
> udev, to try guarantee the same device will always have the same name
>

This is also one of the reasons why an initramfs is useful.

Linus basically decided that it makes far more sense to have userspace
manage this stuff than the kernel, and the initramfs is the way this
is accomplished during boot.  They didn't remove the existing kernel
functionality, but they're not going to be investing in it.

-- 
Rich

Re: [gentoo-user] booting - I don't anystand how the (Linux) world works anymore

[Helmut Jarausch]

Many, many thanks!
That works indeed.

Helmut

On 06/25/2016 09:19:47 PM, Jeremi Piotrowski wrote:

On Sat, Jun 25, 2016 at 08:33:31PM +0200, Helmut Jarausch wrote:
>
> So, I came up withroot=UUID=uuid_number of the root file system.
>
> But to my surprise I now got  a kernel panic
> syncing: VFS: unable to mount root fs on unknown block(0,0)
>
> So, please tell me what I'm missing?

root=UUID lines are normally interpreted by the initramfs to find the
right device to mount. If you don't use one, the kernel pretty much  
only

supports root=/dev/ or root=PARTUUID identifiers (check kernel
source file init/do_mounts.c:182,207 for details).

You can find your PARTUUID using `blkid` or `lsblk -o +PARTUUID`.

Re: [gentoo-user] booting - I don't anystand how the (Linux) world works anymore

[Alan McKinnon]

On 25/06/2016 20:33, Helmut Jarausch wrote:
> Hi,
> 
> I'm a dino since I still use grub-1 but I prefer recent kernels
> (currently 4.70-rc4)
> 
> I don't understand  the   'root=' option on the boot line like
> kernel /boot/vmlinuz-4.7.0-rc4 root=/dev/sda1
> 
> Here my bad experience:
> 
> Having booted by SystemRescueCD from the cdrom device, my root device is
> labelled  /dev/sda1
>  BUT trying to use that on the kernel boot line fails (the kernel cannot
> find the root file system)
> 
> By trial and error I've found that I have to use   root=/dev/sdb1
> 
> but if I plug in an external drive (via USB) this doesn't work any more.
> 
> So, I came up withroot=UUID=uuid_number of the root file system.
> 
> But to my surprise I now got  a kernel panic
> syncing: VFS: unable to mount root fs on unknown block(0,0)
> 
> So, please tell me what I'm missing?
> 
> Many thanks!!!
> Helmut
> 
> 


I've run into this with my last 3 laptops. grub, systemrescue and most
other things that run before my kernel is booted usually find the SSD as
the first drive (what a running kernel would call sda), and the spinning
rust is sdb.


When the kernel eventually boots and does device discovery, it decides
the spinning rust is the primary drive (sdb) - the opposite way around.

So why does this happen? screwed if I know, BUT, the the kernel has
never guaranteed it will always find and enumerate devices the same way
every time always. This might account for why SystemRescueCD and your
installed system do opposite things[1]. We don't know *why* it's sdb,
but we know at grub time that it is. SO use whatever that software
thinks the thing is called :-)



[1] It's also one of the reasons persistent device naming came into
udev, to try guarantee the same device will always have the same name


-- 
Alan McKinnon
alan.mckin...@gmail.com

Re: [gentoo-user] booting - I don't anystand how the (Linux) world works anymore

[Rich Freeman]

On Sat, Jun 25, 2016 at 2:33 PM, Helmut Jarausch  wrote:
>
> I don't understand  the   'root=' option on the boot line like
> kernel /boot/vmlinuz-4.7.0-rc4 root=/dev/sda1
>

It is pretty simple.  If you're not using an initramfs, the kernel
attempts to find the device you list and mount it as /, and then it
runs whatever you pass in init=, or the canned list of init locations
it has stored inside if you don't pass that.  If you're using an
initramfs, the kernel mounts it as / and runs its init, passing the
root= parameter over to it.

>
> Having booted by SystemRescueCD from the cdrom device, my root device is
> labelled  /dev/sda1
>  BUT trying to use that on the kernel boot line fails (the kernel cannot
> find the root file system)
>
> By trial and error I've found that I have to use   root=/dev/sdb1
>
> but if I plug in an external drive (via USB) this doesn't work any more.

As you've no doubt figured out, the issue is that these device names
are assigned dynamically, and if your configuration changes (which I
suppose might even include changing the boot device depending on your
firmware), then these names can change.  The kernel's logic is pretty
basic and prone to these kinds of failures.

>
> So, I came up withroot=UUID=uuid_number of the root file system.
>
> But to my surprise I now got  a kernel panic
> syncing: VFS: unable to mount root fs on unknown block(0,0)
>
> So, please tell me what I'm missing?

The linux kernel doesn't have any concept of device UUIDs.  It can
only accept valid device names.

The bit you're missing is that the kernel only interprets the root=
parameter if you're not using an initramfs.  If you're using an
initramfs then the kernel just lets the initramfs mount root.  The
initramfs is basically a mini linux distro that can do just about
anything it wants, and most have a way to handle devices identified by
UUID.

I'd suggest using dracut, which seems to be the most robust initramfs
out there.  To use it (or any other initramfs) there are basically a
few steps:

1.  Create an initramfs image in /boot (the syntax varies by tool).
2.  Configure your bootloader to load the initramfs (the syntax varies
by bootloader)
3.  Pass an appropriate root= line to the kernel (the syntax varies by
initramfs implementation, but most handle the syntax you gave, as well
as the various udev paths that are based on UUIDs and labels and
such).

For dracut #1 is:
dracut "" version (ie dracut "" 4.7.0-rc4)

For grub1 #2 find the kernel line in your grub config file, and add a line:
initrd   (ie initrd initramfs-4.7.0-rc4.img)

Use the same path in that as your kernel, so if your kernel has some
kind of preceding directory path use the same for the initramfs.

While you can often get away without using an initramfs, in general
they tend to make the boot process more robust and they don't really
have any impact on the system once it is running.  They're loaded into
a ramfs, and they typically delete themselves out of ram right before
execing the real init.  They just give you a LOT more options while
booting (especially with dracut ; you'd probably be able to mount root
off of iscsi over a vpn using it).

-- 
Rich

Re: [gentoo-user] booting - I don't anystand how the (Linux) world works anymore

[David W Noon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, 25 Jun 2016 20:33:31 +0200, Helmut Jarausch
(jarau...@skynet.be) wrote about "[gentoo-user] booting - I don't
anystand how the (Linux) world works anymore" (in
<YseLVsRteFjBS+5CTTP64t@7zc0huhpDvqcKwT48Q8b0>):

[snip]
> So, I came up withroot=UUID=uuid_number of the root file
> system.
> 
> But to my surprise I now got  a kernel panic syncing: VFS: unable
> to mount root fs on unknown block(0,0)
> 
> So, please tell me what I'm missing?

How are you configuring the kernel modules to operate your disk
controllers? This situation is usually typical of having more than one
set of disks from which the system can boot.

I always statically link the driver that operates the controller that
connects the root device and modprobe the drivers that operate the
other disk controllers. This ensures that the controller for my
/dev/sda device is probed first and its drives get "a", "b" and "c" in
/dev/sd?, and those letters are assigned in device address order on
the controller.
- -- 
Regards,

Dave  [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAldu3fQACgkQRQ2Fs59Psv9+DgCg0bhVfl8qw9JG9KF2655vgd5y
GHUAoJpVpMFqCvro/LIFAjHAMkKdXb8V
=HIdO
-END PGP SIGNATURE-

Re: [gentoo-user] booting - I don't anystand how the (Linux) world works anymore

[Jeremi Piotrowski]

On Sat, Jun 25, 2016 at 08:33:31PM +0200, Helmut Jarausch wrote:
> 
> So, I came up withroot=UUID=uuid_number of the root file system.
> 
> But to my surprise I now got  a kernel panic
> syncing: VFS: unable to mount root fs on unknown block(0,0)
> 
> So, please tell me what I'm missing?

root=UUID lines are normally interpreted by the initramfs to find the
right device to mount. If you don't use one, the kernel pretty much only
supports root=/dev/ or root=PARTUUID identifiers (check kernel
source file init/do_mounts.c:182,207 for details). 

You can find your PARTUUID using `blkid` or `lsblk -o +PARTUUID`.

[gentoo-user] booting - I don't anystand how the (Linux) world works anymore

[Helmut Jarausch]

Hi,

I'm a dino since I still use grub-1 but I prefer recent kernels  
(currently 4.70-rc4)


I don't understand  the   'root=' option on the boot line like
kernel /boot/vmlinuz-4.7.0-rc4 root=/dev/sda1

Here my bad experience:

Having booted by SystemRescueCD from the cdrom device, my root device  
is labelled  /dev/sda1
 BUT trying to use that on the kernel boot line fails (the kernel  
cannot find the root file system)


By trial and error I've found that I have to use   root=/dev/sdb1

but if I plug in an external drive (via USB) this doesn't work any more.

So, I came up withroot=UUID=uuid_number of the root file system.

But to my surprise I now got  a kernel panic
syncing: VFS: unable to mount root fs on unknown block(0,0)

So, please tell me what I'm missing?

Many thanks!!!
Helmut