| 1 |
On 3/23/2021 07:31, Rich Freeman wrote: |
| 2 |
> On Mon, Mar 22, 2021 at 6:54 PM Andreas K. Huettel <dilfridge@g.o> wrote: |
| 3 |
>> |
| 4 |
>>>> Council decided years ago that we don't support separate /usr without |
| 5 |
>>>> an initramfs, but we haven't completed that transition yet. |
| 6 |
>>> |
| 7 |
>>> Which doesn't imply that we deliberately break things. |
| 8 |
>> |
| 9 |
>> That's right. Though we should at some point start thinking about an end of support for separate usr without initramfs. |
| 10 |
>> |
| 11 |
> |
| 12 |
> Just to clarify - it is already unsupported at a distro level. It is |
| 13 |
> just that some individual packages still work with it. |
| 14 |
> |
| 15 |
> The current Council decisions on the issue are (just providing for |
| 16 |
> general reference): |
| 17 |
> |
| 18 |
> - "Since that particular setup may already be subtly broken today |
| 19 |
> depending on the installed software, Council recommends using an |
| 20 |
> early boot mount mechanism, e.g. initramfs, to mount /usr if /usr |
| 21 |
> is on a separate partition." |
| 22 |
> Accepted unanimously. [1] |
| 23 |
> |
| 24 |
> - "The intention is to eventually not require maintainers to support |
| 25 |
> a separate /usr without an early boot mechanism once the Council |
| 26 |
> agrees that the necessary docs/migration path is in place." |
| 27 |
> Accepted with 4 yes votes, 1 no vote, 2 abstentions. [1] |
| 28 |
> |
| 29 |
> - "The Council agrees that all preparations for dropping support for |
| 30 |
> separate /usr without an initramfs or similar boot mechanism are |
| 31 |
> complete. A news item will be prepared, and users will be given one |
| 32 |
> month to switch after the news item has been sent." |
| 33 |
> Accepted with 5 yes votes, 1 no vote, 1 abstention. [2] |
| 34 |
> |
| 35 |
> Current policy documentation: |
| 36 |
> Developers are not required to support using separate /usr filesystem |
| 37 |
> without an initramfs. [3] |
| 38 |
> |
| 39 |
> 1 - https://projects.gentoo.org/council/meeting-logs/20130813-summary.txt |
| 40 |
> 2 - https://projects.gentoo.org/council/meeting-logs/20130924-summary.txt |
| 41 |
> 3 - https://projects.gentoo.org/qa/policy-guide/filesystem.html#pg0202 |
| 42 |
|
| 43 |
Is there a list of software/ebuilds that currently do this "subtle" handling |
| 44 |
of separate /usr w/o initramfs? |
| 45 |
|
| 46 |
I've got just my MIPS systems left that use a separate /usr and do not boot |
| 47 |
with initramfs because I build fully monolithic kernels and that makes the |
| 48 |
resulting vmlinux images run up against hard size limits in the SGI PROM |
| 49 |
(firmware, BIOS, etc) on these machines if I try to pack too large of an |
| 50 |
initramfs in. I can check for any software that may be switched over soon |
| 51 |
to a hard initramfs requirement and look at my options. |
| 52 |
|
| 53 |
I kinda wish the Linux kernel had an ability to partially boot, init the |
| 54 |
networking subsystem, then fetch an initramfs image over TFTP like it can do |
| 55 |
with NFS Root. That would solve the problem on my MIPS system(s) (and make |
| 56 |
install netboots better). I've dug around, but this does not seem to be a |
| 57 |
capability currently in the kernel, unless I have over looked something. |
| 58 |
|
| 59 |
Otherwise in the future, I may just have to setup an initramfs into an NFS |
| 60 |
Root and teach the SGI's to somehow deal with it. Which all still seems |
| 61 |
unnecessarily complicated because some other distro thinks it knows what's |
| 62 |
best for everyone else (but I digress...). |
| 63 |
|
| 64 |
-- |
| 65 |
Joshua Kinard |
| 66 |
Gentoo/MIPS |
| 67 |
kumba@g.o |
| 68 |
rsa6144/5C63F4E3F5C6C943 2015-04-27 |
| 69 |
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 |
| 70 |
|
| 71 |
"The past tempts us, the present confuses us, the future frightens us. And |
| 72 |
our lives slip away, moment by moment, lost in that vast, terrible in-between." |
| 73 |
|
| 74 |
--Emperor Turhan, Centauri Republic |
Archives