If you use a kernel or an initrd that mounts /dev on root before /etc/init.d/udev-mount then udev-mount just ignores the mounting. I think that if udev-mount finds /dev already mounted and no /dev in fstab it should remount it with the default options.
If you check https://bugs.gentoo.org/show_bug.cgi?id=359065 you will see why udev print that /dev is already mounted. /dev is not in fstab, never will be I think. looks like proper way to handle initramfs is use mount --move from initramfs to real root filesystem. Also, if you have devtmpfs, udev will use it.
> /dev is not in fstab, never will be I think. Yes, it is. If your initramfs does not touch /dev (or your kerel has that options set that automouts /dev), then /etc/init.d/udev-mount either mounts /dev from a fstab-entry, and if no such exists it mounts /dev with pre-defined sane defaults. So I think you misunderstood what this bug is about. This bug is about the following scenario: what happends if your initramfs does not mount /dev with sane defaults? Take for example genkernel and/or dracut. Should they sync their mounting options against /etc/init.d/udev-mount when it is updated? That may leave you with a old/unsafe mounted /dev, absolutely if genkernel against like now has a really old version as latest stable. Or maybe options just not suitable for gentoo. So why should not /etc/init.d/udev-mount do a "mount /dev -o remount,<sane options>" if /dev is already mounted, so all gentoo users do have the same options base, and if they want to change it udev-mount can do "mount /dev -o remount,<options-from-fstab>"
udev-mount has devtmpfs check and is fatal if it fails; and it has a method of remounting /dev if it's in /etc/fstab. if it's in /etc/fstab then that shouldn't be overridden in any scenario, it's what the user chose news item was released for the devtmpfs requirement too; with a warning of checking fstab surely this is an bug in the initramfs tools if they don't do it correctly for the new udev? last I checked, both genkernel and dracut worked for latest udev if you still think we should do something more, please reopen
(In reply to comment #3) > surely this is an bug in the initramfs tools if they don't do it correctly > for the new udev? last I checked, both genkernel and dracut worked for > latest udev I think my thought was the following, that genkernel currently mounts devtmpfs according to how udev did at the time that version of genkernel was tagged in upstream. If a bug affecting sys-fs/udev depending on how devtmpfs was mounted on /dev would appear, and it is fixed in how sys-fs/udev mounts /dev then before a person using sys-kernel/genkernel will get this bug fixed the following needs to happend: 1. A genkernel dev needs to catch this change and change genkernel upstream too (which to be honest will take some time, as we do not really have the time catching up to those bugs for all packages genkernel touches unless the manager of said portage package remembers to send us a notice) 2. A new version/patch needs to be released/added to sys-fs/genkernel in portage 3. The user needs to regenerate their initramfs This would be a zero-problem if udev remounted /dev with its own defaults unless something other is mentioned in fstab. So, yeah. It would be a bug in how genkernel mounts /dev, but it could save both user ("things does not work correctly") and udev developers ("we thought we fixed that") from some frustrations.
