imho this is completely stupid, is there any way to avoid this and still update udev

Well that's what motivated this thread (wanting udev to start after localmount iff we know we don't have any esoteric devices which need setting by udev before localmount can start) but I have no idea how things will work out going into the future. One would hope the udev developers would settle for "all partitions are mounted before starting udev OR initramfs is mounted" as a requirement, vs strict "initramfs is mounted" but I can't be overly optimistic.

<rant>
I can just imagine the "systemd needs this" argument coming, in the same way as it has been pushed in the kernel to apparently justify ignoring portability concerns ie: building a box without cgroups and associated paraphernalia (concerns raised in that regard that I've read simply get no response.) And ofc, it'll again be a mess created by the software that needs it, which everyone else will spend years picking up the pieces for. Until the next round of "ooh.. shiny."
</rant>

Quote:

but if there is any relation to the news about the udev upgrade, than the msg was talking about /usr only, thus the gentoo devs got lazy and may cause unneeded serious computer breakage for users, this must be corrected at once and notify all that /var on separate mounts is affected too.

That's a good point; you might want to raise it in this topic (although I wouldn't go calling anyone lazy - just mention it as overlooked ;)

imho this is completely stupid, is there any way to avoid this and still update udev

Well that's what motivated this thread (wanting udev to start after localmount iff we know we don't have any esoteric devices which need setting by udev before localmount can start) but I have no idea how things will work out going into the future. One would hope the udev developers would settle for "all partitions are mounted before starting udev OR initramfs is mounted" as a requirement, vs strict "initramfs is mounted" but I can't be overly optimistic.

