Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 452799 - segfault in libdevmapper booting with encrypted root + plymouth
Summary: segfault in libdevmapper booting with encrypted root + plymouth
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: plymouth
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 452907 454473 (view as bug list)
Depends On:
Blocks: F10Alpha, F10AlphaBlocker
TreeView+ depends on / blocked
 
Reported: 2008-06-25 06:12 UTC by Harald Hoyer
Modified: 2008-08-14 12:52 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-08-13 04:32:37 UTC


Attachments (Terms of Use)
nash segfault in libdevmapper (deleted)
2008-06-25 06:12 UTC, Harald Hoyer
no flags Details

Description Harald Hoyer 2008-06-25 06:12:00 UTC
- 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 06:12:00 UTC
Created attachment 310224 [details]
nash segfault in libdevmapper

Comment 2 Jeremy Katz 2008-07-01 20:54:56 UTC
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 21:27:35 UTC
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 21:27:47 UTC
*** Bug 452907 has been marked as a duplicate of this bug. ***

Comment 5 Ray Strode [halfline] 2008-07-02 01:13:04 UTC
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-02 01:20:02 UTC
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-02 01:30:09 UTC
(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-09 03:03:09 UTC
*** Bug 454473 has been marked as a duplicate of this bug. ***

Comment 9 Jeremy Katz 2008-07-09 03:05:21 UTC
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 17:42:20 UTC
(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 20:02:27 UTC
Hi Sven, known issue that Peter is fixing today.

Comment 12 Matthias Clasen 2008-08-07 04:15:15 UTC
So, is it fixed by now ?

Comment 13 Ray Strode [halfline] 2008-08-13 04:32:37 UTC
yup


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