Monday, October 14, 2024

Re: how to recover? sysupgrade 7.5 -> 7.6, remote machine sshd not restarted, /usr overfull

On Fri, 11 Oct 2024 15:40:06 -0000 (UTC), Stuart Henderson wrote:
> On 2024-10-11, Amelia A Lewis <amyzing@talsever.com> wrote:

[snipped: sshd not starting on machine with sysupgrade-overfilled /usr
slice]

>> I'm too verbose. Short version: a) with sshd not working and no console
>> access, is there a way to work on it, or is console access required? b)
>
> some sort of console access needed.
>
>> assuming (prolly console) access, can the current contents of /usr be
>> copied to a new /usr slice, and the rest of the upgrade (pkg_add -u)
>> performed, or is a complete/clean install required for stability?
>
> /usr will almost certainly be incomplete, but I'd say there are ways to
> fix this (without creating instability) without a reinstall.

Thanks for this: I got it fixed up this weekend and wanted to update
without going off on multiple tangents, so here's the short version of
what I did, in case it's useful for others, with most of the missteps
removed.

0. console access

1. copy contents of last slice elsewhere, delete slice

2. create new 6G+ slice for /usr at start of old last slice & newfs,
mount as /mnt

3. copy contents of /usr to new slice (preserving perms, not crossing
mountpoints), umount /usr (and mountpoints inside it), umount /mnt,
mount new fs as /usr, remount mountpoints; reboot to test

4. (cleanup) create new -6G last slice & newfs & mount, copy old stuff
into place and delete temp copy

5. sysupgrade -R 7.6

6. pkg_add -u

7. (cleanup) copy /usr/X11R6 slice contents aside, umount then delete
slice, grow former /usr slice to include old x11 slice area, newfs,
mount as /usr/X11R6 and copy contents back

Notes:
[3] the goal in doing this from a broken/small filesystem to a
new/larger one is to minimize the time spent with a working (to some
degree) /usr, and to catch any problems early (preserving perms and not
crossing mountpoints were learned from missteps)

[5] libraries and _possibly_ ssh binaries (especially the new session
code) were corrupted on overflowed /usr. I figured getting sysupgrade
to run again would fix up not only things I knew about but things I
didn't, and this seemed to work. My alternate plan was to run a manual
upgrade, and only do a reinstall if both of those tries failed.

[7] given era of creation, the x11 slice was also greater than 50%
filled, so while fixing, fix that too

[sshd] Failure of sshd to start was possibly due to corruption, but is
more likely due to invalid (legacy) configuration directive that had
been preserved on that system: PubkeyAcceptedKeyTypes +ssh-dss. I found
it difficult to figure out because the failure isn't logged, and won't
show at the console using rcctl start [service] unless rcctl -d start
is used.

Thanks for the help, and big thanks for the OS. :-)

Amy!
--
Amelia A. Lewis amyzing {at} talsever.org
But pain ... seems to me an insufficient reason not to embrace life.
Being dead is quite painless. Pain, like time, is going to come on
regardless. Question is, what glorious moments can you win from life
in addition to the pain?
-- Cordelia Naismith Vorkosigan [Lois McMasters Bujold, "Barrayar"]

No comments:

Post a Comment