2013-09-27-initramfs-required
Title Separate /usr on Linux requires initramfs
...
Due to many upstream changes, properly supporting Linux systems that
have /usr missing at boot time has become increasingly difficult.
Despite all our efforts, it already breaks in some exotic
configurations, and this trend is likely to grow worse.

Personally I've not upgraded udev and am still happily running 171-r6 without any problems.
If it breaks somewhere in the future, I may just go to a static dev.

I don't understand why you brought up udev in this context when udev doesn't have anything to do with separate /usr and is installed to / even in latest version and will stay that way.

I don't understand why you brought up udev in this context when udev doesn't have anything to do with separate /usr and is installed to / even in latest version and will stay that way.

For how long?

I consider systemd/udev and anything Poettering and his followers touch to be hostile to my system (in fact, I consider systemd to be the most hostile package in Gentoo, period)... it's only a matter of time before upstream makes a change and Gentoo, once again, sells out its users to follow upstream, since doing anything different is too much work. And once that happens, it'll be the fault of the users for having systems that his Holy Poettering doesn't like, not the shortsightedness of ill-thought "solutions" from above like the networking change that is neither persistent nor predictable and creates random headaches for admins when they least expect it, possibly when the system is physically out of reach to fix and even though assigning by MAC address was the most reasonable solution to the problem rather than the mess they created.

I don't understand why you brought up udev in this context when udev doesn't have anything to do with separate /usr and is installed to / even in latest version and will stay that way.

For how long?

I consider systemd/udev and anything Poettering and his followers touch to be hostile to my system (in fact, I consider systemd to be the most hostile package in Gentoo, period)... it's only a matter of time before upstream makes a change and Gentoo, once again, sells out its users to follow upstream, since doing anything different is too much work. And once that happens, it'll be the fault of the users for having systems that his Holy Poettering doesn't like, not the shortsightedness of ill-thought "solutions" from above like the networking change that is neither persistent nor predictable and creates random headaches for admins when they least expect it, possibly when the system is physically out of reach to fix and even though assigning by MAC address was the most reasonable solution to the problem rather than the mess they created.

There was only a small period of time, around udev-180'ish that was never in stable that installed to /usr and it was a mistake of an Gentoo packager. That problem existed only about 2 months back in 2011-2012'ish for ~arch users.
Current sys-fs/udev-204 (stable) or 208 (in ~arch, next stable) installs udevd to /sbin just like 171 does. Installs udevadm to /bin/udevadm with compability symlink to /sbin/udevadm where 171 put it. Futhermore, /lib/udev also has
same directory structure.
So from udev's point of view, it doesn't care at all if you have a separate /usr or not. And even with that news item sent, these will stay like this for users who don't care about perfectly working boot process, like not caring if keymaps
for sys-apps/kbd are not available in rescue shell or not owning a bluetooth keyboard because bluez is installed in /usr. These are just two most commonly used examples. But udev doesn't have anything to do with it. Both udev and
eudev in Portage install to /.
And if you use net.ifnames=0 or empty (or symlink to /dev/null) in /etc/udev/rules.d/80-net-name-slot.rules then the eth* wlan* names will be used and udev won't rename them at all.
I'm trying to point out there is no reason for anyone to stay at 171 thesedays. Even lowest kernel 2.6.32 for OpenVZ use is fine.

As in, you can by upgrading get the same exact result as with 171 and you don't need to hold back packages such as latest sys-apps/hwids for up-to-date hardware databases, or media-player-info for player databases, and so forth. There are multiple benefits from upgrading.

Please note I'm not advertising systemd here at all, what I'm saying is that sys-fs/udev's ebuild only uses systemd tarball but builds udev out from it for use with OpenRC and ConsoleKit. And for those that don't know me, I maintain Xfce, ConsoleKit as well and I have completely full intention of keeping the sys-fs/udev + sys-auth/consolekit + sys-auth/polkit + sys-apps/openrc with Xfce combination working, for that to get broken hell must freeze over first.

I don't understand why you brought up udev in this context when udev doesn't have anything to do with separate /usr and is installed to / even in latest version and will stay that way.

