There is now a new migration script available that I have written. It's called Migrant, and  you can get it from Debian's Salsa.

It was developed and tested only with one migration in mind, namely Bullseye to Chimaera.

It is slightly enigmatic. Not because I'm lazy, but because that's what I want it to be. Sorry to all interested but less advanced.

In the local landscape, it falls near rrq's script. Not so much though, as they strongly diverge in various ways, so beware of false expectations. There are three noteworthy similarities:

1. It requires a cable connection. This is both a sefety measure and a vulnerability at the same time. While it reduces the network stack, it also requires it during multiple phases. It would be safer to work with downloaded packages. And it would be handy to have the wireless supported. These two are TODOs. Good enough for a simple beginning though.

2. If you run it from a terminal, use a kernel tty. I made this a somewhat strict requirement. If you outsmart the pts check, it may backfire. This is easy to do, as no controlling terminal is required.

3. Any GUI present in the original OS may be removed. Migrant offers no replacement though, unless you program it yourself.

To learn more about Migrant, you will have to read the script.

Final word. I will most likely have no time to maintain or develop Migrant further in the foreseeable future. Willing and able may step in.

After a few years with Debian and a few with Ubuntu earlier, I moved recently to Dev. It took me three times to finally land.

The line I took initially was the official migration instruction. It looked easy, but failed twice. The third attempt was with a USB installer and went without bigger problems.

The first jump was from a slightly aged and used Debian, which was upgraded before. I had a few extras there, over a rather basic system, like libvirtd. After the first fail I thought I'll try again beginning with a fresh Bullseye installation to reduce dependencies. It got so bad the first time that I needed to install something operable anyhow. But let's stick to the first attempt.

The scenario begins with a reconfiguration of apt. I thought it was fishy to follow the instruction verbatim. The protocol in the URL is "http", then apt update is done with --allow-insecure-repositories. Not a good mix to my nose. I took devuan-keyring from the official repo over HTTPS. I also tried to use the official repos as seen in the sources.list with HTTPS, but that didn't work. A cert error, I gather. This was a smooth beginning.

The three steps that follow the update are where der Hund ist begraben. To recall:

1. apt-get upgrade

2. apt-get install eudev sysvinit-core

3. apt-get -f install

After the installation step, problems are to be expected. They might have begun already at step 1. I was not logging and didn't know, what exactly to expect. I was ready to crash, so was a little light-hearted. I spent hours trying to figure out, what's going on. Troubleshoot, etc. I only spiralled into a complete mess with initrd rebuilding via the emergency line. I remember I couldn't uninstall some component and I needed to badly, as it blocked a reinstallation of initramfs-tools, which I needed for my encrypted disk. It was locked dead. It might have been systemd itself or some other "low" cog. The feedback from Apt was very misleading and I finally gave up.

The second try was similar to the first one. There was a difference in that the problems began as planned in the instruction. So I remember it. Strange, but I can't recall the details of this second round. I was after many, many hours of struggles and had a Devuan installer on my USB.

The third attempt with the USB was easy. But for me forgetting to mark the boot partition for inclusion in fstab twice. (Why twice?!) Here I think one feature is missing, or I don't know how to. Namely, the partitioner doesn't present an option to decrypt an already present Luks. And so a previous setup with LVM over Luks cannot be reused. Pity!

Conclusion. The migration process is nicer described than done. Only just now I have found that there's a shell script linked at the end of the instruction. I missed it somehow. Maybe I didn't get that far in my preparations. I can see that it diverges from the instructions for humans. It is no less smart than me in fetching the key ring. And it certainly is more detailed and granular than the human copy.

Were I to improve this instruction, I'd definitely expand on what to expect when.

May cause? Not "will cause"? Why? When will this be resolved? When things go wrong these become important.

Finally, an inverse instruction would be a good sign to potential newcomers. From Devuan to Debian. It's about choice in the end, right?