<rant>
I can just imagine the "systemd needs this" argument coming, in the same way as it has been pushed in the kernel to apparently justify ignoring portability concerns ie: building a box without cgroups and associated paraphernalia (concerns raised in that regard that I've read simply get no response.) And ofc, it'll again be a mess created by the software that needs it, which everyone else will spend years picking up the pieces for. Until the next round of "ooh.. shiny."
</rant>

Quote:

but if there is any relation to the news about the udev upgrade, than the msg was talking about /usr only, thus the gentoo devs got lazy and may cause unneeded serious computer breakage for users, this must be corrected at once and notify all that /var on separate mounts is affected too.

That's a good point; you might want to raise it in this topic (although I wouldn't go calling anyone lazy - just mention it as overlooked

major overlooked... bordering in laziness.._________________Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein
ProjectFootball

Ok, after an unsuccessful attempt last night (box booted but I don't believe /usr did) - tonight I tried, but only applied the 3 patches, did not modify /etc/fstab (lvm partitions are still referenced as /dev/vg...) didn't modify any runlevels - and this box boots fine and as far as I can tell everything works. I'm going to try this process on another box.

EDIT: Confirmed on second box - set CONFIG_DEVTMPFS in kernel and recompiled, reboot, ok, applied 3 patches - reboot all ok but for gnome-terminal - ssh'd into box set CONFIG_DEVTMPFS_MOUNT in kernel and recompiled, reboot, ok.

Ok, after an unsuccessful attempt last night (box booted but I don't believe /usr did) - tonight I tried, but only applied the 3 patches, did not modify /etc/fstab (lvm partitions are still referenced as /dev/vg...) didn't modify any runlevels - and this box boots fine and as far as I can tell everything works. I'm going to try this process on another box.

EDIT: Confirmed on second box - set CONFIG_DEVTMPFS in kernel and recompiled, reboot, ok, applied 3 patches - reboot all ok but for gnome-terminal - ssh'd into box set CONFIG_DEVTMPFS_MOUNT in kernel and recompiled, reboot, ok.

did not modify fstab or runlevels

AFAICT both boxes are working correctly

afaik, CONFIG_DEVTMPFS is no good, I'd wait for neddy to come and comment on this.

btw, what three patches?_________________Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein
ProjectFootball

Ok, after an unsuccessful attempt last night (box booted but I don't believe /usr did) - tonight I tried, but only applied the 3 patches, did not modify /etc/fstab (lvm partitions are still referenced as /dev/vg...) didn't modify any runlevels - and this box boots fine and as far as I can tell everything works. I'm going to try this process on another box.

EDIT: Confirmed on second box - set CONFIG_DEVTMPFS in kernel and recompiled, reboot, ok, applied 3 patches - reboot all ok but for gnome-terminal - ssh'd into box set CONFIG_DEVTMPFS_MOUNT in kernel and recompiled, reboot, ok.

did not modify fstab or runlevels

AFAICT both boxes are working correctly

w00t! that's great Trog Dog :-)

Can I check, when you say you "didn't modify any runlevels" do you mean that udev is still in sysinit? If so, it'll be starting before localmount (which is in boot; rc-update show), which means you're not actually using the new setup: to be sure all devices started by udev are ok, now and into the future, udev scripts must be able to access /usr (for pci-ids and hwdb, iirc) and afaict, technically there's no knowing what other partitions they might access (or at least, that's the new position.) It's a safe bet they're not going to need /home, /tmp or anything like /usr/{src,portage} but they might for example, install into /opt, or need access to /var.

I have to admit I don't understand how pushing the resolution of the chicken-and-egg nature of, say, needing a udev-configured device to access /usr, while also needing that same partition to run the udev initscripts, is any easier to handle without root (assuming ofc that the root device doesn't need initialising in userspace- which would be the traditional reason to need an initrd.) I guess the reasoning is that they have to support the initrd, and they don't want to support the traditional method, which I can understand. It's just a shame imo; if they'd had a similar process in terms of making such massive changes to user-space/ system-administration that Gentoo has for GLEPs, I really don't believe they'd have got through it, and scripts that were playing silly buggers would have been sorted out (perhaps by conceding pci-ids and hwdb should be installed to root if the distro/ user so configured it, and either redoing the 2-phase sequence they tried to implement before, or just insisting that device-initialisation be installed to root. After all, if it's going to be run by udev during sysinit, it'll be run as root.)

wrt lvm, what version are you on? I was running lvm2-2.02.73 for over a year, and everything was fine with udev; it was when I upgraded to 2.02.88 that things went awry; so if it messes up you know what to do: change fstab to use /dev/mapper/vg-lv as opposed to /dev/vg/lv. If you check /etc/init.d/udev in the populate_dev() function, you'll see the following comment:

Code:

# we can speed up booting under these conditions:
# * using devtmpfs so kernel creates device nodes for us
# * only using kernel created device nodes at boot
# (in /etc/fstab and elsewhere)

/dev/mapper is a kernel-created node, and prior to the upgrade to 2.02.88, lvm was creating the /dev/vg/lv nodes in its startup. The lvm initscript still passes the parameter in /lib/rcscripts/addons/lvm-start.sh -- it runs /sbin/vgscan --mknodes but on my machine at least, that doesn't set up the nodes (or maybe they get overwritten when udev starts, I'm not sure.) I was having to reboot and run the scan manually, which gave me a warning for each logical volume, about how udev was supposed to have made the nodes.

No, that's incorrect: udev will now require that setting, going forwards (it was mentioned on gentoo-dev ml by Greg KH sometime in last few months.)
You can see that it's good anyway by the comment I quoted above from /etc/init.d/udev

Given that, I think it's wise to use the _MOUNT option as well, even if udev-mount does always mount it for you- never know, for example, when you'll be booting into a rescue shell; at that point your lvm drives will still come up if you have the _MOUNT option and are using kernel-device names (/dev/mapper/vg-lv) in fstab.

Can I check, when you say you "didn't modify any runlevels" do you mean that udev is still in sysinit? If so, it'll be starting before localmount (which is in boot; rc-update show), which means you're not actually using the new setup: to be sure all devices started by udev are ok, now and into the future, udev scripts must be able to access /usr (for pci-ids and hwdb, iirc) and afaict, technically there's no knowing what other partitions they might access (or at least, that's the new position.) It's a safe bet they're not going to need /home, /tmp or anything like /usr/{src,portage} but they might for example, install into /opt, or need access to /var.

