Bug 452799 - segfault in libdevmapper booting with encrypted root + plymouth
segfault in libdevmapper booting with encrypted root + plymouth
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: plymouth (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
:
: 452907 454473 (view as bug list)
Depends On:
Blocks: F10Alpha/F10AlphaBlocker
  Show dependency treegraph
 
Reported: 2008-06-25 02:12 EDT by Harald Hoyer
Modified: 2008-08-14 08:52 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-13 00:32:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
nash segfault in libdevmapper (17.65 KB, image/png)
2008-06-25 02:12 EDT, Harald Hoyer
no flags Details

  None (edit)
Description Harald Hoyer 2008-06-25 02:12:00 EDT
- 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
Comment 1 Harald Hoyer 2008-06-25 02:12:00 EDT
Created attachment 310224 [details]
nash segfault in libdevmapper
Comment 2 Jeremy Katz 2008-07-01 16:54:56 EDT
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.
Comment 3 Jeremy Katz 2008-07-01 17:27:35 EDT
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.
Comment 4 Jeremy Katz 2008-07-01 17:27:47 EDT
*** Bug 452907 has been marked as a duplicate of this bug. ***
Comment 5 Ray Strode [halfline] 2008-07-01 21:13:04 EDT
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?
Comment 6 Ray Strode [halfline] 2008-07-01 21:20:02 EDT
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?
Comment 7 Jeremy Katz 2008-07-01 21:30:09 EDT
(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.
Comment 8 Jeremy Katz 2008-07-08 23:03:09 EDT
*** Bug 454473 has been marked as a duplicate of this bug. ***
Comment 9 Jeremy Katz 2008-07-08 23:05:21 EDT
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
Comment 10 Sven Lankes 2008-07-21 13:42:20 EDT
(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]
Comment 11 Ray Strode [halfline] 2008-07-28 16:02:27 EDT
Hi Sven, known issue that Peter is fixing today.
Comment 12 Matthias Clasen 2008-08-07 00:15:15 EDT
So, is it fixed by now ?
Comment 13 Ray Strode [halfline] 2008-08-13 00:32:37 EDT
yup

Note You need to log in before you can comment on or make changes to this bug.