Comment by ryandrake | Hacker News Reader

Comment by ryandrake | Hacker News Reader

Parent Full thread

Coincidentally, I ran into one of these this week. I decided to upgrade my bog-standard Debian installation on a headless NAS from buster to bookworm. Should have been easy peasy: Update sources.list and then apt full-upgrade, right?

Wrong.

Half way through, Debian seems to have lost[1] libcrypt.so.1, which everything important in the system relies on. Could no longer sudo (needs libcrypt) from the session I was logged into. Couldn't re-log in at all either over the network (ssh needs libcrypt) or locally (local authentication needs it too). Could not even get to single-user mode because init=/bin/bash didn't even work. I ended up having to boot from a liveCD, re-assemble the raid partition containing my root filesystem, and manually copy libcrypt into /lib/x86_64-linux-gnu/

All because I tried to upgrade Debian from 10 to 12, skipping a version, which, apparently you can't do anymore.

As much as I can't stand Windows and I grin-and-bear macOS, I've never had an experience even close to as bad as that on those systems.

1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993755

Recently had a Windows update break my work computer. Everything seemed fine until trying to run a Windows Service in Virtual Box with the HOST OS being Windows 10 IoT in RTOS mode. The attempt to start the service create an infinite loop. Uninstalling nor re-installing the Windows updates fixed the issue. Took a month to convince IT to re-install Windows from fresh to fix the issue.

The second most recent was when Windows Store local repository become broken. Any attempt at resolving the issue failed using Windows provided tools. Yet again had to reinstall the OS and all applications.

This is the big reason why I prefer Linux over Windows any day of the week. Windows fix always seems to be the same, re-install OS and applications. Never had a problematic Linux installation that couldn't be resolved with a live CD / USB. Boot into live USB, mount encrypted partitions, chroot into environment, fix problematic package(s) or re-edit configuration files, reboot. No need to reinstall the OS and all applications.

Linux packaging system(s) are heaven compared to the Windows update hell-scale. Ever have to find a way to update the Root Certificates in order to install .NET Framework 4.7.2 offline on Windows 7 Embedded SP1 that is air gaped and has not had an update since the computers were shipped? Not fun.

>The second most recent was when Windows Store local repository become broken. Any attempt at resolving the issue failed using Windows provided tools. Yet again had to reinstall the OS and all applications.

oh man, I had my Windows install get into a weird state where trying to open 'Updates & Security' would just crash the Settings app altogether. Eventually I submitted a feedback hub report for it with a dump and tttrace (though that was a journey in and of itself) and in the meanwhile I actually managed to get updates installed via the PSWindowsUpdate powershell module. Alas, that still didn't fix the crashing Settings app. I had a friend at MS promote my feedback hub item to a bug who relayed the reason being that my copy of MusUpdatehandlers.dll was corrupt somehow. Ok, I guess I can try using sfc and dism to hopefully repair that. A couple rounds of that and all I learnt was I actually had a few more update related DLLs that were also corrupted. The real kicker being the copy in the store was also corrupted??

  2022-05-25 16:40:41, Info                  CSI    00000226 [SR] Could not reproject corrupted file \??\C:\WINDOWS\System32\\updatepolicy.dll; source file in store is also corrupted

Anyways, I was too stubborn to just reinstall and got it fixed by grabbing an install.wim from an ISO that matched my install and telling dism to use that. The really dumb thing was i first tried to do the repair in offline mode pointing it at the install.wim for sources but turns out that's just not supported. Instead you get some opaque failure message and it only mentions the fact that wasn't supported in a single line buried in the huge log file.

It was unsupported to jump releases while upgrading twenty years ago when upgrading woody to sarge as is now. Don't spread rumours. I've been there and the READMEs are still online for reference [1]. And unsupported does not mean impossible. One just can't blame the distro for a failed install.

And if you had bothered to read the Release Notes for bookworm: It's in there [2]. Also you are instructed that only upgrades from bullseye are supported, and to upgrade to bullseye first if you are running an older version.

Nobody else to blame for your fall.

[1] https://www.debian.org/releases/sarge/i386/release-notes/ch-... [2] https://www.debian.org/releases/stable/amd64/release-notes/c...

I've been using Debian since before woody, and am well aware of the usual caution against jumping versions. I have jumped versions in the past with very little pain despite it being officially unsupported. Obviously this time I gambled and lost as it clearly breaks your system more severely than usual.

None of that changes the user-experience comparison with mainstream OS's or parent's point about Linux's "‘stability vulnerabilities’ where the user has to tread carefully". Linux is well known for being a sharp tool without safety guards. That, and the "RTFM" tone of the typical response to trouble, are some reasons why the Year Of The Linux Desktop is perpetually stuck somewhere in the future.

The fact you can fix anything (even a misguided attempt) in 15mins with a live drive is a great strength imho. Back in the 90s you’d often have to reformat partitions to recover any OS.

Windows doesn't let you upgrade from Vista to 10, so I guess your complaint is they didn't stop you from manually editing configuration files manually?

Reply on news.ycombinator.com