For how long?

I consider systemd/udev and anything Poettering and his followers touch to be hostile to my system (in fact, I consider systemd to be the most hostile package in Gentoo, period)... it's only a matter of time before upstream makes a change and Gentoo, once again, sells out its users to follow upstream, since doing anything different is too much work. And once that happens, it'll be the fault of the users for having systems that his Holy Poettering doesn't like, not the shortsightedness of ill-thought "solutions" from above like the networking change that is neither persistent nor predictable and creates random headaches for admins when they least expect it, possibly when the system is physically out of reach to fix and even though assigning by MAC address was the most reasonable solution to the problem rather than the mess they created.

There was only a small period of time, around udev-180'ish that was never in stable that installed to /usr and it was a mistake of an Gentoo packager. That problem existed only about 2 months back in 2011-2012'ish for ~arch users.
Current sys-fs/udev-204 (stable) or 208 (in ~arch, next stable) installs udevd to /sbin just like 171 does. Installs udevadm to /bin/udevadm with compability symlink to /sbin/udevadm where 171 put it. Futhermore, /lib/udev also has
same directory structure.
So from udev's point of view, it doesn't care at all if you have a separate /usr or not. And even with that news item sent, these will stay like this for users who don't care about perfectly working boot process, like not caring if keymaps
for sys-apps/kbd are not available in rescue shell or not owning a bluetooth keyboard because bluez is installed in /usr. These are just two most commonly used examples. But udev doesn't have anything to do with it. Both udev and
eudev in Portage install to /.
And if you use net.ifnames=0 or empty (or symlink to /dev/null) in /etc/udev/rules.d/80-net-name-slot.rules then the eth* wlan* names will be used and udev won't rename them at all.
I'm trying to point out there is no reason for anyone to stay at 171 thesedays. Even lowest kernel 2.6.32 for OpenVZ use is fine.

As in, you can by upgrading get the same exact result as with 171 and you don't need to hold back packages such as latest sys-apps/hwids for up-to-date hardware databases, or media-player-info for player databases, and so forth. There are multiple benefits from upgrading.

Please note I'm not advertising systemd here at all, what I'm saying is that sys-fs/udev's ebuild only uses systemd tarball but builds udev out from it for use with OpenRC and ConsoleKit. And for those that don't know me, I maintain Xfce, ConsoleKit as well and I have completely full intention of keeping the sys-fs/udev + sys-auth/consolekit + sys-auth/polkit + sys-apps/openrc with Xfce combination working, for that to get broken hell must freeze over first.

Again, for how long?

What if Poettering and friends decide to completely integrate udev to the point that you can't use systemd? Are you going to fork udev despite your open hostility to eudev now? Maybe instead of focusing on the people that forked to try to keep udev from going full on crazy, you should focus your efforts on combining forces with people that will force upstream's hand to stop before things get worse before you get left out in the cold too.

ANYONE hitching their ride to Poettering is a fool, IMO. He's repeatedly burned people time and time again, yet for some reason, still has a fervent following amongst a few key people in the Linux ecosystem.

And therein lies the problem with making open ended promises like "and will stay that way." I don't believe it will given Poettering's history of assimilation and hostility to the *nix way of doing things.

Also for anyone crying about systemd being associated with dropping support of a separate /usr or worrying that it's going to mean a merge of /usr too, maybe the news item shouldn't have used Poettering's long debunked screed as part of the excuse for forcing the change.

As I said elsewhere, as I get time, I'm removing udev and *kit entirely and going back to a static dev. I believe systemd and udev cause enough problems that going back to a static dev is more sane and less painful. As the maintainer of udev/systemd, you're free to disagree, but I will abandon Gentoo and Linux entirely before I allow that monstrosity to get any deeper into my system. I abandoned GNOME 3 entirely because of the interface change, but if I hadn't already abandoned that, I'd abandon it over systemd.

