Kitz Forum
Computer Software => Linux => Topic started by: Weaver on April 23, 2023, 08:44:18 AM
-
When I have been installing new versions of Windows NT family operating systems, I have tended to put a new blank hard disk in and do a fresh install onto that, migrating user data from the old disk after the new o/s is up and running. I’m a bit suspicious of the reliability of software that does an in-place upgrade.
I was thinking about upgrading the versions of Linux on my two Raspberry Pis. I read an article about an in-place upgrade of Debian buster to the next version, mildly scary. In my case, especially so, seeing as I only have SSH access, no KVM, no GUI, and if the new version decides not to serve SSH access from the word go, then I’m dead. Isn’t the SSH server availability controlled by the presence or absence of some file? Kindly fellow kitizens did this for me, and I can’t remember the details.
Anyway, would it be mad to risk an in-place upgrade? - assuming that I can even follow the instructions. The sane thing to do would be to get a second SD card and that can be a backup / fallback. But I’ve no idea how to connect such a thing.
-
I see no problem with in place upgrade... done this plenty of times, sudo apt-get dist-upgrade , or sudo apt-get full-upgrade. "Full" should solve any conflicts! if they arise. Then run sudo do-release-upgrade.
Follow up by reboot and running sudo apt-get autoremove
https://askubuntu.com/questions/81585/what-is-dist-upgrade-and-why-does-it-upgrade-more-than-upgrade
-
Should be fine, I routinely remote upgrade unix based server machines.
Its supported officially, just check the documentation before you start. :)
-
Depends on the distro, I think there are still a few that don't officially support it and none will guarantee no problems. Although I upgraded Fedora for 10 years before doing a complete reinstall.
-
If the distro you are using supports in-place upgrades then it should all go ok, but as I'm sure you're well aware there is no such thing as certainty in the IT world...
I'd back-up any important files first, but I'm sure you'd be doing that anyway.
If it were to fail you'd be in a similar situation to doing a clean install, except I suppose that you'd have no working system disk to fall back on if the new install didn't play nicely.
-
What model raspberry pi, my v1s and bs take forever.
-
I have a raspberry Pi 3 B and a 4.
-
it'll fly on those,
what instructions are you following?
-
Are your Pi's running a 32 or 64 bit OS?
If 32 Bit Buster I believe it will upgrade to Raspberry Pi OS (Legacy) which is based on Buster
If 64 bit, the latest versions of Pi OS are based on Bullseye
-
The Pi 3 is running this clever systemd-nspawn pair of OS’s (see https://github.com/sakaki-/raspbian-nspawn-64 ) and with this I have 32-bit Raspbian v? plus Debian Buster AArch64.
The Pi 4 is running Ubuntu 20.x AArch64 (I forget the precise version number).
-
What are the headaches they speak of from just running a plain 64bit OS?
-
Could you explain, Alex? One of our number pointed me towards the clever container solution way back when I was asking about an AArch64 build, which wasn’t so easy to come by back then.
The problem with Debian Buster AArch64 is that the build of GCC GDC (for the D language) is broken. Comes up with stupid internal errors the moment you try to compile and link anything at all. I really need GDC as I want to try out some GCC-specific features, and I also want to try some AArch64 asm embedded in GDC-specific specialised D code. Luckily I also have the LLVM-based D compiler (called LDC or LDC2), so that means that I can produce AArch64 code from D source, and the compiler is very hugh quality. Unfortunately the way LDC handles embedded asm is not the same as GDC’s syntax, but hopefully the authors will help the developers out and converge the two syntaxes at some point, so that you don’t have to duplicate all asm inside compile-time ‘static-if’ statements (equivalent to #if/#ifdef in C), one block for each compiler.
However another thing I’m interested in is exploring GCC and GDC’s GCC-specific features, and so for that LDC is not an option, so AArch64 can’t be used in these experiments. I have the GDC compiler for 32-bit ARM architectures, so I can use that to explore GDC.
I also need to get the Raspberry Pi 4 up and running since it has its AArch-64 Ubuntu. That machine got buried in Janet’s filing system and was only rediscovered by archaeologists last week. So I want to upgrade that and then start doing some maintenance work on it.
An aside:
I finally solved the problem of how to remotely run programs in my ZyXEL modems from my iPad. The problem was that I write code for my iPad using the Apple Shortcuts framework. This offers a Shortcuts library routine that will SSH into a remote machine and then run some script on it. There’s some bug somewhere which causes the SSH connection setup to fail when talking to a modem using that Shortcuts routine. However, I did manage to set things up to run remote commands on the Raspberry Pi from the iPad successfully using the same Shortcuts routine. The code I wrote runs a bash script remotely and that script gets sent a block of data as an argument, which gets decoded, written to disk, and is then an arbitrary runnable script file, which finally gets run on the Pi. Now the solution came to me. I remotely, on the Pi, ran telnet into the modem, say spawn telnet 192.168.x.1 but under the control of an expect script. The expect script controls telnet and automates things, making it log into a modem and then it finally runs chosen commands in the modem’s ZyXEL command interpreter or even uses Burakkucat’s trick to break out and get into a real bash shell in the modem. And then the job is done. This works because I’m connecting to the modem using telnet in this case, not SSH, and so that avoids any problems with the modems’ SSH implementation, or who knows what is going on between the iPad and the modem regarding SSH from Shortcuts. I would never have had to do this if I had telnet library routines on the iPad plus the likes of an ‘expect’ function to do automation and remote control.
So now, for the first time ever, I can just hit an icon on the iPad and it forces a resync on modem n.
-
Only last night remotely upgraded a FreeBSD server in a DC, no issues.
Ubuntu and Debian can be upgraded remotely, if an OS doesnt support remote upgrading in 2023 then its not a competitive OS.
One note though, if you are more than one version old, then go to the next version, then do another upgrade after, dont skip a version.
An alternative idea if you risk averse is move to using VM's, as then you can snapshot the VM before starting as well as getting console access via the VM host. Or setup an ubuntu VM, practice on it, then do the real thing on your live device.
-
Ubuntu and Debian can be upgraded remotely, if an OS doesnt support remote upgrading in 2023 then its not a competitive OS.
I feel the same, was my bone of contention with CentOS as I was stuck on 7 for years and why I got an IONOS VPS as its not practical to lose my e-mail for hours to do a complete reinstall of my main VPS. Especially given fresh installs of Virtualmin can be a PITA.
Always thought that was odd given how well Fedora support upgrades.
-
I feel the same, was my bone of contention with CentOS as I was stuck on 7 for years and why I got an IONOS VPS as its not practical to lose my e-mail for hours to do a complete reinstall of my main VPS. Especially given fresh installs of Virtualmin can be a PITA.
Always thought that was odd given how well Fedora support upgrades.
You can upgrade from CentOS 7 to Rocky or Alma:
https://docs.rockylinux.org/guides/migrate2rocky/
https://almalinux.org/elevate/
-
You can upgrade from CentOS 7 to Rocky or Alma:
https://docs.rockylinux.org/guides/migrate2rocky/
https://almalinux.org/elevate/
I can't imagine that working well with Virtualmin, given when I DID replace my VPS I couldn't use it on Alma as it was not supported due to distro differences in paths. Granted, that's a Virtualmin issue and I ended up with Rocky which hopefully can update more seamlessly.