wrt lvm, what version are you on? I was running lvm2-2.02.73 for over a year, and everything was fine with udev; it was when I upgraded to 2.02.88 that things went awry; so if it messes up you know what to do: change fstab to use /dev/mapper/vg-lv as opposed to /dev/vg/lv. If you check /etc/init.d/udev in the populate_dev() function, you'll see the following comment:

I'll try messing around with the runlevels to see what works and what doesn't.

Yeah- make sure you use /dev/mapper/vg-lv in fstab as the first thing (and test it boots okay), as you need that before you put udev in boot runlevel. (Or you'll need to boot with init=/bin/bash to edit fstab, or switch runlevels for udev and edit /etc/conf/udev to revert. If you do end up in a rescue shell and need lvm drives, use vgscan --mknodes before mount.)

Don't forget to add sysfs and udev-mount to sysinit -- those can always stay there, it doesn't hurt them being there when udev is in sysinit (the default).

Whenever udev is in boot, you must have initramfs="no" in /etc/conf.d/udev, and whenever it's in sysinit, you must have initramfs="yes" (or comment the line out.)

That's what makes things a bit tricky, as you need to edit the file whenever you switch udev runlevel, or you'll end up back in a rescue shell.

I'll try messing around with the runlevels to see what works and what doesn't.

Yeah- make sure you use /dev/mapper/vg-lv in fstab as the first thing (and test it boots okay), as you need that before you put udev in boot runlevel. (Or you'll need to boot with init=/bin/bash to edit fstab, or switch runlevels for udev and edit /etc/conf/udev to revert. If you do end up in a rescue shell and need lvm drives, use vgscan --mknodes before mount.)

Don't forget to add sysfs and udev-mount to sysinit -- those can always stay there, it doesn't hurt them being there when udev is in sysinit (the default).

Whenever udev is in boot, you must have initramfs="no" in /etc/conf.d/udev, and whenever it's in sysinit, you must have initramfs="yes" (or comment the line out.)

That's what makes things a bit tricky, as you need to edit the file whenever you switch udev runlevel, or you'll end up back in a rescue shell.

Wrt udev-181 and above, I read that the only difference is that there is no longer support for retrying devices that failed first time around (eg if a file needed is on /usr which wasn't mounted) which is what udev-postmount did. With our patches, that's not an issue, as we have localmount up before udev. I haven't tried it yet- not going to til it goes stable, but for anyone who's going to upgrade, this method should work (though you'll have to take care with the patch. If anyone has copies of the udev and udev-mount scripts for 181+ then please post them and I'll do a patch if you've found it hard, or even better post working patches ;-) Anyone trying unstable udev in a VM?

Oh, there's also this method which is an earlymount init script that mounts selected partitions before udev, though it appears to have some teething troubles. I'm going to stick with our method, as I prefer being able to start after localmount and feel better knowing that it and all of its dependencies, whatever they might be going into the future, are taken care of, since I know I don't need any udev-configured devices to get local drives mounted on my machines. (This is also where udev used to start in the boot sequence.) It also makes fsck a lot simpler (ie it works in the standard manner.)

Thank you for this thread. I was planning to (eventually) find the time to move /usr back to / with /usr/portage keeping what is now that partition when I saw this. I don't want /var in /, however, so I guess I'm going to have to do this or an initrd ... and I really don't want to do an initrd if I can help it.

Now if only I can find the time to sit down and get this working on my systems._________________krenshala
:wq

Thank you for this thread. I was planning to (eventually) find the time to move /usr back to / with /usr/portage keeping what is now that partition when I saw this. I don't want /var in /, however, so I guess I'm going to have to do this or an initrd ... and I really don't want to do an initrd if I can help it.

Hi krenshala; yeah that's exactly how I felt about it-- I've never needed an initrd since I have what I need (and only what I need) to mount local filesystems compiled into the kernel, and I don't have any encryption, just non-root lvm and a load of partitions.

Quote:

Now if only I can find the time to sit down and get this working on my systems.

Well let us know how you get on/ if you need any help. I'm in #friendly-coders on chat.freenode.net when I'm online, if you need live assistance. (My nick is 'igli'.)
Make sure you follow instructions in first post closely, particularly about getting everything you need in the correct runlevels: sysfs and udev-mount added to sysinit, udev deleted from sysinit and added to boot. udev must be in boot runlevel whenever you have initramfs="no" in /etc/conf.d/udev. Don't do that first though!

I'd apply the patches first, without initramfs added to the config file, just to make sure they boot clean. Then, set up CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT, and change /dev/vg/lv to /dev/mapper/vg-lv for any lvm volumes in /etc/fstab and make sure the system boots with those. Then you can try adding the parameter and changing udev's runlevel.

You can leave sysfs and udev-mount in sysinit: it's when you change udev's runlevel that you must have initramfs correct (="no" when udev is in boot, ="yes" or unset when udev is in sysinit.)

Lennart Poettering 24.04.2012 +4
you are mistaken, we support /var split off just fine, without initrd. Same for /home. These splits make a lot of sense and are not cumbersome to implement, hence we support them.﻿

_________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

Lennart Poettering 24.04.2012 +4
you are mistaken, we support /var split off just fine, without initrd. Same for /home. These splits make a lot of sense and are not cumbersome to implement, hence we support them.﻿

so according to you, I can upgrade without any problems?_________________Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein
ProjectFootball

Don't quote me on it yet, I really can't tell unless I've tried it myself._________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

I follow -dev mailing list pretty well. Right now, /var is supported. That may change in the future tho. That is what is being said on -dev. At some point, /var may be needed like /usr is about to be needed.

Me and what I see on my box; I see errors that I think are because /var is not mounted. The complaints are that it can't write the PID files in /var. I wish I could tell dracut to mount and /usr and /var then let the system switch_root and boot. My system does boot since the services do start later on. So, this is not a problem right now.

Your mileage may vary. I would have a binpkg of the older udev, the instructions on how to chroot and a bootable CD/DVD/USB stick thingy if it were me. It may ward off the evil broken OS spirits.

I follow -dev mailing list pretty well. Right now, /var is supported. That may change in the future tho. That is what is being said on -dev. At some point, /var may be needed like /usr is about to be needed.

Me and what I see on my box; I see errors that I think are because /var is not mounted. The complaints are that it can't write the PID files in /var. I wish I could tell dracut to mount and /usr and /var then let the system switch_root and boot. My system does boot since the services do start later on. So, this is not a problem right now.

Your mileage may vary. I would have a binpkg of the older udev, the instructions on how to chroot and a bootable CD/DVD/USB stick thingy if it were me. It may ward off the evil broken OS spirits.

no dracut here, I'm trying to keep my system junk free._________________Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein
ProjectFootball

The info I was trying to provide wasn't about dracut. I would suspect that you would get the same errors if you used any other init thingy, unless you had it mount /var as well as /usr before switching root.

The point was, /var is fine without a init thingy, right now. It may change soon tho since /var has been discussed and I see the errors on my machine already. I have all but /boot and / on LVM.

Also, there is talk of moving /bin and /sbin to /usr/*bin as links in the future. In other words, /bin and /sbin doesn't contain anything, it is just a link to the /usr bins. At that point, everything will be in /usr. I'm not sure what sort of init thingy we will all need then.

This, to me, is starting to look a LOT like winders. Next it will be C: for the hard drive.