I find it kind of funny that mostly everyone sees linux from its desktop perspective, meanwhile its generally no better than windows or mac (or even freebsd) this way. One of the areas linux really rocks is embedded applications, where one can really benefit from having /usr cut off to a separate partition. I mentioned this approach here (https://bugs.gentoo.org/show_bug.cgi?id=485716), and from I can tell having initrd to mount /usr makes things really complicated. Without initrd things work just fine straight out of box, and in most simple cases (like no root on lvm on raid on nfs on etc) its just an unneccesary kludge. Just my 2 cents here.

Exactly, desktop is one area where Linux is mostly irrelevant but somehow it manages to dictate how one should boot one's computer

I don't understand why you brought up udev in this context when udev doesn't have anything to do with separate /usr and is installed to / even in latest version and will stay that way.

For how long?

I consider systemd/udev and anything Poettering and his followers touch to be hostile to my system (in fact, I consider systemd to be the most hostile package in Gentoo, period)... it's only a matter of time before upstream makes a change and Gentoo, once again, sells out its users to follow upstream, since doing anything different is too much work.

(...snip...)

Again, for how long?

What if Poettering and friends decide to completely integrate udev to the point that you can't use systemd? Are you going to fork udev despite your open hostility to eudev now? Maybe instead of focusing on the people that forked to try to keep udev from going full on crazy, you should focus your efforts on combining forces with people that will force upstream's hand to stop before things get worse before you get left out in the cold too.

It isn't systemd's fault. systemd works fine with /usr on a separate file system that is not pre-mounted at boot.

systemd is merely the messenger. Don't shoot the messenger.

There's no news in all of this. The message you saw is just a statement of fact, describing the status quo. Things have been this way since a while.

The message is merely a warning. You can choose to ignore it.

Don't blame us, don't abuse us, it's not our fault. We have been working on the Linux userspace since quite some time, and simply have enough of the constant bug reports regarding these issues, since they are actually very hard to track down because the failures are mostly graceful. Hence we placed this warning into the early boot process of every systemd Linux system with a split off and not pre-mounted /usr, so that people understand what is going on.

What I said about a separate /usr was from a desktop perspective.
I do understand that an embedded system would have different priorities and a separate /usr would make sense._________________Asus m5a99fx, FX 8320 - amd64-multilib, 4.11.7-zen, glibc-2.21, gcc-4.9.4, eudev
xorg-server-1.19.4 w/mesa-17.1.8, openbox, nouveau and radeon, oss4(2017)

Well, we intent to continue to make it possible to run udevd outside of
systemd. But that's about it. We will not polish that, or add new
features to that or anything.

OTOH we do polish behaviour of udev when used *within* systemd however,
and that's our primary focus.

And what we will certainly not do is compromise the uniform integration
into systemd for some cosmetic improvements for non-systemd systems.

(Yes, udev on non-systemd systems is in our eyes a dead end, in case you
haven't noticed it yet. I am looking forward to the day when we can drop
that support entirely.)

Lennart

Edit to add: I don't have a problem with Lennart wanting to integrate udev
completely into systemd and shutting out anyone from using it except with
systemd. I just don't think that a maintainer of software ebuilds should be
so openly hostile towards packages like eudev that are trying to give end
users another path. I think it sends a bad message to the users of gentoo
in general. This is all just my opinion._________________Asus m5a99fx, FX 8320 - amd64-multilib, 4.11.7-zen, glibc-2.21, gcc-4.9.4, eudev
xorg-server-1.19.4 w/mesa-17.1.8, openbox, nouveau and radeon, oss4(2017)

Last edited by Anon-E-moose on Sat Oct 05, 2013 10:28 am; edited 1 time in total

Because the vocal minority gentoo anti-systemd crowd of tinfoil fedora wearing trolls which for some reason hide behind aliases and refuse to bring their secret technical facts to mailing lists or public discussions with devs, and by pure coincidence happen to be the only truly enlightened people in regards to lennurrs freedumb stealing software dictatorship have come out to enlighten us all.

What I said about a separate /usr was from a desktop perspective.
I do understand that an embedded system would have different priorities and a separate /usr would make sense.

That's quite the opposite what would help for embedded; what would help is completed /usr merge so bin, sbin, lib, lib32, lib64, and other package-manager only-maintained directories would all be in the same partition for easy read-only mounting, like for embedded and sdcard.
As in, all this is to *help* embedded, not to take anything away from it.

What if Poettering and friends decide to completely integrate udev to the point that you can't use systemd? Are you going to fork udev despite your open hostility to eudev now? Maybe instead of focusing on the people that forked to try to keep udev from going full on crazy, you should focus your efforts on combining forces with people that will force upstream's hand to stop before things get worse before you get left out in the cold too.

I don't think it's good idea to speculate what might never become reality. However, if systemd developers make udev not work on anything else than systemd at some point, then I'll maintain patchset that makes it behave again.
Forking is something far in the future if they introduce massive incompabilities, and forking at this stage when there is no need for forking is simply retarded -- specically if you lack trust on the people reviewing the upstream
commits forward to the fork.

The door has been open for joining the team maintaining sys-fs/udev all the time, some people just decided to waste their efforts on too early fork instead.

What if Poettering and friends decide to completely integrate udev to the point that you can't use systemd? Are you going to fork udev despite your open hostility to eudev now? Maybe instead of focusing on the people that forked to try to keep udev from going full on crazy, you should focus your efforts on combining forces with people that will force upstream's hand to stop before things get worse before you get left out in the cold too.

I don't think it's good idea to speculate what might never become reality. However, if systemd developers make udev not work on anything else than systemd at some point, then I'll maintain patchset that makes it behave again.
Forking is something far in the future if they introduce massive incompabilities, and forking at this stage when there is no need for forking is simply retarded -- specically if you lack trust on the people reviewing the upstream
commits forward to the fork.

The door has been open for joining the team maintaining sys-fs/udev all the time, some people just decided to waste their efforts on too early fork instead.

Yes... and you are openly hostile to them and their fork. Your definition of a broken udev is different than theirs, but that doesn't stop you from railing against them on a regular basis even though you admit that, at some point, you would fork udev yourself.

So be consistent and either stop bashing eudev or else admit that maybe they have a point, a point that you yourself would benefit from, given your open ended promise. How long until Poettering and friends break udev enough that you give up maintaining a patch set because it's too much work to do alone?

Because the vocal minority gentoo anti-systemd crowd of tinfoil fedora wearing trolls which for some reason hide behind aliases and refuse to bring their secret technical facts to mailing lists or public discussions with devs, and by pure coincidence happen to be the only truly enlightened people in regards to lennurrs freedumb stealing software dictatorship have come out to enlighten us all.

/me unsubs from thread

Every time the subject comes up, users have talked to the devs about it... and at first the devs listened, but we've been summarily ignored this time around.

Yes... and you are openly hostile to them and their fork. Your definition of a broken udev is different than theirs, but that doesn't stop you from railing against them on a regular basis even though you admit that, at some point, you would fork udev yourself.

I have used eudev for a brief period, then realised it didn't make any sense, and went back to udev again. Really, what's the point of a fork very far in advance of speculative things to come?_________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic

I consider systemd/udev and anything Poettering and his followers touch to be hostile to my system (in fact, I consider systemd to be the most hostile package in Gentoo, period)...

Why? How?

saellaven wrote:

it's only a matter of time before upstream makes a change and Gentoo, once again, sells out its users to follow upstream, since doing anything different is too much work.

The goal of a "distribution" is not to rewrite or heavily patch things; but rather to "distribute" things, as close to upstream as possible. Or at least, that is the general case; if you want more than that, you'll have to find a devoted person or step up or do it yourself. In the end it's you, the users, that can make a change here; because for us "too much work" is the result of "a lack of time and manpower", and complaining this way won't make a change to that. Contributing will.

Don't like to follow upstream? Pick a different one. We're not forcing a particular upstream on you; nobody here says that you need to run GNOME 3 to be supported, as that is the only upstream that kind of forces it. We actually have measures in place not to force it for people who want to try their way around it; gdm has a systemd USE flag now, it might not work, but past attempts have shown that it does indeed take too much work to support it properly.

saellaven wrote:

And once that happens, it'll be the fault of the users for having systems that his Holy Poettering doesn't like, not the shortsightedness of ill-thought "solutions" from above like the networking change that is neither persistent nor predictable and creates random headaches for admins when they least expect it, possibly when the system is physically out of reach to fix and even though assigning by MAC address was the most reasonable solution to the problem rather than the mess they created.

I haven't found its predicition to fail, the one I let generate has been the one that ended up after any maintenance reboot and any future as well (as long as the network card isn't [re]moved during reboot); YMMV.

