On Tue, Nov 27, 2018 at 11:11:41PM -0800, 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). > > > # 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.) > > > # 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'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. 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. ;-> > > > # 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. > > > # 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.
I'm happily using a GPT file system on a machine that does not EFI. There's a so-called "protective" MBR. But the first lowest-level boot is from an MBR on an older, smaller MBR-formatted disk. I suspect, though, that it is possible to boot directly to the GPT disk starting from the so-called provective MBR. > > 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 far as I can tell, the EFI partition on my old laptop (which is not the machine I mentioned above) is completely borked. It doesn't even seem to have a mountable FAT file system. The EFI partition is still there from the days it used to have a Windows XP system preinstalled on it. Is it plausible that that partition wasa borked fro the get-go? -- hendrik _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
