Seems to me if /rescue/tar is going to run gzip as a subprocess, it
should have the full path /rescue/gzip (or gzcat or whatever) baked
in so its behaviour doesn't depend on PATH.
> Fortunately, I could /rescue/gzcat base.tgz >base.tar and tar x that
I also couldn‘t /rescue/gunzip base.tgz. Why?
On Mon, 4 Jul 2022, Martin Husemann wrote:
On Mon, Jul 04, 2022 at 06:58:39PM +, Emmanuel Dreyfus wrote:
On Mon, Jul 04, 2022 at 08:32:02PM +0200, Martin Husemann wrote:
Try with PATH=/rescue, that should avoid the issue.
Shouldn't /rescue binaries have /rescue prepended to their PATH?
On Mon, Jul 04, 2022 at 06:58:39PM +, Emmanuel Dreyfus wrote:
> On Mon, Jul 04, 2022 at 08:32:02PM +0200, Martin Husemann wrote:
> > Try with PATH=/rescue, that should avoid the issue.
>
> Shouldn't /rescue binaries have /rescue prepended to their PATH?
Tricky - isn't that too much magic?
We
On Mon, Jul 04, 2022 at 08:32:02PM +0200, Martin Husemann wrote:
> Try with PATH=/rescue, that should avoid the issue.
Shouldn't /rescue binaries have /rescue prepended to their PATH?
--
Emmanuel Dreyfus
m...@netbsd.org
On Mon, Jul 04, 2022 at 07:43:41PM +0200, Edgar Fuß wrote:
> So why does something in /rescue need a shared library?
It doesn't, but it exec's gzip via $PATH and finds /usr/bin/gzip - and
that needs /usr/lib/liblzma.so.2.
Try with PATH=/rescue, that should avoid the issue.
Martin
I nearly locked myself out updating a server (from -6 to -8).
I booted the new kernel (single user), mounted /usr, /var and /tmp,
extracted base.tgz (excluding /rescue, fortunately), but had forgotten
to remount / rw.
After that (I interrupted tar), tar didn't work any more.
Well, I had /rescue/t