It is handy to have a choice; don't like it, you can disable it, install or write something else.

saellaven wrote:

What if Poettering and friends decide to completely integrate udev to the point that you can't use systemd? Are you going to fork udev despite your open hostility to eudev now?

If people really continue to think about systemd, I guess they will have to and will do so; but until we are that point, I guess it's going to be a long way to get there. How many people deeply care?

saellaven wrote:

Maybe instead of focusing on the people that forked to try to keep udev from going full on crazy, you should focus your efforts on combining forces with people that will force upstream's hand to stop before things get worse before you get left out in the cold too.

Consider how many people you would need for that, consider the amount of people that deeply care; I don't really see this happen, and what gain would it have for other distributions?

saellaven wrote:

ANYONE hitching their ride to Poettering is a fool, IMO. He's repeatedly burned people time and time again, yet for some reason, still has a fervent following amongst a few key people in the Linux ecosystem.

And therein lies the problem with making open ended promises like "and will stay that way." I don't believe it will given Poettering's history of assimilation and hostility to the *nix way of doing things.

Also for anyone crying about systemd being associated with dropping support of a separate /usr or worrying that it's going to mean a merge of /usr too, maybe the news item shouldn't have used Poettering's long debunked screed as part of the excuse for forcing the change.

As I said elsewhere, as I get time, I'm removing udev and *kit entirely and going back to a static dev. I believe systemd and udev cause enough problems that going back to a static dev is more sane and less painful. As the maintainer of udev/systemd, you're free to disagree, but I will abandon Gentoo and Linux entirely before I allow that monstrosity to get any deeper into my system. I abandoned GNOME 3 entirely because of the interface change, but if I hadn't already abandoned that, I'd abandon it over systemd.

