You are not logged in.
Pages: 1
I have been running Debian for a number of years (about 13) and am generally satisfied with the OS. However, I am becoming more and more convinced that Systemd is like a cancer and is spreading out of control. My desktop has two SSD's, each with Debian Bullseye installed. Let's call them drive A and drive B. Drive A is my daily driver and drive B is a fully bootable backup. I have been giving serious thought to migrating drive B to Devuan. I have read the page on migrating from Bullseye to Devuan Chimaera and it seems pretty straight forward. However I have some questions that I would like answered before I take the leap.
1. Can I do the migration using a terminal, such as the xfce terminal, so that I can keep the web page instructions in view while doing the migration? I would assume so, but assuming can be risky.
2. Since I am using grub on drive A will the update properly reconfigure grub on that drive? Actually, both drives have an MBR and grub is installed on both drives but A is the primary go to drive.
3. I have two pinned packages (I don't like the updated versions). Will those pinned packages cause any issues during migration?
4. I also have an older version of Tcl and Tk installed (8.4), but since those version were installed by the specific version number I don't think that should cause any issues. Any thoughts on that?
I think I had some other question but I can't remember it. Old age sometimes does that. LOL!
I will be awaiting a response with pleasant anticipation.
ps. Good to see some familiar and trustworthy members here that are also present on the Debian forum.
There are in fact two thing, science and opinion. The former begets knowledge, the latter ignorance. - Hippocrates
Offline
1) "Normally" a migration is done with the running OS, and in that case it's really a VT console level activity.
Last time I looked into it, the Debian system seemed to have some new layers of confusion with a series of (Windows-ish) steps to go through to reach a VT console level. That might be different now. The important bit is of course that the migration script needs to not be terminated prematurely when the init transition occurs, and therefore the shell that runs it must not be under any "session process control".
In your case, you could instead hook up drive B as the disk for a qemu virtual machine, and then migrate within that while idling in front of the browser on the "main" OS, drive A. The only particular quirk with that would be how to make drive B bootable by qemu (perhaps using extlinux)
In all cases you'll need a final grub setup after the migration; i.e. running update-grub with OS A to let it (re-)discover the drive B OS.
Though, I think I would call that a 201 activity as it does require sllghtly more than notional knowledge about running a qemu virtual machine, and about equipping it with an extlinux boot. It might not be your ideal solution but that's the way I can think of to let you view the instructions while following them. Printed on paper might be a better option.
2) You will need to re-update grub with OS A. Possibly already at the first of the two migration reboots.
3) The pinning will be preserved and shouldn't cause any issue ... unless, well, unless something.
4) And it shouldn't be an issue with keeping the old Tk either.
Offline
Thanks for that feedback ralph.ronnquist. I had to to do a search to even find out what qemu is. Sounds to me like it is adding a level of difficulty to the process, but maybe that's because I'm a bit slow. I was hoping to just boot into drive B and do the upgrade. When I do a Debian upgrade on drive B and there are updates to the kernel that create a new grub config, the new config is written without problems. I understand that I would then have to boot back into drive A and update grub, but that isn't beyond my capabilities. LOL!
I guess my biggest concern was that the migration would somehow modify, and make dysfunctional, grub on drive A. I guess that a super safe way of doing the migration would be to disconnect drive A and boot directly into drive B. Afterwards, assuming drive B is working correctly, I could boot into drive A and do the grub update.
I'll need to think on this a bit. I will post my results after I have made the decision and pull the trigger.
Maybe I should have also added that I boot in the legacy mode (no efi here). Hopefully that is not an issue.
There are in fact two thing, science and opinion. The former begets knowledge, the latter ignorance. - Hippocrates
Offline
Pages: 1