On Tue, 18 Aug 2020 at 09:44, Attila Pintér
Yep, same issue on this end. Rolling back fixes the issue then transactional-update dup and comment the @tmp mount to /tmp in fstab before a reboot. Seems to solve it for now.
I could not replicate this hack for some reason, do you mind to explain more? I checked my fstab after running the transactional-update dup and this is what I had for the /tmp; "UUID=435f85e7-f149-4419-bbef-5c3bafe73add /tmp btrfs subvol=/@/tmp 0 0" which I then changed to "UUID=435f85e7-f149-4419-bbef-5c3bafe73add /tmp btrfs subvol=/tmp 0 0" before updating but I still get the aforementioned issues. am I missing something here?
The most worrying part for me with this issues is that health-checker didn't catch this during boot. Starting it from the system manually does state that the system is not healthy.
worrying indeed!
Let me know if I can provide anything for debugging.
Br, A.
On Tue, Aug 18, 2020, 11:57 AM The Undertaker
wrote: I would like to confirm this, I started seeing this very exact behaviour earlier as well.
On Tue, 18 Aug 2020 at 07:58, Jim Heald
wrote: Hello! I don't know how to communicate "where" the breakage occurred, but with my latest snapshot (which was 10x bigger than my other snapshots, at 206MB) I observed the following behavior: 1. `/tmp` somehow became a mountpoint for `/`. As such, ls'ing /tmp and / returned the same results, and /tmp became ro, breaking some of my Docker services 2. `sudo` took an unreasonable amount of time. Before I decided to just become root, running something trivial such as `sudo echo hi` took 25 seconds (I typed my password in a previous sudo command)
I would also like to add a few other points that I have observed in this case, though still not having any idea what went wrong here.
1. The system is generally slower in doing pretty much everything now compared to before the update, that includes booting, logging in, and running commands in general.
2. upon boot, and before showing the login prompt, I know receive 5 lines of "failed to start login service" and one line of "failed to start NTP client/server"
3. My HPE Gen 10 DL380 server is in a small server room on a different floor, but now the NICs don't initiate anymore and I can only service it in person or through the HP iLO rather than remotely.
4. The only out of the ordinary prompt during the update process that I noticed was:
"(33/70) Installing: gtk3-tools-3.24.22-1.1.x86_64 [...............done] Additional rpm output: update-alternatives: warning: forcing reinstallation of alternative /usr/bin/gtk-update-icon-cache-3.0 because link group gtk-update-icon-cache is broken update-alternatives: warning: skip creation of /usr/share/man/man1/gtk-update-icon-cache.1.gz because associated file /usr/share/man/man1/gtk-update-icon-cache-3.0.1.gz (of link group gtk-update-icon-cache) doesn't exist"
but I don't have any clue how that pertains to this issue, if at all.
Doing `transactional-update rollback last` worked flawlessly,
In my case I rebooted > Start bootloader from read-only snapshot > chose the previous working snapshot > ran "snapper rollback" when system successfully rebooted.
Anything I can help with, count me in as well.
Cheers. -- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-kubic+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kubic+owner@opensuse.org