On 28/11/18 at 08:11, Rick Moen wrote: > Quoting KatolaZ (kato...@freaknet.org): > >> # 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 <alessandrose...@linux.com> VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