I really don't see what this fuzz is all about; I'm a happy user of both, I don't think anything bad will happen to it.

You might think so, you're free to use anything else; but I don't see how stating things about Gentoo or directing yourself to Gentoo Developers is going to make a change in that, we've been having these discussions for a long while and it hasn't convinced much people.

Don't get me wrong, I don't want to stop you; I think a real movement to bring back support or the old days could be a nice idea if you can pull it off, after all Gentoo is all about choice...

But there becomes a point, that if there are just persons here and there holding these discussions, that it becomes futile; so, I suggest you to gather up forces and become a stronger voice instead.

Udev is not much more than a file based interface to the Linux kernel. The real work done in the kernel. What is is the point:

Quote:

Your definition of a broken udev is different than theirs,

What differs Eudev from Udev? I saw non-Gentoo people LOL about it, calling Eudev a copy and paste trunk. What do you see is special about Eudev?

If it is not more than a copy you would be able to do that copy at any time in the future when it is needed, because git saves the history of a tree.

With udev now a part of systemd, I have absolutely zero faith that udev will remain separately usable and frankly, after the network renaming thing, I'm not sure trusting anything to udev was sane to begin with. I will take a static dev before I let someone else break my system because I don't use it the way they think I should.

The point of eudev was to break from Poettering and friends before they inseparably integrate udev and systemd so that you must use both.

I consider systemd/udev and anything Poettering and his followers touch to be hostile to my system (in fact, I consider systemd to be the most hostile package in Gentoo, period)...

Why? How?

Through their attempts to intertwine themselves into every facet of the system, forcing their one true way on everyone else.

If I wanted a Microsoft type mentality dictated to me to use my computer, why take half measures when I could just switch to Microsoft?

Quote:

saellaven wrote:

it's only a matter of time before upstream makes a change and Gentoo, once again, sells out its users to follow upstream, since doing anything different is too much work.

