Description of problem: Recently created live images fail to boot because /sbin/udevtrigger is missing: Loading vmlinuz0...... Loading initrd0.img..... /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): udev-124-1.fc10.i386 How reproducible: ever Steps to Reproduce: 1. Create a live image with recent udev 2. Boot this live image Actual results: live image won't boot Expected results: 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.
http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=7652450a0a21f9075ddc4325e29f38d57e0ca039 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 linux-hotplug.org
(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 much effort. 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.