#18 1.01 fails if rootdev in extended part
Given a systemimager master file with the following sfdisk commands:
sfdisk -L -uM /dev/sda <<EOF || shellout
/dev/sda1 : start= 0, size= 243, Id=83
/dev/sda2 : start= , size= , Id=5
/dev/sda3 : start= 0, size= 0, Id=0
/dev/sda4 : start= 0, size= 0, Id=0
/dev/sda5 : start= , size= 15005, Id=83
/dev/sda6 : start= , size= 10244, Id=83
/dev/sda7 : start= , size= 2047, Id=82
/dev/sda8 : start= , size= , Id=83
EOF
systemconfigurator-1.01 will fail to complete boot
setup even if you explicitly list ROOTDEV = /dev/sda6.
The failure happens because systemconfigurator is
running e2label against /dev/sda5, even though it's
just the 'parent' of a number of extended partitions.
systemconfigurator should recognize when a primary
partition contains extended partitions and avoid
running any label check on it.
The error message output looks like
attempt to read block from filesystem resulted in short read while trying to open /dev/sda2
Couldn't find valid filesystem superblock
(The above two messages will happen if you run e2label by hand on the primary partition).
systemconfigurator issues error messages that look like
Use of uninitialized value in string eq at... Grub.pm
(the lines reported are 361 and 364).
In addition, systemconfigurator exits with a code that
fails to cause the systemimager master script to 'shellout'.
System is unbootable after this.
Logged In: YES
user_id=21949
Can you please provide more information. SC doesn't ever go
fatal in the event that e2label doesn't work. Although some
warnings may be thrown, this should not affect the operation
of the Grub setup code.
When using SystemImager only, SC doesn't generate the
lilo.conf or grub.conf files, so it is relying on the files
on disk. Hence, adding ROOTDEV shouldn't make a difference.
What distribution and version of Linux are you attempting to
image? What does your fstab for the image look like? Are
you trying to use Lilo or Grub? What does the appropriate
conf file look like?
Logged In: YES
user_id=512778
OOPS! First paragraph should have said /dev/sda2 where it says /dev/sda5.
You're right... it doesn't go fatal, which causes systemimager
to think that the setup succeeded, and so shellout is not executed.
The grub.conf has rootdev=/dev/sda6 on all the kernel lines,
however, it did have the kernel location wrong (/ instead of /boot).
I still think that SC should not have even tried e2label on
the sda2 partition.
grub.conf
default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
title Linux (2.4.17-smp)
root (hd0,0)
kernel /vmlinuz-2.4.17-smp ro root=/dev/sda6
initrd /initrd-2.4.17-smp.img
title Red Hat Linux (2.4.9-21)
root (hd0,0)
kernel /vmlinuz-2.4.9-21 ro root=/dev/sda6
initrd /initrd-2.4.9-21.img
title Red Hat Linux (2.4.9-21smp)
root (hd0,0)
kernel /vmlinuz-2.4.9-21smp ro root=/dev/sda6
initrd /initrd-2.4.9-21smp.img
redhat 7.2 with kernel 2.4.17+smp
fstab
LABEL=/ / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
/dev/fd0 /mnt/floppy auto noauto,owner 0 0
none /proc proc defaults 0 0
none /dev/shm tmpfs defaults 0 0
none /dev/pts devpts gid=5,mode=620 0 0
/dev/sda7 swap swap defaults 0 0
/dev/cdrom /mnt/cdrom iso9660 noauto,user,unhide,ro 0
0
nestegg:/p0/local/linux/rh7.1 /usr/local nfs ro,bg,intr,hard,proto=tcp 0 0
nestegg:/p0/local/share /usr/local/share nfs rw,bg,intr,hard,proto=tcp 0 0
I'll go try a 'repaired' grub.conf right now and let you
know what happens.
Logged In: YES
user_id=512778
My mistake... the grub.conf is correct, because the
kernel location is relative to the mount point.
Logged In: YES
user_id=512778
After further debugging/testing, the problems listed boil
down to:
1) The e2label error can be avoided by putting an 'ignore' entry
in the fstab of the image being downloaded for any primary partition
which contains extended partitions.
2) There should also be an 'ignore' entry in the fstab for any
unused partitions. In the sample sfdisk commands, more partitions
were created than were actually used in the fstab. systemconfigurator
doesn't handle this properly.
3) System unbootable is a 'real' bug in systemconfigurator.
The kernel I am using has the percraid patches added
to it, and the percraid presents its disks as 'removable'
media. This means that the BIOS mapping of the device is
not available. systemconfigurator goes to the trouble of
checking for and/or creating a device.map file, but
when it actually tries to run the setup it does not use it.
The result is that BIOS support *must* be active for the
setup to work. In my image, I had a correct device.map file,
but it wasn't used.
Modifying Boot/Grub.pm line 231 such that it uses the device.map
file results in a bootable system. For example:
$this->{bootloader_exe} --device-map=$this->{device_map_file} 2>&1 << ETO
Logged In: YES
user_id=21949
didn't realize that it wasn't picking up the device.map by
default. I'll make sure this change goes into CVS and out
with 1.3 shortly.
Logged In: YES
user_id=21949
This is fixed in the 1.9.3 development snapsnot.