- install F9 in a virtual machine (encryption on) - update to rawhide - see kernel oops bug 452796 - boot the old kernel - try to mkinitrd for the old kernel - see plymouth bug 452797 - install elfutils # mkinitrd -f /boot/initrd-2.6.25-14.fc9.i686-2.img $(uname -r) The default plymouth plugin (.so) doesn't exist /sbin/ldconfig: /lib/ld-linux.so.2 is not a symbolic link - reboot to old kernel, new initrd see attached screenshot may be reassigned to lvm2
Created attachment 310224 [details] nash segfault in libdevmapper
Okay, this is looking like it's mkinitrd's fault and not libdevmapper at the moment * Installed rawhide kernel on F9 (with F9 mkinitrd) and it works. * Create initrd for rawhide kernel with rawhide mkinitrd (+plymouth, due to bug 453768) and the boot fails. Interestingly, the failure is different with the non-plymouth-available initrd.
Aha, and the other key point is not having 'rhgb' in your kernel command line. If you don't have rhgb in your command line, then plymouth ends up exiting and thus when output occurs, there's nowhere to output to. So we either need to make plymouth start up always or do the check for rhgb in the kernel command line in the initrd and only startup plymouth if rhgb is specified. I suspect that the former is the path of making things reasonable. And that we then split out plymouth vs plymouth-gui and act accordingly.
*** Bug 452907 has been marked as a duplicate of this bug. ***
So to rephrase, just to make sure I understand... 1) nash sets up a pseudoterminal and passes the master fd to plymouthd while setting its own (and its children) stdin, stdout, and stderr up to the slave end of the pseudoterminal. 2) plymouth redirects all system console messages to the pseudoterminal. It watches the pseudoterminal for those messages and the messages sent from nash and nash's children and silently buffers them. These get displayed if the user presses escape and in /var/log/boot.log. 3) if plymouth sees that rhgb isn't on the command line then it exits. When it exits the pseudoterminal master fd is closed and any subsequent writes to the slave fail which leads to crashes. Is that the running theory, Jeremy?
Assuming I've got a hold on the situation, why don't we just have nash check if the ptm is still healthy after it notices that plymouth has exited/daemonized?
(In reply to comment #5) > So to rephrase, just to make sure I understand... [snip] > Is that the running theory, Jeremy? Yep (In reply to comment #6) > Assuming I've got a hold on the situation, why don't we just have nash check if > the ptm is still healthy after it notices that plymouth has exited/daemonized? Might be doable -- I'm not sure if there's a good way to tell if it's still functional or not. And my copies of the appropriate references are at the office. But it's worth asking the question of how we want things to run anyway -- there's something to be said for only having one flow for this sort of stuff just so that we reduce special case testing that's needed.
*** Bug 454473 has been marked as a duplicate of this bug. ***
FYI -- based on the discussion Ray, Peter and I had, we do want plymouth to always run. But if rhgb isn't specified, then we should do the details plugin rather than one of the pretty ones
(Hopefully related) sidenote: Currently mis-typing your password results in a segfault: init[1]: segfault at 10 ip 009d252a sp bfad0cbc error 4 in libdevmapper.so.1.02[9c4000 + 16000]
Hi Sven, known issue that Peter is fixing today.
So, is it fixed by now ?
yup