1 |
On Sat, Mar 27, 2021 at 10:51:11PM -0400, Joshua Kinard wrote: |
2 |
> On 3/27/2021 20:32, William Hubbs wrote: |
3 |
> > On Sat, Mar 27, 2021 at 05:43:34PM -0400, Joshua Kinard wrote: |
4 |
> >> On 3/23/2021 07:31, Rich Freeman wrote: |
5 |
> >>> On Mon, Mar 22, 2021 at 6:54 PM Andreas K. Huettel <dilfridge@g.o> wrote: |
6 |
> >>>> |
7 |
> >>>>>> Council decided years ago that we don't support separate /usr without |
8 |
> >>>>>> an initramfs, but we haven't completed that transition yet. |
9 |
> >>>>> |
10 |
> >>>>> Which doesn't imply that we deliberately break things. |
11 |
> >>>> |
12 |
> >>>> That's right. Though we should at some point start thinking about an end of support for separate usr without initramfs. |
13 |
> >>>> |
14 |
> >>> |
15 |
> >>> Just to clarify - it is already unsupported at a distro level. It is |
16 |
> >>> just that some individual packages still work with it. |
17 |
> >>> |
18 |
> >>> The current Council decisions on the issue are (just providing for |
19 |
> >>> general reference): |
20 |
> >>> |
21 |
> >>> - "Since that particular setup may already be subtly broken today |
22 |
> >>> depending on the installed software, Council recommends using an |
23 |
> >>> early boot mount mechanism, e.g. initramfs, to mount /usr if /usr |
24 |
> >>> is on a separate partition." |
25 |
> >>> Accepted unanimously. [1] |
26 |
> >>> |
27 |
> >>> - "The intention is to eventually not require maintainers to support |
28 |
> >>> a separate /usr without an early boot mechanism once the Council |
29 |
> >>> agrees that the necessary docs/migration path is in place." |
30 |
> >>> Accepted with 4 yes votes, 1 no vote, 2 abstentions. [1] |
31 |
> >>> |
32 |
> >>> - "The Council agrees that all preparations for dropping support for |
33 |
> >>> separate /usr without an initramfs or similar boot mechanism are |
34 |
> >>> complete. A news item will be prepared, and users will be given one |
35 |
> >>> month to switch after the news item has been sent." |
36 |
> >>> Accepted with 5 yes votes, 1 no vote, 1 abstention. [2] |
37 |
> >>> |
38 |
> >>> Current policy documentation: |
39 |
> >>> Developers are not required to support using separate /usr filesystem |
40 |
> >>> without an initramfs. [3] |
41 |
> >>> |
42 |
> >>> 1 - https://projects.gentoo.org/council/meeting-logs/20130813-summary.txt |
43 |
> >>> 2 - https://projects.gentoo.org/council/meeting-logs/20130924-summary.txt |
44 |
> >>> 3 - https://projects.gentoo.org/qa/policy-guide/filesystem.html#pg0202 |
45 |
> >> |
46 |
> >> Is there a list of software/ebuilds that currently do this "subtle" handling |
47 |
> >> of separate /usr w/o initramfs? |
48 |
> >> |
49 |
> >> I've got just my MIPS systems left that use a separate /usr and do not boot |
50 |
> >> with initramfs because I build fully monolithic kernels and that makes the |
51 |
> >> resulting vmlinux images run up against hard size limits in the SGI PROM |
52 |
> >> (firmware, BIOS, etc) on these machines if I try to pack too large of an |
53 |
> >> initramfs in. I can check for any software that may be switched over soon |
54 |
> >> to a hard initramfs requirement and look at my options. |
55 |
> > |
56 |
> > One group of packages involved in this is any package that calls |
57 |
> > gen_usr_ldscript. We have this function for a couple of reasons. |
58 |
> > |
59 |
> > Gentoo has a policy that bans *.a static libraries from being |
60 |
> > installed in /lib*. I think this policy is unique to Gentoo, |
61 |
> > because Most build systems I've seen do not |
62 |
> > have separate paths for static vs dynamic libraries, so all libraries |
63 |
> > from a package are installed in /usr/lib* or /lib*. This policy was |
64 |
> > originally hard coded into portage some time back (I can find the commit |
65 |
> > if you want it) before it was made a formal policy by the qa team. |
66 |
> > It has since become a formal policy. |
67 |
> > |
68 |
> > Because of this policy, we have to tell upstream build systems to |
69 |
> > install libraries in ${ED}/usr/$(get_libdir). This is fine unless you |
70 |
> > have separate usr with no initramfs. In that case, you have binaries on |
71 |
> > / that link to shared libraries on /usr. When we saw this happening, we |
72 |
> > started manually moving shared libraries from /usr/lib* to /lib* if |
73 |
> > someone needed the package at boot time. Then we hit bug 4411 [1] |
74 |
> > where the linker was prioritizing static libraries in /usr/lib* over shared |
75 |
> > libraries in /lib*. |
76 |
> > |
77 |
> > I don't know if we tried to address that upstream or not, but ultimately |
78 |
> > gen_usr_ldscript came out of it. |
79 |
> > |
80 |
> > Several folks have wanted to get rid of this function for years [2]. |
81 |
> > |
82 |
> > I have looked into it before, and there are several things that can be done. |
83 |
> > |
84 |
> > We can have packages that currently build static libraries and |
85 |
> > use gen_usr_ldscript stop building static libraries and use the |
86 |
> > appropriate setting in their build systems to install libraries in |
87 |
> > /$(get_libdir). This is the path OpenRC is taking per request of the qa |
88 |
> > lead. The next release will not support the static-libs use flag. This |
89 |
> > will actively break anyone who is expecting this use flag to exist for OpenRC. |
90 |
> > |
91 |
> > If a package does not build static libraries in the first place, there is |
92 |
> > really no reason to call gen_usr_ldscript; the ebuild should be using |
93 |
> > the upstream build system to put the libraries where they need to be. |
94 |
> |
95 |
> The number of packages calling gen_usr_ldscript looks to be fairly small. |
96 |
> Creating a TRACKER bug and sub-bugs for checking or removing the need for |
97 |
> gen_usr_ldscript might be a way to go to pair the list down and reduce the |
98 |
> footprint: |
99 |
> |
100 |
|
101 |
Yes, I can start this work. |
102 |
|
103 |
> |
104 |
> > If static libraries are needed for a package that is using |
105 |
> > gen_usr_ldscript to move shared libraries to /lib*, the only option you |
106 |
> > have is to drop the gen_usr_ldscript call. If you do that, all of the |
107 |
> > libraries will stay in /usr/lib*, but as soon as one package takes this |
108 |
> > path, there will be active breakage for someone who is using a separate |
109 |
> > /usr without an initramfs. |
110 |
> |
111 |
> Correct me if wrong, but static libraries are only needed during |
112 |
> compilation, right? The *.a files are merged into the binary at link time |
113 |
> and thus that binary can stand on its own regardless of whether the *.a |
114 |
> files are available or not. They're not like shared libs which are needed |
115 |
> by the loader to resolve symbols at run time. |
116 |
|
117 |
You are correct, and actually in Gentoo we prefer not to link to static |
118 |
libraries, so we build them but we do not use them. |
119 |
|
120 |
*snip* |
121 |
|
122 |
> We're mostly talking about the small window during boot where, on a system |
123 |
> with /usr on a separate disk partition, /usr might not be available until |
124 |
> some userspace tool in /bin or /sbin runs to make it available. Running the |
125 |
> system compiler during boot would be a rare and very unique scenario (not to |
126 |
> mention a sign of questionable development processes). |
127 |
|
128 |
The problem is, there's a chicken-and-egg problem in the scenario where |
129 |
/ and /usr are on separate partitions, and this is why a number of linux |
130 |
distros have moved to requiring an initramfs in this situation. |
131 |
I'm linking systemd's description here, only because it is the best |
132 |
writeup of the issue I've found [1]. |
133 |
Anything that is needed in the early boot process requires all of its libraries, |
134 |
dependent libraries, binaries, data files, etc to be on /, and this has |
135 |
become a moving target. |
136 |
|
137 |
> > The most controversial thing to do would be the /usr merge. It would |
138 |
> > affect far more users than the other paths for getting rid of |
139 |
> > gen_usr_ldscript, but it would make all "separate /usr" concerns go |
140 |
> > away along with giving us a number of other benefits. |
141 |
> > |
142 |
> > The short version is, anything we do to remove the gen_usr_ldscript |
143 |
> > function will actively break some group of users. |
144 |
> |
145 |
> If I read the temperature right, it seems like there is desire to eliminate |
146 |
> gen_usr_ldscript regardless of sep-usr or not. If so, then that seems the |
147 |
> way to go. Make the eventual /usr merge a separate issue to tackle some |
148 |
> time further down the road. |
149 |
|
150 |
The way I see it, when we start to remove the gen_usr_ldscript calls, |
151 |
people using a sep-usr mount without an initramfs will run into one or |
152 |
both of these issues: |
153 |
|
154 |
- they might have to increase the size of their root partition depending |
155 |
on what gets added to /lib* |
156 |
- if one package in that list drops gen_usr_ldscript without installing |
157 |
libraries in /lib*, it will mean they need an initramfs. |
158 |
|
159 |
From my pov, it is better to start using initramfs in that situation, |
160 |
and if you do that you fix all of the other issues mentioned on |
161 |
the page linked above. It feels like the usr merge is less of a big deal |
162 |
once we know everyone who has /usr separate is using an initramfs. |
163 |
|
164 |
William |
165 |
|
166 |
[1] https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ |