Problems booting GRML via fromhd
Hi,
We use GRML as rescue system on our machines. The /boot partition (which sits on a software raid1) of the main system includes the GRML-Kernel, initrd and squashfs so in case someone unintentionally removes libc6 or does some other bad things it's possible to recover the machine via the grml boot option in grub.
the good thing is that this works if the /boot partition is on ide devices because the ide drivers are compiled into the kernel and the raid code in the kernel autostarts the raid.
the bad thing: it doesn't work with our new dell boxes with mpt fusion controllers. the second problem here is that these boxes don't have ps/2 keyboard connectors and grml doesn't recognise the usb keyboard when it puts me into the rescue shell ... argh.
here is what i did to fix these problems:
- when grml loads the usb kernel modules it also tries to insmod usbhid.ko but this one has unknown symbols because ff-memless.ko has to be loaded first. so i copied ff-memless.ko to the initrd and added it to the list of usb.modules. cool. now i have a keyboard.
- the next thing was that the sysfs-scsi-detection code did not find my fusion mpt controller. after reading /modules/scsi/scsi-modules.txt i knew why: because it was missing from there. after adding the entries for it i ended with a correctly detected controller but without a raid. how is the scsi-modules.txt file created? by hand? maybe it would be better to generate it from /lib/modules/$(uname -r)/modules.{dep,pcimap} because in these files the mpt drivers where referenced ...
- ok so after having the devices i needed to start the raid1 to access the filesystem. unfortunately there is no mdadm in the initrd image of grml so i had to compile a static version of mdadm and put it in /static. after this i added some code to assemble all arrays in case there exists a boot option fromhd=/dev/md*
ok so now everything works. great!
btw: grml is a really cool tool
cheers,
* Philipp Richter philipp.richter@linbit.com [20070821 17:36]:
We use GRML as rescue system on our machines. The /boot partition (which sits on a software raid1) of the main system includes the GRML-Kernel, initrd and squashfs so in case someone unintentionally removes libc6 or does some other bad things it's possible to recover the machine via the grml boot option in grub.
the good thing is that this works if the /boot partition is on ide devices because the ide drivers are compiled into the kernel and the raid code in the kernel autostarts the raid.
the bad thing: it doesn't work with our new dell boxes with mpt fusion controllers. the second problem here is that these boxes don't have ps/2 keyboard connectors and grml doesn't recognise the usb keyboard when it puts me into the rescue shell ... argh.
Ok.
here is what i did to fix these problems:
- when grml loads the usb kernel modules it also tries to insmod usbhid.ko but
this one has unknown symbols because ff-memless.ko has to be loaded first. so i copied ff-memless.ko to the initrd and added it to the list of usb.modules. cool. now i have a keyboard.
Great, thanks for information.
- the next thing was that the sysfs-scsi-detection code did not find my fusion
mpt controller. after reading /modules/scsi/scsi-modules.txt i knew why: because it was missing from there. after adding the entries for it i ended with a correctly detected controller but without a raid. how is the scsi-modules.txt file created? by hand? maybe it would be better to generate it from /lib/modules/$(uname -r)/modules.{dep,pcimap} because in these files the mpt drivers where referenced ...
Thanks for information.
We use http://grml.org/files/devel/create-scsi-mod-file.sh for generating the scsi-modules.txt file.
- ok so after having the devices i needed to start the raid1 to access the
filesystem. unfortunately there is no mdadm in the initrd image of grml so i had to compile a static version of mdadm and put it in /static. after this i added some code to assemble all arrays in case there exists a boot option fromhd=/dev/md*
Thanks again for the hint.
ok so now everything works. great!
Excellent. Thanks a lot for sharing your patches! I'll take a closer look at them. Regarding the mdadm stuff I hope to be able to use live-initramfs in the near future which should give us more options for mdadm/lvm/... out-of-the-box in the initrd/initramfs part of booting.
btw: grml is a really cool tool
Thanks :)
regards, -mika-
On Tuesday 21 August 2007 20:26:43 Michael Prokop wrote:
- the next thing was that the sysfs-scsi-detection code did not find my
fusion mpt controller. after reading /modules/scsi/scsi-modules.txt i knew why: because it was missing from there. after adding the entries for it i ended with a correctly detected controller but without a raid. how is the scsi-modules.txt file created? by hand? maybe it would be better to generate it from /lib/modules/$(uname -r)/modules.{dep,pcimap} because in these files the mpt drivers where referenced ...
Thanks for information.
We use http://grml.org/files/devel/create-scsi-mod-file.sh for generating the scsi-modules.txt file.
hmm. the fusion mpt driver resides in a different location (/lib/modules/$(uname -r)/kernel/drivers/message/fusion) so you have to add this directory to the 'find'. but then again, the simple dependency logic does not work here because there are multiple dependencies and modinfo prints them in random order (for mptsas.ko to load you need to load mptbase.ko and mptscsih.ko in this order). modprobe would be cool here ... any reason not to use it?
Excellent. Thanks a lot for sharing your patches! I'll take a closer look at them. Regarding the mdadm stuff I hope to be able to use live-initramfs in the near future which should give us more options for mdadm/lvm/... out-of-the-box in the initrd/initramfs part of booting.
this sounds good. recent kernel/initramfs combinations are really powerful and flexible regarding the device of the root filesystem. for which release is the live-initramfs transition planned?
cheers bzw. sers,
* Philipp Richter philipp.richter@linbit.com [20070822 16:45]:
On Tuesday 21 August 2007 20:26:43 Michael Prokop wrote:
- the next thing was that the sysfs-scsi-detection code did not find my
fusion mpt controller. after reading /modules/scsi/scsi-modules.txt i knew why: because it was missing from there. after adding the entries for it i ended with a correctly detected controller but without a raid. how is the scsi-modules.txt file created? by hand? maybe it would be better to generate it from /lib/modules/$(uname -r)/modules.{dep,pcimap} because in these files the mpt drivers where referenced ...
Thanks for information.
We use http://grml.org/files/devel/create-scsi-mod-file.sh for generating the scsi-modules.txt file.
hmm. the fusion mpt driver resides in a different location (/lib/modules/$(uname -r)/kernel/drivers/message/fusion) so you have to add this directory to the 'find'. but then again, the simple dependency logic does not work here because there are multiple dependencies and modinfo prints them in random order (for mptsas.ko to load you need to load mptbase.ko and mptscsih.ko in this order). modprobe would be cool here ... any reason not to use it?
modprobe of busybox was/is too broken. :( But when switching to the initramfs approach we shouldn't have to deal with that any further.
Excellent. Thanks a lot for sharing your patches! I'll take a closer look at them. Regarding the mdadm stuff I hope to be able to use live-initramfs in the near future which should give us more options for mdadm/lvm/... out-of-the-box in the initrd/initramfs part of booting.
this sounds good. recent kernel/initramfs combinations are really powerful and flexible regarding the device of the root filesystem. for which release is the live-initramfs transition planned?
Depends on the progress of development in the next few weeks.
If we have a grml 1.1 release quite soon, the initramfs-approach might hit 1.2, if we "delay" the 1.1 release some further weeks it might be part of 1.1 already. (I expect to take a closer look at live-initramfs at this weekend at Froscon - see http://www.mail-archive.com/grml@mur.at/msg01328.html for details.)
cheers bzw. sers,
greats && seas :)
regards, -mika-
Teilnehmer (2)
-
Michael Prokop -
Philipp Richter