:: Re: [DNG] running with separate / a…
Página Principal
Delete this message
Reply to this message
Autor: Rainer Weikusat
Data:  
Para: dng
Assunto: Re: [DNG] running with separate / and /usr
Ralph Ronnquist <rrq@???> writes:
> On Sun, Jan 15, 2023 at 11:13:40PM -0500, Hendrik Boom wrote:
>> ...
> On Sun, Jan 15, 2023 at 10:22:43PM +0000, Rainer Weikusat via Dng wrote:
>> > As it stands, an updated Chimera system will fail to boot unless / and
>> > /usr are on the some partition. That's not documented in the release
>> > notes and that's a serious issue for everyone who might become affected
>> > by it. Undocumented features with seriously negatively consequences are
>> > by definition bugs.
>>
>> So it's been a good thing I haven't updated by beowulf server to chimaera.
>> It has separate /use from / for more than a decade now. And it
>> won't be possible without major repartitoning.
>
> One should also note that the chimaera installer (as well as daedalus
> preview) provide no-merged-usr filesystems, and either can be used
> with separate / and /usr partitions.
>
> Rainer's issue thus seems to relate to his system and the setup he
> has, and it's not a general chimaera issue.


The issue is specifically that libselinux is linked with most basic
utilities and requires libpcre2 which is below /usr and that the module
utilities are linked with libcrypto (from OpenSSL) which is also below
/usr. The effect is that it's not possible to boot a system in the
traditional way, ie, have the kernel mount / and then run init to start
everything up as init cannot be executed before /usr has been mounted.

This may or may not be a problem when an initrd is being used. This
depends on what the system on the initrd does before trying to run the
real init. Since I'm running (meanwhile) a completely mirrored system, I
tried switching the ascii system I had to using an initrd. This
renumbered my root RAID1 from /dev/md0 to /dev/md127 by changing the
superblock (a more useless feature is hard to imagine), took an eternity
messing around with the other RAIDS and then failed to boot. I didn't
feel like debugging this seriously outdated stuff and hence, switched
back to using kernel autodetection[*] for getting the /-raid started which
- as always - works fine (minus the gotcha with the /dev/mtd0 ->
/dev/mtd127 switch).

[*] The people who maintain

https://raid.wiki.kernel.org/index.php/RAID_setup

claim that "this code has been removed from the kernel". As 'this code'
is most certainly in 6.1.2, the probably refer to "isn't compiled into
distribution kernels" (we control) anymore.