Red Hat Bugzilla – Bug 451764
live images fail to boot because /sbin/udevtrigger is missing
Last modified: 2008-06-18 17:41:54 EDT
Description of problem:
Recently created live images fail to boot because /sbin/udevtrigger is
/init: line 253: /sbin/udevtrigger: No such file or directory
Bug in intramfs /init detected. Dropping to a shell. Good luck!
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a live image with recent udev
2. Boot this live image
live image won't boot
live image boots
udevtrigger is gone... see changelog... use "/sbin/udevadm trigger"
Binaries *CANNOT* just go away from udev like this. udevtrigger is used in
multiple places and having it go away is going to mean breaking compatibility
across them between releases or maintaining looking for lots of different paths
which is lame :(
it is not a binary, which is gone.. it is a symlink
"udevtrigger is used in multiple places" ??? where? It should only be used once
per bootup and this would be start_udev.
I can create those symlinks nevertheless in the specfile, though support for the
symbolic link logic may be removed in the future...
It's used in the initrd for livecds, it's used in the initrd for the installer,
it would be used in the general case initrd except for the fact that we ripped
out udev from the regular initrd due to this sort of nonsense regularly occurring.
udev was never in the regular initrd due to other reasons
this is rawhide, btw.. things can change
(In reply to comment #6)
> udev was never in the regular initrd due to other reasons
Bzzt, wrong. It was there in the past. We pulled it out and rolled our own
because I got tired of dealing with the fact that udev can't actually go six
months without changing the way it works
(In reply to comment #7)
> this is rawhide, btw.. things can change
Things can change but there's a lot to be said for avoiding gratuitous change
which adds zero benefit. Because we especially end up moving a lot of things
like udev back to older releases as we end up doing newer kernels on older releases.
udevadm exists since udev-116 ...
feel free to object on email@example.com
(In reply to comment #8)
> Bzzt, wrong. It was there in the past. We pulled it out and rolled our own
> because I got tired of dealing with the fact that udev can't actually go six
> months without changing the way it works
so in fact, instead of working with upstream and me on the problem, you decided
to roll your own thing and duplicate all the effort.
Upstream was all but actively hostile and this was before you were maintaining
udev iirc. And it's not like "create device nodes based on sysfs" is all that
But whatever, we'll carry hackjobs so that Kay can continue his continued "let's
change the world every six months". I'm just saddened by the fact that nothing
has changed there in three years.
Fixes pushed for mklivinitrd and anaconda; the former will likely get built
later today as Peter is also doing some plymouth stuff in mkinitrd.