Bug 136058 - udev_start crashes in initrd (twice)
udev_start crashes in initrd (twice)
Status: CLOSED DUPLICATE of bug 136005
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Harald Hoyer
: 136104 (view as bug list)
Depends On:
Blocks: FC3Blocker
  Show dependency treegraph
Reported: 2004-10-17 05:31 EDT by Alexandre Oliva
Modified: 2007-11-30 17:10 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 14:06:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
diff between the unpacked src packages (038-1 <-> 038-2) (1.88 KB, text/plain)
2004-10-17 18:45 EDT, Nils Philippsen
no flags Details

  None (edit)
Description Alexandre Oliva 2004-10-17 05:31:48 EDT
Description of problem:
Re-creating initrd after upgrading to latest udev introduces crashes,
and even failure to boot up.  I suspect the issues might be related
with raid and/or LVM, since I have both on the boxes I tested.

Version-Release number of selected component (if applicable):
udev-038-2 mkinitrd-4.1.17-1

How reproducible:
Every time

Steps to Reproduce:
1.Rebuild an initrd for the kernel you're running, with the same
mkinitrd options, but using the latest mkinitrd and udev
Actual results:
One x86_64 box with root on LVM and extra filesystems on LVM on RAID
1, with USB and Firewire component disks, failed to boot up.  An ia32
box with root on LVM on RAID 1 on internal IDE booted up ok, but print
messages about udev crashes while initrd ran.

Expected results:
No such messages, and reliable boot.

Additional info:
Replacing udev.static with a previous binary (035-1?) fixes it.
Comment 1 Matt Underwood 2004-10-17 08:12:09 EDT
I don't have RAID. Well my motherboard (Asus A7N8X) claims to have
SATA RAID, but I'm only using a single IDE HD. However it looks like I
an using LVM (new to me in FC3t3)

During boot udev_start gives two error reports, my boot messages look
like this,

root (hd0,1)
 Filesystem type is ext2fs, partition type 0x83
kernel /vmlinuz-2.6.8-1.624 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
   [Linux-bzImage, setup=0x1400, size=0x155e8a]
initrd /initrd-2.6.8-1.624.img
   [Linux-initrd @ 0x37f01000, 0xee655 bytes]

Uncompressing Linux... Ok, booting the kernel.
audit(1098018215.886:0): initialized
Red Hat nash version 4.1.17 starting
ERROR: /sbin/udevstart exited abnormally!
ERROR: /sbin/udevstart exited abnormally!
  Reading all physical volumes.  This may take a while...
  No volume groups found
  No volume groups found
  No volume groups found
mount: error 6 mounting ext3
mount: error 2 mounting none
switchroot: mount failed: 22
umount /initrd/dev failed: 2
Kernel panic - not syncing: Attempted to kill init!

I have an XP installation on /dev/hda1, /dev/hda2 is my Linux boot
partition with /dev/hda3 being my main linux volume.
Comment 2 Colin Walters 2004-10-17 15:44:38 EDT
I also get this with udev-0.38-2.x86_64.  Downgrading to 0.38-1 and regenerating
my initrd fixed the problem.

I'm also on x86_64, with LVM.
Comment 3 Nils Philippsen 2004-10-17 18:09:59 EDT
The same here, only on i386.
Comment 4 Nils Philippsen 2004-10-17 18:11:27 EDT
*** Bug 136104 has been marked as a duplicate of this bug. ***
Comment 5 Nils Philippsen 2004-10-17 18:17:46 EDT
Well, not entirely the same -- these are pure Linux boxen with /boot
on /dev/hda1 and my volume group being on /dev/hda2 (in case of the
laptop) and /dev/hda1,/dev/hdb1 (in case of the server).
Comment 6 Nils Philippsen 2004-10-17 18:19:20 EDT
Make that /dev/hda2,/dev/hdb1. Still no quantum partitions here ;-).
Comment 7 Nils Philippsen 2004-10-17 18:45:46 EDT
Created attachment 105358 [details]
diff between the unpacked src packages (038-1 <-> 038-2)

As this diff shows, there hasn't changed much between 038-1 and 038-2,
especially nothing that should affect udevstart as adversely as it apparently
did (for my uninitiated eyes). I'll try whether rebuilding the package changes
anything (i.e. use initrds that are built with rebuilt 038-1 and 038-2 udev).
Comment 8 Nils Philippsen 2004-10-17 18:51:43 EDT
Hmm while rebulding I noticed some dubious messages:

Linking udev:                                                         [OK]
  udev_add.o(.text+0xb7b): In function `udev_add_device':
  /home/nils/redhat/BUILD/udev-038/udev_add.c:254: warning: Using
'getgrnam' in
   statically linked applications requires at runtime the shared
libraries from
   the glibc version used for linking
  ing: Using 'getpwnam' in statically linked applications requires at
runtime t
  he shared libraries from the glibc version used for linking

I wonder if that might be related (udevstart.static is just a link to
udev.static) -- I doubt that we pack an entire glibc into the initrds...
Comment 9 Nils Philippsen 2004-10-17 19:13:33 EDT
I tried two kernels with rebuilt 038-1 and 038-2 and all attempts gave
the above error instead of booting.

I suspect that the old udev-038-1 package was somehow built
differently, i.e. the warning of the above comment didn't harm then
but does harm now, probably due to changes in the build tool chain,
likely in how the binaries were linked. I could imagine that in the
working release these symbols were marked to be only resolved when
they were encountered, not when starting the program.

NB: I'm only a layman when it comes to the innards of linking so I
might just be talking nonsense ;-).
Comment 10 Nils Philippsen 2004-10-17 19:16:46 EDT
This might be related to bug #136027.
Comment 11 Nils Philippsen 2004-10-17 19:18:10 EDT
Or even bug #111298.
Comment 12 Warren Togami 2004-10-17 22:15:26 EDT
jakub any thoughts?
Comment 13 Bill Nottingham 2004-10-17 23:05:34 EDT
See bug 136005.
Comment 14 Barry K. Nathan 2004-10-17 23:56:05 EDT
If I rebuild udev-0.38-2 on a 20041014 rawhide snapshot, I get the
warnings mentioned in comment #8, but the resulting package does not
have this bug (i.e. it works, like 0.38-1).
Comment 15 Barry K. Nathan 2004-10-18 00:07:25 EDT
(Oops, I meant udev-038-2 in my last comment. Anyway...)

If I take the system that compiled a working udev-038-2 (see comment
14), and I upgrade glibc from 2.3.3-67 to 2.3.3-68, then it compiles a
broken udev-038-2 rather than a working one.

I don't think I have time to look at this in any more detail, but I
hope this helps nonetheless!
Comment 16 Harald Hoyer 2004-10-18 07:46:43 EDT

*** This bug has been marked as a duplicate of 136005 ***
Comment 17 Red Hat Bugzilla 2006-02-21 14:06:22 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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