You are not logged 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:
apt-get upgrade
apt-get install eudev sysvinit-core
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.
The last command may cause package breaks but they will be resolved as part of the migration process.
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?
Last edited by tomasz (2022-08-03 01:14:57)
Offline
Welcome to the forum and thanks for taking the time to share your migration experience. I am only going to comment on the use of http vs https.
Please have a look at this page for basic information about Devuan's round-robin of repositories. If you want to use https, chose a specific mirror from the mirror list for your sources.list configuration. There is additional information about how the mirrors are set up here.
Any improvements to the current migration documentation would be appreciated.
Online
Any improvements to the current migration documentation would be appreciated.
How can this be done?
Offline
golinux wrote:Any improvements to the current migration documentation would be appreciated.
How can this be done?
@tomasz . . .
1. Please open an account at https://git.devuan.org/
2. Clone the document you will need to edit
3. Commit you changes for review
I have asked the webmaster to identify the exact document from which you should be working as I was unable to discern the workflow from /documentation to /www.
Stay tuned . . .
Online
@golinux
I've got it. It may not be the best time in the life though. Tx.
Offline
@tomasz . . . I think I found the problem!
The instructions should begin with this:
# Migrate from Debian Bullseye to Chimaera
It's necessary to [configure your network](network-configuration.md) before you begin, otherwise you will lose network access during the migration.
For migration from Debian Bullseye to Chimaera you need to install sysvinit-core before continuing.
root@debian:~# apt-get install sysvinit-core
. . .
I see now that this change was made to an incompletely updated file - that line was added but the other release references on the page were not updated and the page never transitioned to the Devuan website. Totally a screwup on our end to have missed that.
Would it be possible for you to test a migration adding that instruction?
Online
@golinux
1. There definitely was a problem with my network connection. I forgot about it. I couldn't download some packages and it was a blocker in the process.
2. You didn't link an url in the markup. Please update.
3. This is not a good moment for me to test the migration. I might not finish this task soon. Please ask someone reliable.
Offline
Hi, adding to this. What a coincidence, I too was migrating from bullseye yesterday. This is what I did:
I followed the instructions here https://www.devuan.org/os/documentation … o-chimaera
1. Comment out all the old lines in sources.list, add the new devuan lines
2. sudo apt update --allow-insecure-repositories resulted in NO_PUBKEY error, I happened to find this page https://beta.devuan.org/os/keyring even though it wasn't linked in the guide, and downloaded and installed the keyring manually with dpkg -i devuan-keyring_2017.10.03_all.deb
3. Then I did apt install -y devuan-keyring and it was up to date
4. sudo apt update and sudo apt upgrade went fine
5. The real problems began in the next step when I did sudo apt install eudev sysvinit-core - I definitely got package breakages, I don't have logs now but it was trying to uninstall things in order to install eudev. Sysvinit installed. I don't know if everything installed or uninstalled correctly, I thought it did, but after trying to force it several times with variations of apt -f install and specifying the packages... It seemed like I did the most I could, and the instructions made me think that it would get resolved "during the migration process"... So I took a risk!
6. Sudo shutdown -r now and I am sitting in front of a screen that says it's looking for a btrfs filesystem (I don't have that) and RAID (don't have that), then it does a fsck, the ext4 system is clean, mounts with "Opts: (null)".. It says /scripts/local-bottom...done. /scripts/init-bottom...done. A warning that it is "Not activating Mandatory Access Control as /sbin/tomoyo-init does not exist." Init version 2.96: booting. And finally, "INIT: No inittab file found. Enter runlevel: ""
I'm trying to think the best strategy to get my system back up without losing any data or desktop configurations. I know I can do a rescue disk, but maybe I can do single user made and get it back up?
I think it's saying that openrc boots but there is no inittab file, so it doesn't know what to do. Also this confirms to me that sysvinit did install and systemd is definitely gone. Maybe eudev is missing, I don't know right now.
Last edited by auanta (2022-08-03 20:07:41)
Devuan GNU/Linux, the sysadmin secret sauce
> "I use Hyperbola btw" my favorite BSD
Disclaimer: If I give you any technical advice, always double check it, because even though I used GNU/Linux many years, I'm still learning, just like you. I try to help, but I could be wrong! Empower yourself!
Offline
Ah nope, can't enter any runlevel, it just prompts me again. But if I turn it off and boot into recovery mode, I can do runlevel 1 but then it says "no more processes left in this runlevel"
Devuan GNU/Linux, the sysadmin secret sauce
> "I use Hyperbola btw" my favorite BSD
Disclaimer: If I give you any technical advice, always double check it, because even though I used GNU/Linux many years, I'm still learning, just like you. I try to help, but I could be wrong! Empower yourself!
Offline
@golinux
2. You didn't link an url in the markup. Please update.
Ha . . . forgot to add the URL to the markdown. Fixed.
3. This is not a good moment for me to test the migration. I might not finish this task soon. Please ask someone reliable.
It will be tested when it's tested. At least we are now aware of the problem so thanks for the helpful input.
(golinux waits to hear from Xenguy . . . )
Online
Maybe you can enlist me in the migration testing. What do I need to do? @golinux
Devuan GNU/Linux, the sysadmin secret sauce
> "I use Hyperbola btw" my favorite BSD
Disclaimer: If I give you any technical advice, always double check it, because even though I used GNU/Linux many years, I'm still learning, just like you. I try to help, but I could be wrong! Empower yourself!
Offline
Maybe you can enlist me in the migration testing. What do I need to do? @golinux
Thanks for the offer, auanta. I am waiting for the Webmaster to sort it and upload the corrected instructions to devuan.org. I'll let you know when that's sorted.
Online
@auanta
1. apt install -y after dpkg -i is not necessary. It boils down to the same thing. But for nuances perhaps.
2. You forgot about the upgrade step. Did you forget to mention it or to perform it also?
3. Tomoyo for MAC is strange. Did you use it in Bullseye?
4. Where would openrc come from?!
Offline
I see now that this change was made to an incompletely updated file - that line was added but the other release references on the page were not updated and the page never transitioned to the Devuan website. Totally a screwup on our end to have missed that.
I can't tell, which line was added. Do you mean this commit?
I can't find your version anywhere in git. Was there a pull request?
The web site doesn't seem to mirror this repo at all.
This looks bad indeed. I think you should suspend this feature asap until it's fixed and tested well.
Offline
@golinux
I've got it. It may not be the best time in the life though. Tx.
In fact I have not. I can't log in. (To the web interface of git.)
Maybe because I'm a Most Notorious Spammer?
Last edited by tomasz (2022-08-03 20:20:44)
Offline
@auanta
2. You forgot about the upgrade step. Did you forget to mention it or to perform it also?
Oops, forgot to mention that, it went smoothly with the keyring installed. If there's any difference through apt I would have to redo the migration, and see if apt complains. As this is not a virtual machine, I have to rescue my computer first.
3. Tomoyo for MAC is strange. Did you use it in Bullseye?
4. Where would openrc come from?!
No, I've never heard of tomoyo before, I haven't used MAC either, only MAC addresses obviously It seems to be very confused of even what kind of system I have. Ok, the openrc being there was just a guess. So I guess I got sysvinit but it's missing configuration scripts...
Last edited by auanta (2022-08-03 20:32:02)
Devuan GNU/Linux, the sysadmin secret sauce
> "I use Hyperbola btw" my favorite BSD
Disclaimer: If I give you any technical advice, always double check it, because even though I used GNU/Linux many years, I'm still learning, just like you. I try to help, but I could be wrong! Empower yourself!
Offline
golinux wrote:I see now that this change was made to an incompletely updated file - that line was added but the other release references on the page were not updated and the page never transitioned to the Devuan website. Totally a screwup on our end to have missed that.
I can't tell, which line was added. Do you mean
this commit?
Yes, that line. `root@debian:~# apt-get install eudev sysvinit-core`. sysvinit-core was added to that line but never made it into the instructions on the website.
I can't find your version anywhere in git. Was there a pull request?
The funky version - bullseye-to-chimaera.md - is listed on this page which is not even edited properly for chimaera!
The web site doesn't seem to mirror this repo at all.
This looks bad indeed. I think you should suspend this feature asap until it's fixed and tested well.
The website repo is HERE. I always worked directly on www but the new web person is doing it a different way (which I never understood). Seems it might need a rethink if important stuff like this is falling through the cracks . . .
Online
Hmm, that's interesting, I feel silly saying this (maybe I didn't understand) but I did (and do) see that line on the website, it seems both @tomasz and I ran basically the same instructions (which included apt-get install eudev sysvinit-core). Maybe it was something specific to bullseye that makes this migration need more version-specific instructions.
Devuan GNU/Linux, the sysadmin secret sauce
> "I use Hyperbola btw" my favorite BSD
Disclaimer: If I give you any technical advice, always double check it, because even though I used GNU/Linux many years, I'm still learning, just like you. I try to help, but I could be wrong! Empower yourself!
Offline
If there's any difference through apt I would have to redo the migration, and see if apt complains. As this is not a virtual machine, I have to rescue my computer first.
I don't understand. What difference?
Tomoyo is an alternative to AppArmor, which is used by default in Debian and to SeLinux, which is is by default in Ubuntu (I may be wrong here). AppArmor is on by default in Dev1 also. So you may want to check this out on Wikipedia :-) Again, it is odd that Tomoyo is checked here. Just my nose guess. Your system logs might be useful for fixing this cluster-bug (?). Be careful though when including your logs in bug reports, as they will include your personal data. So think five times before you publish them. And just pick the right regions if you decide to publish.
Last edited by tomasz (2022-08-03 21:08:16)
Offline
Whatever this file is, which you cite here, it is the key to this mystery. At least to its first door.
# Migrate from Debian Bullseye to Chimaera
It's necessary to [configure your network](network-configuration.md) before you begin, otherwise you will lose network access during the migration.
For migration from Debian Bullseye to Chimaera you need to install sysvinit-core before continuing.
root@debian:~# apt-get install sysvinit-core
The line about network configuration is undoubtedly important and it is missing in the official instruction.
Offline
The website repo is HERE. I always worked directly on www but the new web person is doing it a different way (which I never understood). Seems it might need a rethink if important stuff like this is falling through the cracks . . .
Ok. I need to take a look, what's there.
I'd need more details about how you did it before and how it's done now to give you an intelligent answer. If I were architecting this flow though, I'd target simplicity. So something like:
Git (as version control and integration control) --> deployment (via some channel to the HTTP server)
With definitely no manual edits after Git. No matter what.
Offline
Not my problem anymore . . .
Online
Hey folks I booted into a debian 11 netinstall and am in rescue shell, my system is otherwise fine besides boot issue, it seems the first task is to fix the dependency hell from within rescue shell. My system doesn't want to install eudev. Here's what it looks like:
# apt install eudev
Reading package lists... Done
Building dependency tree... Done
Reading state informatian... Done
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
eudev : Depends: libeudev1 (= 3.2.9-10-chimaera1) but it is not going ta be installed
Breaks: systemd (> 220) but 247.3-7 is to be installed
libpam-elogind : Depends: elogind (= 246.10.2) but it is not going to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).
When I try apt install eudev libeudev1 it complains that it conflicts with libudev1.
Not sure if I need to uninstall libpam-elogind.
In anticipation of network issues when boot is fixed I configured the network manually according to instructions here https://git.devuan.org/devuan/documenta … uration.md
Last edited by auanta (2022-08-04 02:28:20)
Devuan GNU/Linux, the sysadmin secret sauce
> "I use Hyperbola btw" my favorite BSD
Disclaimer: If I give you any technical advice, always double check it, because even though I used GNU/Linux many years, I'm still learning, just like you. I try to help, but I could be wrong! Empower yourself!
Offline
Good luck with that!
And what's this?!
Reading state informatian... Dano
Offline
Good luck with that!
And what's this?!
auanta wrote:Reading state informatian... Dano
Typo...fixed lol
Devuan GNU/Linux, the sysadmin secret sauce
> "I use Hyperbola btw" my favorite BSD
Disclaimer: If I give you any technical advice, always double check it, because even though I used GNU/Linux many years, I'm still learning, just like you. I try to help, but I could be wrong! Empower yourself!
Offline