Created attachment 48698 [details]
comment out rules in initramfs

Interesting, the only thing we changed was udev to print these errors;
mkninitrd must have these problems with 9.3 too.

o /dev/null should be fixed (patch attached).
o input_device error pops up cause we got the input support back to the kernel
o mount.sh is the same problem like input_device

I'm on the way to automatically comment out udev rules in initramfs when the
called tools are not available. (patch)

But we need a way to tell mkinitrd not to add these scripts to initramfs then.
Now mkinitrd does:
"cp /sbin/udev.*.sh $tmp_mnt/sbin"

We could explicitely list the needed tools somewhere or put a comment in the
scripts that is read by mkinitrd, or we give these tools a special name for
mkinitrd to pick these up. Any ideas?

*** Bug 114596 has been marked as a duplicate of this bug. ***

*** Bug 112820 has been marked as a duplicate of this bug. ***

I applied your patch, called mkinitrd and rebooted.  I still get these:

Probing IDE interface ide1...
udev[862]: run_program: exec of program '/sbin/udev.mount.sh' failed
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3] C4[C3])
ACPI: Processor [CPU] (supports 8 throttling states)
udev[866]: run_program: exec of program '/sbin/udev.mount.sh' failed
ACPI: Thermal Zone [THM0] (47 C)
udev[873]: run_program: exec of program '/sbin/udev.mount.sh' failed
Attempting manual resume
udev[878]: run_program: exec of program '/sbin/udev.mount.sh' failed
udev[879]: run_program: exec of program '/sbin/udev.mount.sh' failed
swsusp: Suspend partition has wrong signature?
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
udev[1683]: run_program: open /dev/null failed
udev[1683]: run_program: exec of program '/sbin/udev.input_device.sh' failed
md: Autodetecting RAID arrays.

I have got other udev related error messages:

[quote]

Probing IDE interface ide0...
input: ImPS/2 Logitech Wheel Mouse on isa0060/serio1
udev[815]: main: action, subsystem or devpath missing
hda: SAMSUNG SV0411N, ATA DISK drive
hdb: Maxtor 4W060H4, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: max request size: 1024KiB
hda: 78242976 sectors (40060 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
hda: cache flushes supported
 hda: hda1 hda2 hda3 < hda5 hda6 >
hdb: max request size: 128KiB
hdb: 120103200 sectors (61492 MB) w/2048KiB Cache, CHS=65535/16/63, UDMA(100)
hdb: cache flushes not supported
 hdb: hdb1 hdb2
Probing IDE interface ide1...
udev[864]: run_program: exec of program '/sbin/udev.mount.sh' failed
udev[865]: run_program: exec of program '/sbin/udev.mount.sh' failed
udev[866]: run_program: exec of program '/sbin/udev.mount.sh' failed
udev[867]: run_program: exec of program '/sbin/udev.mount.sh' failed
udev[868]: run_program: exec of program '/sbin/udev.mount.sh' failed
udev[869]: run_program: exec of program '/sbin/udev.mount.sh' failed
udev[870]: run_program: exec of program '/sbin/udev.mount.sh' failed
hdc: HITACHI DVD-ROM GD-2500, ATAPI CD/DVD-ROM drive
hdd: PIONEER DVD RW DVR-106D, ATAPI CD/DVD-ROM drive

[/quote]

For the 1st one I have no real idea (maybe connected to the mouse device ...)
but the 2nd to 8th message I would think these are related to the number of
partitions on the 2 HDDs (hda: 5 partitions, hdb: 2 partitions).

BTW: The problem is not related to beta4 only. It happens with the recent kernel
update (2.6.13-3) for beta3, too. This kernel is used for beta4 as well.

Those from #5 are known - I use the current udev which is newer than beta4.

"udev[815]: main: action, subsystem or devpath missing"
Probably fixed with the latest kernel by readding our input_device patch, cause
the upstream kernel has a broken input driver-core integration. Well it actually
causes a different error you see in the description of this bug :)

"/sbin/udev.mount.sh"
We will need a way to select the tools that get included in initramfs, will be
fixed not later than monday.

Created attachment 48709 [details]
omment out rules in initramfs 03

I have a new patch for mkinitrd that seems to fix all currently known errors in
initrd. It doesn't add bash scripts (mount...sh + input...sh) to the initramfs
image anymore, cause we have no bash there.

As the last step all udev rules are searched for program calls and all rules
with programs not available in the initramfs image will get commented out.

I applied the patch to mkinitrd and rebuilt the initrd for the recent kernel.
Results:
 - "udev[xxx]: main: action, subsystem or devpath missing" still present
 - "/sbin/udev.mount.sh" is *not* present anymore ! (at least this was solved by
the patch !)
If you need more information please call for it !

Why not have a list, which tools to include? Like INITRD_MODULES.

Excluding bash scripts is ok, but will not catch all.

Na, not a good idea.
The programs to be included is based on the selected features; each feature has
to know which program it should include.
As udev used to change quite a lot in the recent past it's difficult to know
which program one should include.
Once udev stabilizes it's quite easy to figure out which program we need.

The patch seems quite reasonable to me.
agruen, shall we include it in the mkinitrd script?

Updated mkinitrd submitted to STABLE.

Where to find this updated mkinitrd script ?
I checked ftp.gwdg.de using YOU without success ...
Any hint for the right location ?

The new package will be in RC1.

I had this problem at first with 10.1-alpha3

<3>udev[901]: run_program: exec of program '/usr/sbin/hal.hotplug' failed
<3>udev[902]: run_program: exec of program '/usr/sbin/hal.hotplug' failed

After this messages the system asks me for the root password and I should repair some filesystems manually.

I have a separate /usr-partition and udev was not able to create the necessary /dev/hda* files. Because of missing /dev/hda* files, /usr could not be mounted.

Downgrading udevd to the version from 10.1-alpha or 10.0-final fixed the problem for me. That's why I think, that there are new problems with udevd since 10.1-alpha3.

This is unrelated to this bug. I'm closing it here and move to #134898.