Description of problem: Trying out F13 Alpha FC3, in my kickstart %post: + /usr/sbin/memtest-setup grubby recieved SIGSEGV! Backtrace (8): /sbin/grubby[0x804f898] [0x61d400] /lib/libc.so.6(strcmp+0x8)[0xbc46e8] /sbin/grubby[0x804e1d4] /sbin/grubby[0x804e32d] /sbin/grubby[0x804f644] /lib/libc.so.6(__libc_start_main+0xe6)[0xb61c96] /sbin/grubby[0x80490a1] I can run it fine on the installed system after it boots. Version-Release number of selected component (if applicable): grubby-7.0.13-1.fc13.i686
Created attachment 429600 [details] Minimal Fedora13 Install Kickstart Illustrating Problem in Post Script This is a simplified minimal kickstart file to perform the installation of Fedora 13 and then in the post-installation script, to update the kernel. This kernel update will fail due to a SIGSEGV.
Created attachment 429602 [details] Failed Grubby during Post Installation Here is the post-installation-log (generated from the previously attached kickstart) showing the failure of grubby during a yum -y update kernel.
In addition to Orion's problem where grubby is failing while adding memtest to the grub.conf file, this also happens on released Fedora 13 during the execution of a post installation script. This is causing a problem in the mass deployment of Fedora 13 workstations where the post installation script performs extreme customizations and a full update. The workstation, when booted following this, will erroneously boot into the older kernel rather than the updated kernel because the updated kernel entry is not placed into the grub.conf file. Ideally, the kickstart is designed to allow the workstation to be production-ready at its first boot. With this failure, I'll either have to put in workaround code into the kickstart file or re-update the kernel after the operating system has booted. (This problem does not appear during a kernel update after the installed version of the operating system is booted).
We hit the same problem on RH6 beta with grubby-7.0.15-1. We in fact add some modified kernel rpm in postinstall, and we get a SIGSEGV in grubby: grubby recieved SIGSEGV! Backtrace (8): /sbin/grubby[0x4080bf] /lib64/libc.so.6(+0x32a40)[0x7fea152a2a40] /lib64/libc.so.6(+0x120746)[0x7fea15390746] /sbin/grubby[0x406a42] /sbin/grubby[0x406b94] /sbin/grubby[0x407cf4] /lib64/libc.so.6(__libc_start_main+0xfd)[0x7fea1528ec5d] /sbin/grubby[0x401709] The fix for BZ592294 fixes the problem of SIGSEGV. But this still prevents grubby to work: it returns: "grubby fatal error: unable to find a suitable template" New kernel RPM is installed, but not present in grub.conf. We analyzed the problem and found that in the postinstall stage, new grubby code checks the UUID of the root partition, that fails. This is due to having "/" mounted on "/dev/root" that does not exist at this point. Note that the official kernel installs without problem, as in the RPM installation phase, "/" is mounted on an existing disk device: Taking traces on the serial console we get: -------- during the RPM installation phase --------------------- sh-4.0# chroot /mnt/sysimage sh-4.0# cat /etc/mtab /dev/sda1 / ext4 rw 0 0 <--- OK devpts /dev/pts devpts rw 0 0 tmpfs /dev/shm tmpfs rw 0 0 proc /proc proc rw 0 0 sysfs /sys sysfs rw 0 0 sh-4.0# -------- after entering the "Running post-installation scripts" phase ------ sh-4.0# cat /etc/mtab /dev/root / ext4 ro 0 0 <--- KO sh-4.0# ls -l /dev/root ls: cannot access /dev/root: No such file or directory sh-4.0# We patched grubby to reverse the UUID check and everything works fine. But unfortunately it is not the right direction ;-) So, the problem could be due to the installer ?
We are working around this problem by adding the following to the beginning of our postinstall script; this should probably allow things to work for most other installations too without the need to patch grubby: ln -s `awk '{ if ($2 == "/") print $1; }' /etc/fstab` /dev/root Probably somebody should file a bug report against anaconda as well as against grubby, since anaconda is producing a postinstall environment in which presumably (though I'm away from our test system right now so can't verify for sure) /mnt/sysimage/etc/mtab shows "/" mounted from /dev/root, but /mnt/sysimage/dev/root does not exist. So after the chroot, / appears to be mounted from /dev/root but /dev/root does not exist. I'd imagine the right thing for anaconda to do is populate the necessary nodes in /mnt/sysimage/dev before moving to the postinstall phase.
Thanks for the workaround. Re-assigning to anaconda.
This should be fixed in the next build of anaconda.
It looks this is fixed by BZ657257