The goal of a "distribution" is not to rewrite or heavily patch things; but rather to "distribute" things, as close to upstream as possible. Or at least, that is the general case; if you want more than that, you'll have to find a devoted person or step up or do it yourself. In the end it's you, the users, that can make a change here; because for us "too much work" is the result of "a lack of time and manpower", and complaining this way won't make a change to that. Contributing will.

Don't like to follow upstream? Pick a different one. We're not forcing a particular upstream on you; nobody here says that you need to run GNOME 3 to be supported, as that is the only upstream that kind of forces it. We actually have measures in place not to force it for people who want to try their way around it; gdm has a systemd USE flag now, it might not work, but past attempts have shown that it does indeed take too much work to support it properly.

I came to Gentoo from my own LFS type system as a means of automating what I was already doing because Gentoo offered flexibility. Gentoo has decided to remove flexibility. I've maintained my own overlay and have no problem doing so. But if Gentoo buys into the Poettering line, as they appear to be doing, it is no longer worth my time to stay with Gentoo, just as you argue that maintaining a large patchset makes life too hard on the Gentoo devs.

I've often thought about becoming a Gentoo dev and actually somewhat started down the road last summer before my dad became hospitalized and died, but the politics of Gentoo has always kept me away.

Quote:

saellaven wrote:

And once that happens, it'll be the fault of the users for having systems that his Holy Poettering doesn't like, not the shortsightedness of ill-thought "solutions" from above like the networking change that is neither persistent nor predictable and creates random headaches for admins when they least expect it, possibly when the system is physically out of reach to fix and even though assigning by MAC address was the most reasonable solution to the problem rather than the mess they created.

I haven't found its predicition to fail, the one I let generate has been the one that ended up after any maintenance reboot and any future as well (as long as the network card isn't [re]moved during reboot); YMMV.

It is handy to have a choice; don't like it, you can disable it, install or write something else.

Then you haven't read the mailing lists and bugs over the last year or so where people have complained about lvm being updated in portage but the initramfs not being rebuilt, which in turn made their system non-bootable or other people complaining that initramfs simply wouldn't let their computer boot all the way.

So initramfs hasn't broken for you... yet. But it most likely will at some point (maybe less likely since you're on the kernel team and presumably update your initramfs frequently).

Quote:

saellaven wrote:

What if Poettering and friends decide to completely integrate udev to the point that you can't use systemd? Are you going to fork udev despite your open hostility to eudev now?

If people really continue to think about systemd, I guess they will have to and will do so; but until we are that point, I guess it's going to be a long way to get there. How many people deeply care?

Look at this quarter's earnings, nobody should ever look a year out, all that matters is today's stock price!

Quote:

saellaven wrote:

Maybe instead of focusing on the people that forked to try to keep udev from going full on crazy, you should focus your efforts on combining forces with people that will force upstream's hand to stop before things get worse before you get left out in the cold too.

Consider how many people you would need for that, consider the amount of people that deeply care; I don't really see this happen, and what gain would it have for other distributions?

He was the one that made an open promise regarding the placement of udev, not me. I was trying to get him to think fully about the promise that he was making.

Quote:

I really don't see what this fuzz is all about; I'm a happy user of both, I don't think anything bad will happen to it.

It works for you and you're happy with it, so summarily dismiss any complaints as invalid, precisely as I said the devs have migrated to doing...

Quote:

But there becomes a point, that if there are just persons here and there holding these discussions, that it becomes futile; so, I suggest you to gather up forces and become a stronger voice instead.

That's just it... we'll be dismissed, just as you've literally just done, so it doesn't matter what I or any of the other people who have spoken out against deprecating a separate /usr, the /usr merge, systemd, etc. The day that my Gentoo system no longer boots or forces me to use systemd, I leave and I'm sure a handful of others will as well. In the process, the Gentoo community shrinks a little bit more as you, the devs, continue to complain about a lack of manpower. But hey, your system wasn't affected, yet, so it doesn't really matter.

Through their attempts to intertwine themselves into every facet of the system, forcing their one true way on everyone else.

They still have quite some facets to go.

saellaven wrote:

