On 28/11/18 at 08:11, Rick Moen wrote:
> Quoting KatolaZ (katolaz@???):
>
>> # ldd /sbin/mount.nfs | grep "/usr"
>> libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f82f53ac000)
>> libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f82f52cf000)
>> libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f82f529b000)
>> libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f82f4fd1000)
>
> If I were relying on NFS during early boot, I'd file a bug against package
> nfs-common, and also, meanwhile, compile a local-package substitute with
> either static binaries or ones linked to libs in /lib (and provide those).
I agree. Everything that sits on / must have it's dynamical libraries
in / too. Everything under /usr that uses the same libraries will work
correctly, the opposite is not necessarily true.
>> # ldd /sbin/lvscan | grep "/usr"
>> liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fde00702000)
>>
>> # ldd /sbin/lvs | grep "/usr"
> liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fd3b7fa1000)
>
> Ditto package lvm2. (Which FWIW I've avaoided needing.)
I don't use it for my personal systems, but I do acknowledge LVM is a
boon on servers where the disk/filesystem occupation is hard to predict
at install time or that might see their use change consistently over
time, such a NFS fileserver that at some point it's decided it's going
to double as a mail server too.
>> # ldd /sbin/sysctl | grep "/usr"
>> liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f3ab7b18000)
> Um, I know of no reason why /sbin/sysctl would be urgently needed in a
> minimal system prior to availability of /usr for purposes of backup,
> restore, system repair, etc.
I wonder, too.
> I've never needed to futz with /proc/sys/*
> entries while running in maintenance mode, but, if one did need to do
> so, doing the task using 'echo' is more than sufficient.
>
>> # ldd /sbin/gdisk | grep "/usr"
>> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f7ddf10f000)
> I haven't yet needed gdisk (& cgdisk, sgdisk, fixparts), having so far
> successfully avoided GPT.
I always use GPT whenever I can, to take advantage of it's increased
resiliency to accidental damage (that's because it copies it's boot and
partitioning data at the end of the drive).
> The obvious alternative to gdisk is GNU
> parted (package parted), and FWIW it suffers a similar build boo-boo,
> requiring library libtic.so.5 (terminfo) from inside /usr/lib.
>
> Tsk-tsk. ;->
Agree. 😈
>> # ldd /bin/kill | grep "/usr"
>> liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f9f6aa4a000)
>>
>> # ldd /bin/ps | grep "/usr"
>> liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007fd7f6ebc000)
> Yeah, those two are really annoying. FWIW, my server system has older
> versions of those two utilities that do _not_ have that (IMO) build
> error. Local packages will be an immediate resort, when/if I hit that.
Package: liblz4-1
Description: Fast LZ compression algorithm library - runtime
Why on Earth do kill and ps need a "compression algorithm library"? 😕
>> # ldd /bin/efibootmgr | grep "/usr"
>> libefivar.so.1 => /usr/lib/x86_64-linux-gnu/libefivar.so.1 (0x00007f7ed22bd000)
>> libefiboot.so.1 => /usr/lib/x86_64-linux-gnu/libefiboot.so.1 (0x00007f7ed20b0000)
> As with GPT, I've managed so far to step sideways and successfully evade
> the Second System Effect poster child that is EFI.
EFI anyway is connected to boot, very early boot actually, and for
this reason it should reside on /.
> I'm also unconvinced that efibootmgr is essential to a 'recovery'
> minimal maintenance system, anyway. My readings suggest that I would
> want to have a 'EFI stub kernel' configuration where you place an
> (unsigned) kernel binary image in the EFI System Partition and rely on
> the EFI firmware to boot that kernel and mount the root fs directly
> without needing a bootloader. Coverage at, among other places:
> https://wiki.gentoo.org/wiki/EFI_stub_kernel
>
> (As usual, I'm saying this is an example of what would Work for Me[tm].
> What might suit others or some entire abstract group of people is a
> different discussion.)
Anyway, as I already stated, this has to do with boot, and everything
connected with it should be in / (and /boot).
>> Most of the utilities you would need to debug a problem in mounting a
>> /usr over NFS, or a failing lvm volume, or a scrambled efi partition
>> (some of the use cases somebody mentioned before) need stuff in
>> /usr.
> This has not been my experience for my own use case (granting your point
> about /bin/kill and /bin/ps as provided in packaged versions I am not
> yet running). If I encounter that, I will consider that situation to
> involve critical bugs that I would resolve through the package
> maintainer if possible, or via a locally built alternative if not.
Yep. I got the feeling developers/packagers have turned on relying on
initramfs as an easy way to fix the mess their software/packages
produced on a regular, classical Unix installation with a split /usr
filesystem. "It works for me", "separate /usr is not supported/you're
supposed to use initramfs", bug closed. 😠
--
Alessandro Selli <alessandroselli@???>
VOIP SIP: dhatarattha@???
Chiave firma e cifratura PGP/GPG signing and encoding key:
BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE
::
Re: [DNG] /usr to merge or not to m…
