| View previous topic :: View next topic |
| Author |
Message |
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3686
Location: Rasi, Finland
|
 Posted: Sun Jul 21, 2024 10:38 am Post subject: Thinking of switching to merged-usr... |
 |
|
My systems, currently two, both use split-usr profiles. Both are also openrc.
Is there a point to switch? I always boot with custom initrd.
With merged-usr I could have neatly the whole /usr on an lv, if needed.
I guess there are no plans to deprecate split-usr any time soon either..?
The point I'm going after here is my custom profiles. I haven't yet created any that references (is a child of) 23.0 profiles. But I'm now planning. I'd use those profiles for all my systems and future systems too. But I'm unable to decide if to create merged-usr or split-usr based profiles.
It seems like merged-usr is the more common one and, in my case, really doesn't matter which I choose, so... maybe "better" to go with merged one?
Any tips? Pitfalls of choosing one or another?
Thanks.
_________________
..: Zucca :..
| My gentoo installs: | init=/sbin/openrc-init
-systemd -logind -elogind seatd |
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
 |
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20484
|
| Posted: Sun Jul 21, 2024 2:11 pm Post subject: |
|
|
I presume it's a matter of time before it's unavoidable, but I'm still on 17.1. If merged does become the only option, I'd rather not have a short window of time when I have to make the switch. So when I switch to 23, I'll likely follow up to merged. Provided that /usr being on a different LV doesn't matter (I don't think it does).
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 214
|
| Posted: Sun Jul 21, 2024 4:18 pm Post subject: |
|
|
The removal of the final, lingering, mostly unmaintained for a decade support for booting without an initramfs while /usr is un-mounted and expecting system initialization to work, greatly decreased the issues with supporting split-usr. I think that supporting split-usr is now much more manageable and given that rather a lot of people seem to really like it and Gentoo generally tries to be about choice, my personal suspicion is that there isn't much taste for trying to remove it.
I suspect releng would *like* to, in order to reduce the matrix of stage tarballs that have to be generated, but I think it's currently down to one variant anyway and it's not the most compelling reason to drop support. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20484
|
| Posted: Sun Jul 21, 2024 5:47 pm Post subject: |
|
|
| eschwartz wrote: | The removal of the final, lingering, mostly unmaintained for a decade support for booting without an initramfs while /usr is un-mounted and expecting system initialization to work, greatly decreased the issues with supporting split-usr. I think that supporting split-usr is now much more manageable and given that rather a lot of people seem to really like it and Gentoo generally tries to be about choice, my personal suspicion is that there isn't much taste for trying to remove it.
I suspect releng would *like* to, in order to reduce the matrix of stage tarballs that have to be generated, but I think it's currently down to one variant anyway and it's not the most compelling reason to drop support. |
I presume some of the changes Gentoo devs make are "forced" by upstream. I'd personally prefer /bin and /sbin be for the OS, and anything /usr be for not the OS. But that's just me.
Since the changes forcing an initramfs if /usr is a separate partition, I've been booting to a initramfs rescue shell and manually mounting /usr. If there was a way to do that without an initramfs, I would. I finally managed to get a partially working initramfs last week, but they still don't seem worth the trouble. Granted, I don't know what the workarounds were, but it still seems like a tail wagging the dog kind of problem.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 214
|
| Posted: Sun Jul 21, 2024 6:07 pm Post subject: |
|
|
| pjp wrote: | | eschwartz wrote: | The removal of the final, lingering, mostly unmaintained for a decade support for booting without an initramfs while /usr is un-mounted and expecting system initialization to work, greatly decreased the issues with supporting split-usr. I think that supporting split-usr is now much more manageable and given that rather a lot of people seem to really like it and Gentoo generally tries to be about choice, my personal suspicion is that there isn't much taste for trying to remove it.
I suspect releng would *like* to, in order to reduce the matrix of stage tarballs that have to be generated, but I think it's currently down to one variant anyway and it's not the most compelling reason to drop support. |
I presume some of the changes Gentoo devs make are "forced" by upstream. I'd personally prefer /bin and /sbin be for the OS, and anything /usr be for not the OS. But that's just me.
Since the changes forcing an initramfs if /usr is a separate partition, I've been booting to a initramfs rescue shell and manually mounting /usr. If there was a way to do that without an initramfs, I would. I finally managed to get a partially working initramfs last week, but they still don't seem worth the trouble. Granted, I don't know what the workarounds were, but it still seems like a tail wagging the dog kind of problem. |
The long and short of it is that arbitrary commands used during system startup, including things such as the `mount` program for mounting the /usr partition, tend to pull in somewhat arbitrary shared libraries. If those shared libraries are required at boot before /usr is mounted, this implies the libraries have to be part of /lib* and not /usr/lib* -- but this is a problem because most libraries aren't actually set up to work that way.
It requires manually maintaining a list of libraries that "might" be pulled in at boot, and adding handcrafted workarounds in the ebuilds to copy the real library to /lib*, conditional on USE=split-usr, and leave linker scripts in its place so that the compiler is halfway functional and can still link software after the change. And then this breaks software that attempts to say, dlopen the library.
There are some notable PAM bugs that could render your system quite broken as a result of this! Also, no one was really checking that this list of libraries was properly maintained, and occasionally people would report bugs that their USE=split-usr system without an initramfs wasn't booting and it would turn out things had become broken months ago and no one noticed.
An initramfs is "just" a technology for ensuring that your system startup environment doesn't depend on /usr to be available in order to bring up the system, including mounting /usr and setting up the service manager and so on.
Plausibly, you can do the same thing with statically linked busybox in /bin and not bother with an initramfs. I haven't tried it. I don't use an initramfs but I also use merged-usr. Someone mentioned the busybox case to me as a criticism of the news article deprecating the support for "move the libraries to /lib and create a linker script", arguing that the news article was incomplete because it mentioned using an initramfs but didn't mention the busybox case -- IIRC I responded that I figured the news article was fine as-is unless someone was willing to actually go document the busybox approach on the wiki. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22612
|
| Posted: Sun Jul 21, 2024 6:08 pm Post subject: |
|
|
Various packages (I no longer recall which ones) were installing rules in /lib/udev that caused udev to try to run /usr/bin/some-command during early boot, before fstab had caused /usr to mount. The workarounds tried to solve this, variously by relocating some-command to /bin, rearranging the rules to run later, and possibly other approaches.
I've used an initramfs for a long time, for support of root-on-LVM. I previously had separate /usr, but eliminated that when Gentoo started warning that it was not well supported by some packages. I had no strong need for it, and had made it separate because that was what I learned in the early days, before anyone had heard of udev rules causing these problems. I don't recall if I ever had a phase where I had a separate /usr and made my initramfs mount it before starting /sbin/init, but if I did, it would've been an automatic step. The system would come up on its own, without me helping it with that mount each time. |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20484
|
| Posted: Sun Jul 21, 2024 6:45 pm Post subject: |
|
|
@eschwartz, Hu:
Thanks for the explanations. I'm not a dev, so I'm just along for the ride.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3686
Location: Rasi, Finland
|
| Posted: Sun Jul 21, 2024 10:42 pm Post subject: |
|
|
| eschwartz wrote: | An initramfs is "just" a technology for ensuring that your system startup environment doesn't depend on /usr to be available in order to bring up the system, including mounting /usr and setting up the service manager and so on.
Plausibly, you can do the same thing with statically linked busybox in /bin and not bother with an initramfs. |
Now that you said that... yes, I think it's possible.
My custom initramfs uses busybox where ever it can. So in a way doing the busybox trick to avoid initramfs is somewhat the same as moving the contents of initramfs into the system root.
Busybox has a very limited sysvinit -like service too even. But that's not really needed to bring the system to a state where the ongoing process can exec the real init.
Anyways... Interesting concept.
I think I could switch to merged-usr for slightly easier snapshotting...
_________________
..: Zucca :..
| My gentoo installs: | init=/sbin/openrc-init
-systemd -logind -elogind seatd |
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