If I wanted a Microsoft type mentality dictated to me to use my computer, why take half measures when I could just switch to Microsoft?

Or you can look at it the other way; since I have switched from Windows, this is convenient.

Okay, that was pun intended; back to serious answers...

saellaven wrote:

I came to Gentoo from my own LFS type system as a means of automating what I was already doing because Gentoo offered flexibility.

That's what the about and philosophy outline, providing tools so you don't have to go down to doing all the package related management manually.

saellaven wrote:

Gentoo has decided to remove flexibility. I've maintained my own overlay and have no problem doing so.

How so? What is that overlay for?

saellaven wrote:

But if Gentoo buys into the Poettering line, as they appear to be doing, it is no longer worth my time to stay with Gentoo,

I don't see how Gentoo is buying it; as far as I see, there is only one optional dependency on GNOME 3, nothing more.

saellaven wrote:

just as you argue that maintaining a large patchset makes life too hard on the Gentoo devs.

Exactly, doing large patchsets in multiple places while mantaining 18.000+ packages is overkill; be aware that we have a little more to do than a single package here and there.

saellaven wrote:

I've often thought about becoming a Gentoo dev and actually somewhat started down the road last summer before my dad became hospitalized and died,

I'm sorry to hear that.

Quote:

but the politics of Gentoo has always kept me away.

Which politics in particular?

saellaven wrote:

Then you haven't read the mailing lists and bugs over the last year or so where people have complained about lvm being updated in portage but the initramfs not being rebuilt, which in turn made their system non-bootable or other people complaining that initramfs simply wouldn't let their computer boot all the way.

So initramfs hasn't broken for you... yet. But it most likely will at some point (maybe less likely since you're on the kernel team and presumably update your initramfs frequently).

