On Tue, Nov 27, 2018 at 11:11:41PM -0800, 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).
>
> > # 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
::
Re: [DNG] /usr to merge or not to m…
