[lfs-support] Error: invalid file name When Booting For the FirstTime

Alan Feuerbacher alanf00 at comcast.net
Sat Nov 23 17:59:38 PST 2013


Well I finally found the problem why linux would not boot: for some 
reason grub is assigning (hd0) to /dev/sdb. The latter is where I've 
installed LFS. So in grub.cfg I changed "set root=(hd1,1)" to "set 
root=(hd0,1)". Following the syntax in the grub.cfg in Fedora19's 
installation on /dev/sda, I found that "set root='hd0,msdos1'" also 
works. When I changed this and rebooted, linux came up. Whew!

I found this by following the suggestions of Pierre, Fernando and Ken, 
and doing some careful detective work.

I didn't realize until a little while ago that there was something 
radically inconsistent with the way the grub shell listed the hard disks:

ls => (hd0) (hd0,msdos6) (hd0,msdos5) (hd0,msdos3) (hd0,msdos2) 
(hd0,msdos1) (hd1) (hd1,msdos2) (hd1,msdos1) (hd2)

I looked carefully at the overall disk layout using lsblk, blkid, fdisk 
and gdisk. By comparing the outputs of these programs with the above 
output of ls, I realized that grub is swapping the positions of /dev/sda 
and /dev/sdb, such that /dev/sda -> (hd1) and /dev/sdb -> (hd0). I also 
discovered that fdisk is apparently doing something similar.

Here, lsblk shows what corresponds to the physical location of the disks 
in terms of what SATA ports they're plugged into:

root [ / ]# lsblk
#################
NAME            MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda               8:0    0  1.8T  0 disk
+-sda1            8:1    0  500M  0 part
+-sda2            8:2    0  1.8T  0 part
   +-fedora-root 253:0    0   50G  0 lvm  /fedoraroot
   +-fedora-swap 253:1    0  7.7G  0 lvm  [SWAP]
   +-fedora-home 253:5    0  1.8T  0 lvm  /fedorahome
sdb               8:16   0  1.8T  0 disk
+-sdb1            8:17   0    1G  0 part /boot
+-sdb2            8:18   0   16G  0 part [SWAP]
+-sdb3            8:19   0  100G  0 part /
+-sdb4            8:20   0    1K  0 part
+-sdb5            8:21   0  200G  0 part /home
+-sdb6            8:22   0  195G  0 part /opt
sdc               8:32   0  1.8T  0 disk
+-sdc1            8:33   0    1G  0 part
+-sdc2            8:34   0  500G  0 part
   +-vglfs-swap  253:2    0   16G  0 lvm
   +-vglfs-root  253:3    0  100G  0 lvm  /lfsefiroot
   +-vglfs-home  253:4    0  384G  0 lvm  /lfsefihome
sr0              11:0    1 1024M  0 rom
#################

Here, blkid shows some crucially useful information about UUID's that 
helped me track down what was going wrong:

root [ / ]# blkid
#################
/dev/sda1: UUID="db51dd77-f71f-4319-b439-e13926388f1b" TYPE="ext4" 
PARTUUID="000a5524-01"
/dev/sda2: UUID="exid3g-e84U-w93k-g6tR-1qYk-dgHd-uY6uYf" 
TYPE="LVM2_member" PARTUUID="000a5524-02"
/dev/sdb1: UUID="e6edb5f1-1e29-4538-b0bf-4d00337dc07a" TYPE="ext4" 
PARTUUID="e185ae78-01"
/dev/sdb2: UUID="9b7f161e-cf91-4a76-9286-25251a07eeaf" TYPE="swap" 
PARTUUID="e185ae78-02"
/dev/sdb3: UUID="ec1ef083-8cac-49e4-be0d-4df9313c06be" TYPE="ext4" 
PARTUUID="e185ae78-03"
/dev/sdb5: UUID="c6731536-1c77-490f-af78-306610ac10c7" TYPE="ext4" 
PARTUUID="e185ae78-05"
/dev/sdb6: UUID="df780b67-3e9f-4f28-9118-23242d43109e" TYPE="ext4" 
PARTUUID="e185ae78-06"
/dev/mapper/fedora-root: UUID="216a3b57-308b-40d1-9fb4-dc4bfb00e652" 
TYPE="ext4"
/dev/mapper/fedora-swap: UUID="76bfd777-3fe9-4d43-b7b3-d474769a2e73" 
TYPE="swap"
/dev/mapper/fedora-home: UUID="766d3abc-9598-4948-b541-a767d21b5f1e" 
TYPE="ext4"
/dev/sdc1: UUID="A12D-1A6F" TYPE="vfat" PARTLABEL="EFI System" 
PARTUUID="f000e2e8-a452-4553-a939-5edddc4cbbc7"
/dev/sdc2: UUID="DEig5C-AQxo-ncwd-Xd1p-MKAv-LtAe-3fhM2Y" 
TYPE="LVM2_member" PARTLABEL="Linux LVM" 
PARTUUID="1505ae6f-a4ef-41bc-a9a8-ff8c20fb2854"
/dev/mapper/vglfs-swap: UUID="7b173603-96fb-49ba-a582-2294c38745cd" 
TYPE="swap"
/dev/mapper/vglfs-root: UUID="2cb0acca-841d-4164-817b-b20e6584ac84" 
TYPE="ext4"
/dev/mapper/vglfs-home: UUID="1b70c23a-48a3-4410-b6d0-ac1744e682ee" 
TYPE="ext4
#################

The following partial output from fdisk shows that fdisk is listing the 
disks in the same order in which grub is assigning the (hdX) numbers. 
Note that the number of partitions for each disk (5, 2 and 2 (minus the 
Extended partition on /dev/sdb4)) and their partition numbers and their 
order corresponds to the grub shell's output:

root [ / ]# fdisk -l
#################
Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
...
Device    Boot     Start        End    Blocks  Id System
/dev/sdb1 *         2048    2099199   1048576  83 Linux
/dev/sdb2        2099200   35653631  16777216  82 Linux swap / Solaris
/dev/sdb3       35653632  245368831 104857600  83 Linux
/dev/sdb4      245368832 1084229631 419430400   5 Extended
/dev/sdb5      245370880  664801279 209715200  83 Linux
/dev/sdb6      664803328 1073747967 204472320  83 Linux

Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
...
Device    Boot     Start        End     Blocks  Id System
/dev/sda1 *         2048    1026047     512000  83 Linux
/dev/sda2        1026048 3907028991 1953001472  8e Linux LVM

Disk /dev/sdc: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
...
Disklabel type: gpt
Disk identifier: 53BC10EE-39CD-4B83-AB30-1DC63DF7E35C
Device           Start          End   Size Type
/dev/sdc1         2048      2099199     1G EFI System
/dev/sdc2      2099200   1050675199   500G Linux LVM
#################

After recording the above listings I listed the partitions in the grub 
shell like this:

ls (hd0,msdos1) =>
Partition hd0,msdos1: Filesystem type ext* ... UUID e6edb5f1... 
Partition start at 2048 ...

ls (hd0,msdos2) => ...

...

I saw that the UUID's and the "Partition start at" numbers all 
corresponded to /dev/sdb as listed by blkid. So that was the smoking gun 
that grub is swapping the drive designations.

I hope the above proves useful to others in a similar predicament.

Now, does anyone have a clue as to why both grub and fdisk are swapping 
the disk numbers?

Alan



More information about the lfs-support mailing list