Well, it was about predictable network names, unless I have misunderstood; anyhow, I don't run an initramfs at all, so I indeed don't know what that is all about. Sounds like either users not following news and/or post installation messages or maybe the absence of such messages; or people running ~arch (which isn't covered by such messages until it hits people).

saellaven wrote:

It works for you and you're happy with it, so summarily dismiss any complaints as invalid, precisely as I said the devs have migrated to doing...

Well, given the situation I cannot address the complaints; I cannot speak for others...

saellaven wrote:

That's just it... we'll be dismissed, just as you've literally just done, so it doesn't matter what I or any of the other people who have spoken out against deprecating a separate /usr, the /usr merge, systemd, etc. The day that my Gentoo system no longer boots or forces me to use systemd, I leave and I'm sure a handful of others will as well. In the process, the Gentoo community shrinks a little bit more as you, the devs, continue to complain about a lack of manpower. But hey, your system wasn't affected, yet, so it doesn't really matter.

Yeah, because support for it has to come from somewhere; if nobody is in for it, nobody's going to benefit from it. You can speak out FUD all you want, your words alone are not going to make up a difference...

It is like asking a government to lower tax prices because it is going to make people poor, without coming up with an efficient actionable solution to keep up the economy using the government's limited resources; it simply won't happen until the government can or the people manage to massively overthrow it...

"It doesn't really matter" are just your thoughts; please read our philosophy, because it does matter!

There was a simple solution that I asked about many months back
when it was announced that udev-171-r10 (IIRC) would be removed from portage.
I asked why it couldn't just stay there as it worked and it should be left until it broke
because of dependencies. That suggestion was summarily dismissed. Why? Because
it was promised that udev would continue to work. So now we have an announcement
that people need to change their systems because, "boo hoo hoo, now upstream
makes it too hard". Precisely what I and others predicted would happen.

Yes, I realize that many could have moved the old ebuild to their local directory
but they trusted the word of the devs and now it seems that that word
is useless. It's hardly the end users fault for trusting the devs to keep their word.

I also tried to caution a dev about promising things over which he had no control,
as it would cause problems. Now we got 2 devs on here playing CYA. All this could
have been avoided. Either by not guaranteeing things over which one has no control
or simply being quiet during these bitchfests, instead of thinking that one has to
control the thinking of the crowd.

Tom, I'm glad that your system is working, for others it's play catch-up since
they aren't on the cutting edge as devs are likely to be. And they're upset that
they are having to play, what will make it work this time and for how long.

Personally I think the devs, and that includes all, do a good job.
But many might try listening more and defending less.
Anyway just some thoughts on this.

There is a workaround for the GPL. Make the code so complex no single individual can understand it, therefore no single individual can fix it and supply patches.
This is where the concept of 'vertical integration' is headed.

The GPL is only useful while the philosophy of a piece of code doing one thing and doing it well is applied.
That keeps code simple and in the realm of individual understanding.

Having seen a number of 'vertically integrated' projects grow in complexity to the point where they had to be abandoned because nobody could make them work, I am not a fan of the philosophy behind systemd. udev is tainted with that philosophy too.

eudev is useful as it keeps the pressure on the udev/systemd team to keep things working for the non systemd supporters. Its difficult to say if the eudev fork was too early or not as its existence curbed the worst excesses of udev development.

I have a Gentoo install that works perfectly well without udev/systemd/eudev/mdev ... of course I've given up Gnome and hot plugging. Thats a trade off I'm willing to make._________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

It is claimed that udev itself is not related with the non-supporting of a separate /usr.

But perhaps this is not true, because AFAIK previous versions of udev were capable of repeating failed tasks once /usr is mounted, and AFAIK this is not the case for newer udev.

On the other hand, I agree that just repeating failed tasks is an ugly hack (since e.g. the failure could have other reasons than /usr not being ready, and repeating thus may be plain wrong).

What I do not understand: Why is it claimed that there is not a problem if using an initramfs?
I mean: While the initramfs is running (and udev is not yet started), the kernel parallelly initializes the hardware and thus might want to send an event which actually should be handled by udev (or a similar tool), but since initramfs is not yet finished there is no udev there to pick up the event.
Why are these events guaranteed to be not lost? Is the kernel buffering them until they are requested by some tool like udev?
If this is the case, why cannot the same mechanism be used without initramfs?

The /usr merge is being driven by a lot of upstream projects. udev was just the messenger.

The udev team decided to stop doing retries of commands that failed because /usr was not yet mounted.
I suspect it was getting harder and harder to paper over the cracks.

There are two ways forward. Mount /usr in an initrd or start udev later, after /usr is mounted in the normal course of events.
Both ways work. Most of the world is pushing for the initrd to be the one true way :)
SteveL has posted some changes to the startup scripts that start udev later in the boot sequence.

There is no problem when using an initramfs as the initramfs mounts both root and /usr and thats all, so that the init script sees a unified / and /usr, even though the reality is that they are still separate.

When udev is eventually started, it looks around the system to see what it should have done if it were running, much as if it was restarted.
This means that permissions on the content of /dev are not correct until udev starts but since everything is being run as root at that time, it does not matter_________________Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

There was a simple solution that I asked about many months back
when it was announced that udev-171-r10 (IIRC) would be removed from portage.
I asked why it couldn't just stay there as it worked and it should be left until it broke
because of dependencies. That suggestion was summarily dismissed. Why? Because
it was promised that udev would continue to work. So now we have an announcement
that people need to change their systems because, "boo hoo hoo, now upstream
makes it too hard". Precisely what I and others predicted would happen.

Why do you bring up udev-171 again? First and foremost, the ebuild was never lost, anyone can fetch it from the attic even today. However, one would also have to deal with several blockers to squeeze it into the system. And how would that be any better than using a perfectly well working udev today, except maybe a few kB less download size? And, well, there still is eudev.

Anon-E-moose wrote:

Yes, I realize that many could have moved the old ebuild to their local directory
but they trusted the word of the devs and now it seems that that word
is useless. It's hardly the end users fault for trusting the devs to keep their word.

eudev is useful as it keeps the pressure on the udev/systemd team to keep things working for the non systemd supporters. Its difficult to say if the eudev fork was too early or not as its existence curbed the worst excesses of udev development.

I understand after the announcement of eudev at least some old kernel support was brought back into udev/systemd Or is credit due to some upstream kernel voices?_________________backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic