[svlug] Can't get LFS systemd system to boot

Rick Moen rick at linuxmafia.com
Fri Jan 30 01:24:17 PST 2015

(I'm again removing Michael's '...' suffix from his Subject header.  
Honestly, Michael, what the Gehenna is that for?)

Quoting Michael Robinson (plug_1 at robinson-west.com):

> Yes, that was it.  Trouble is, how do I cut and paste the diagnostic
> message when the system isn't booting?

Me, I'd either jot it onto a legal pad or snapshot the screen using a
smartphone or other digital camera and later transcribe it.  Either way,
you _do_ need to transcribe it -- unless you're doing this in a VM.
Which you may recall is what I suggested, and would give you Clipboard

What you're now saying amounts to 'Gee, but I'd have to, y'know, write
something down.'  Correct, what I've said -- twice -- is you should do
exactly that.

If you're not willing to transcribe diagnostic strings accurately, 
it's much more difficult to help you, and some may choose to not try.
Naturally, your call as to whether 10 seconds' additional effort is that

> Here is my current grub.cfg:
> [root at eagle64 ~]# ./enter_chroot.bash 
> root [ / ]# cd /boot/
> root [ /boot ]# ls
> config-3.16.2  lost+found         vmlinuz-3.16.2-lfs-7.6-systemd
> grub           System.map-3.16.2
> root [ /boot ]# cat grub/grub.cfg 
> # Begin /boot/grub/grub.cfg
> set default=0
> set timeout=5
> insmod ext2
> set root=(hd0,msdos1)
> menuentry "GNU/Linux, Linux-3.16.2-lfs-7.6-systemd" {
> 	linux /vmlinuz-3.16.2-lfs-7.6-systemd root=0x823 ro
> }
> root [ /boot ]# 
> But now I get unknown-block(8,35).  

unknown-block(8,35) is Linux major,minor device syntax (see kernel.org
URL cited below), showing _what_ cannot be mounted as the root
filesystem.  (I still laugh heartily when I remember all of those people
who claimed with a serious face that changing from lilo to GRUB was
going to make everything easier.  What a crock!)

Aside:  I'm a little confused.  Slightly earlier, you were asking how to
specify the root fs using UUID.  I provided that answer.  Is there are
reason why you're not using that information?  Wasn't the whole point of
that, that you were worried about reshuffling of device recognition or
something like that?  Having gotten that answer, you ignore it and try 
a hexadecimal rendition of the /dev/sd?? name.  What's up with that,

As init/do_mounts.c (kernel source code) says:

 *  Convert a name into device number.  We accept the following variants:
 *  1) device number in hexadecimal represents itself
 *  2) /dev/nfs represents Root_NFS (0xff)
 *  3) /dev/<disk_name> represents the device number of disk
 *  4) /dev/<disk_name><decimal> represents the device number
 *         of partition - device number of disk plus the partition number
 *  5) /dev/<disk_name>p<decimal> - same as the above, that form is
 *     used when disk name of partitioned disk ends on a digit.
 *  6) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing the
 *     unique id of a partition if the partition table provides it.
 *     The UUID may be either an EFI/GPT UUID, or refer to an MSDOS
 *     partition using the format SSSSSSSS-PP, where SSSSSSSS is a zero-
 *     filled hex representation of the 32-bit "NT disk signature", and PP
 *     is a zero-filled hex representation of the 1-based partition number.
 *  7) PARTUUID=<UUID>/PARTNROFF=<int> to select a partition in relation to
 *     a partition with a known unique id.
 *  If name doesn't have fall into the categories above, we return (0,0).
 *  block_class is used to check if something is a disk name. If the disk
 *  name contains slashes, the device name has them replaced with
 *  bangs.

For some reason, you're now electing to use syntax variant #1, hexadecimal.
further clarifies:

  A device number in hexadecimal represents the major and minor number
  of the device in the internal format that the kernel expects.  This
  method is not recommended unless you have access to kernel internals.

Um, yeah.  I don't know offhand how to decompose 0x823 into major and
minor device numbers, and am wondering how you calculated it.  And thus
I wonder how you know it's the device you intended.  

Approaching that matter from the other side, the diagnostic -- which you
are _still_ not bothering to transcribe verbatim (just part of it) -- says:


As you'll see in https://www.kernel.org/doc/Documentation/devices.txt:

Major number '8' is Linux block devices (such as disk devices)
Minor number '35' is /dev/sdc3  (because '32' is /dev/sdc as a whole)

Were you trying to boot /dev/sdc3 as the root device?  Because that
appears to be what 0x823 resolves to.

> Not sure about the unknown part of the message.

It merely means that the kernel was not able to find the device whose
hexadecimal number you provided.

More information about the svlug mailing list