| View previous topic :: View next topic |
| Author |
Message |
M95D
Tux's lil' helper
Joined: 03 Jan 2020
Posts: 94
|
 Posted: Sun Aug 11, 2024 10:23 am Post subject: How to migrate to split-usr profile? |
 |
|
I installed a fresh Gentoo stage3 for ARM. The default profile is merged-usr. I could not find a split-usr stage3. I wish to switch to split-usr. Any instructions/tips?
Thank you! |
|
| Back to top |
|
 |
Chiitoo
Administrator
Joined: 28 Feb 2010
Posts: 2670
Location: Here and Away Again
|
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2182
|
| Posted: Sun Aug 11, 2024 7:27 pm Post subject: |
|
|
I don't think switching back is supported. If you can't find a stage 3 tarball for your platform to reinstall from scratch, then you're stuck. But I also can't think of too many reasons to want to do so. Maybe share your underlying issue so that another solution may be found?
Best Regards,
Georgi |
|
| Back to top |
|
|
M95D
Tux's lil' helper
Joined: 03 Jan 2020
Posts: 94
|
| Posted: Sun Aug 11, 2024 11:13 pm Post subject: |
|
|
It's armv7a, 32bit, RK3288.
First reason is that I like having busybox symlinks installed in /bin and /sbin so I can use them as backup in case something happens to "full" utils.
Second reason is that "merged-usr" looks like a hack/patch. If symlinks are removed, everything breaks. Why would anyone want that? |
|
| Back to top |
|
|
kimchi_sg
Advocate
Joined: 26 Nov 2004
Posts: 3037
|
| Posted: Sun Aug 11, 2024 11:42 pm Post subject: |
|
|
| M95D wrote: | | "merged-usr" looks like a hack/patch. If symlinks are removed, everything breaks. |
split-usr is equally fragile by that measure. If directories are removed, everything breaks too. |
|
| Back to top |
|
|
flexibeast
Guru
Joined: 04 Apr 2022
Posts: 382
Location: Naarm/Melbourne, Australia
|
| Posted: Sun Aug 11, 2024 11:53 pm Post subject: |
|
|
eschwartz has written a quick introduction to the motivations behind merged-usr in this recent comment:
| Quote: | 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. |
|
|
| Back to top |
|
|
M95D
Tux's lil' helper
Joined: 03 Jan 2020
Posts: 94
|
| Posted: Mon Aug 12, 2024 9:34 am Post subject: |
|
|
| kimchi_sg wrote: | | M95D wrote: | | "merged-usr" looks like a hack/patch. If symlinks are removed, everything breaks. |
split-usr is equally fragile by that measure. If directories are removed, everything breaks too. |
Yes, but it's a hack in the sense that bins are not referenced to their real location. I would have considered it ok if symlinks were not required. |
|
| Back to top |
|
|
M95D
Tux's lil' helper
Joined: 03 Jan 2020
Posts: 94
|
| Posted: Mon Aug 12, 2024 9:54 am Post subject: |
|
|
| flexibeast wrote: | eschwartz has written a quick introduction to the motivations behind merged-usr in this recent comment:
| Quote: | 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. |
|
That expains why /usr does't always work if mounted from a separate partition, not why all bins were moved in there. It could have been a simple note that /usr in a separate partition is not officially supported and just leave it like that, instead of actively trying to prevent such a setup. To me, it looks like devs want to force some kind of uniformity on how Gentoo users set up their system. I don't agree with this, especially since there is a simple script to migrate to merge-usr, but no way back from the only stage3.
I don't use a separate /usr partition, but I really really hate restricting user choice for trivial reasons (or no reason at all, in this case, unless there is a hidden agenda incompatible with separate-usr). I woudn't use such a high-maintenance OS like Gentoo if I liked uniformity. |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2182
|
| Posted: Mon Aug 12, 2024 10:08 am Post subject: |
|
|
| M95D wrote: |
I don't use a separate /usr partition, but I really really hate restricting user choice for trivial reasons (or no reason at all, in this case, unless there is a hidden agenda incompatible with separate-usr). I woudn't use such a high-maintenance OS like Gentoo if I liked uniformity. |
Well then, you could step up and make up for the effort required to maintain a split-usr profile.
Best Regards,
Georgi |
|
| Back to top |
|
|
flexibeast
Guru
Joined: 04 Apr 2022
Posts: 382
Location: Naarm/Melbourne, Australia
|
| Posted: Mon Aug 12, 2024 11:51 am Post subject: |
|
|
| M95D wrote: | | That expains why /usr does't always work if mounted from a separate partition, not why all bins were moved in there. |
Because some of those binaries might be needed before the /usr partition is mounted. And where software has put binaries over the years hasn't been (and still isn't) consistent, and other software will be making assumptions about certain binaries being accessible in certain ways, and different users will have different binaries required at boot time. It's a complex issue for distro and package maintainers - cf. below - and in the case of Gentoo, most of those maintainers are volunteers, with limited time and resources.
| M95D wrote: | | It could have been a simple note that /usr in a separate partition is not officially supported and just leave it like that, instead of actively trying to prevent such a setup. To me, it looks like devs want to force some kind of uniformity on how Gentoo users set up their system. |
This is ultimately being forced by systemd/FDO upstream; here's a more extensive explanation on freedesktop.org. As usual, the Gentoo devs are trying to work with the hand they've been dealt.
| M95D wrote: | | I don't use a separate /usr partition, but I really really hate restricting user choice for trivial reasons (or no reason at all, in this case, unless there is a hidden agenda incompatible with separate-usr). I woudn't use such a high-maintenance OS like Gentoo if I liked uniformity. |
As logrusx noted, user choice requires volunteers to do the work to support making and keeping those choices available. (i'm not a systemd user, and will work to avoid it as long as possible, for various reasons; i use OpenRC, but i've also ported and maintain man page ports of the documentation for various parts of the s6 ecosystem, which i've previously used in the form of s6+66 on Void.) In my own case, i don't have any significant reason to stay with split-usr, so i've changed to merged-usr. Nonetheless, i don't disagree with others being able to maintain split-usr systems, only that volunteer Gentoo devs should be expected to fight the merged-usr tide regardless of the pros and cons of doing so from the point of view of their time and energy. |
|
| Back to top |
|
|
eschwartz
Developer
Joined: 29 Oct 2023
Posts: 135
|
| Posted: Wed Aug 14, 2024 11:18 pm Post subject: |
|
|
| flexibeast wrote: | eschwartz has written a quick introduction to the motivations behind merged-usr in this recent comment:
| Quote: | 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. |
|
Sorry, my comment was about the motivation behind removing certain forms of USE=split-usr support from packages where the maintenance burden of it was effectively unreasonable.
It has nothing to do with why merged-usr or split-usr profiles exist or whether they will continue to be supported.
The distinction here is the difference between a USE flag and a profile. The profile does enforce a USE flag, for packages that need the USE flag because portage cannot handle both merged and split without a USE flag to distinguish the two, but... see below.
| M95D wrote: |
That expains why /usr does't always work if mounted from a separate partition, not why all bins were moved in there. It could have been a simple note that /usr in a separate partition is not officially supported and just leave it like that, instead of actively trying to prevent such a setup. To me, it looks like devs want to force some kind of uniformity on how Gentoo users set up their system. I don't agree with this, especially since there is a simple script to migrate to merge-usr, but no way back from the only stage3.
I don't use a separate /usr partition, but I really really hate restricting user choice for trivial reasons (or no reason at all, in this case, unless there is a hidden agenda incompatible with separate-usr). I woudn't use such a high-maintenance OS like Gentoo if I liked uniformity. |
On merged-usr systems, binaries are naturally installed to only a single location. On split-usr systems, the binaries haven't been moved.
The issue is moving *between* profiles. Portage supports both merged-usr and split-usr using a single installation schema -- ebuilds always install binaries to their "canonical location", e.g. on a merged-usr system, bash is installed to /bin/bash not /usr/bin/bash.
At src_install time, this information remains true -- and usable in binpackages that were built on a merged-usr system but are installable and work correctly on a split-usr system.
When merging the package to the live ROOT, portage is "clever" and it detects when /bin is a symlink, it installs /bin/bash following the symlink and dynamically updates the tracked information. That's how it also works on a merged-usr system. By doing this, portage can invisibly handle the case where files just need to be installed to either /usr or / (by simply installing to / in all cases!).
This does mean that in order to migrate between split-usr and merged-usr profiles, you have no real way of knowing what the original canonical location of a file is. That's not a problem when moving from split-usr to merged-usr, since you have that information on the live filesystem and intend to discard it -- but it means you cannot trivially reverse the process.
Of course, you could boot to installation media, delete the directory symlinks (thereby breaking various software unpredictably) and reinstall all packages (so that the files are installed fresh, *without* following directory symlinks and therefore without dynamically updating the tracked information). This would be a pretty big pain and isn't significantly different from saving your world file and /etc/portage and reinstalling from stage3. |
|
| 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
