The officially official Devuan Forum!

You are not logged in.

#1 Re: Desktop and Multimedia » which tool for changing WLAN access » 2022-08-18 21:18:20

You can try nmtui. It is provided by the package network-manager, which is not the same as network-manager-gnome. Is that light enough?

#2 Installation » Migrant - a new migration script » 2022-08-13 16:54:58

Replies: 0

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.

#3 Re: Installation » Revised migration page on www » 2022-08-08 17:38:27


I don't remember that issue. I'd have to meditate, it was so long ago. I might not recall. What I meant about networking here was linked to my other thread about this topic here and post #6 in particular.

#4 Re: Installation » Revised migration page on www » 2022-08-08 05:03:05

auanta wrote:
tomasz wrote:

Looks like someone's forgotten about the network again. Or is this on purpose?

Please share the output of the error you are seeing?

Are you feeling accused?

#5 Re: Installation » Revised migration page on www » 2022-08-08 03:20:54

Looks like someone's forgotten about the network again. Or is this on purpose?

#6 Re: Installation » Bullseye migration story » 2022-08-05 15:25:34

Some things are not meant to be guessed.

#7 Re: Installation » Bullseye migration story » 2022-08-05 14:35:32

golinux wrote:

@tomasz . . .  What we choose with each intentional action sets the course of our life. Easy to shoot oneself in the foot so best to choose wisely . . .

Hard to disagree. But the filter situation also means that if I have something to share with you, it will be published on Debian's Salsa.

#8 Re: Installation » Bullseye migration story » 2022-08-05 13:42:20

auanta wrote:

Not sure if I should open an issue for your trouble logging into git web interface. @tomasz

Thanks. That's nice. That is not a bug, but a feature. Thanks to the spammer filter. I disregard that filter. And this translates into me being banished.

#9 Re: Installation » Bullseye migration story » 2022-08-05 09:39:15

There is documentation in the web repo. Let me mark it for you in the tree.

├── bin
├── data
├── etc
│   └── nginx
│       ├── sites-available
│       └── snippets
├── lib
├── locales
└── source
    ├── error
    ├── os
    │   ├── announce
    │   │   └── report


    │   └── documentation
    │       ├── design-guide
    │       ├── dev1fanboy
    │       │   ├── en
    │       │   ├── es
    │       │   ├── img
    │       │   └── it
    │       └── install-guides
    │           ├── ascii
    │           │   └── img
    │           │       └── live-gui
    │           ├── beowulf
    │           │   └── img
    │           │       └── live-gui
    │           └── chimaera
    │               ├── css
    │               ├── img
    │               │   └── live-gui
    │               └── pics


    └── ui
        ├── css
        │   ├── debbugs
        │   ├── fonts
        │   └── pkginfo
        └── img
            └── 404

#10 Re: Installation » Bullseye migration story » 2022-08-05 02:38:23

auanta wrote:
tomasz wrote:
auanta wrote:

I'm searching up and down, and only see one documentation repo. So I think we're ok on that.

No. There are two. Why otherwise would you report a bug on one of them mentioning the other?

I mean, in theory there could be two repos, but then where is the second repo? In my bug report I reference the live site at and the repo at but no secondary repo. is secondary.

#11 Re: Installation » Bullseye migration story » 2022-08-05 02:13:59

auanta wrote:

I'm searching up and down, and only see one documentation repo. So I think we're ok on that.

No. There are two. Why otherwise would you report a bug on one of them mentioning the other?

#12 Re: Installation » Bullseye migration story » 2022-08-04 12:52:07

I remember my network problem. It was both the interface and the DNS resolution.

The first one can be handles on the go with ip.

As for DNS, I may be slightly wrong here, but Bullseye would link /etc/resolv.conf to a dynamic entry in /proc (or so). Strictly speaking, that would be Network Manager. Then after some (?) step, the file would be just an empty regular one. So you need to put your DNS server(s) there.

#13 Re: Installation » Bullseye migration story » 2022-08-04 12:24:11

I've inspected the situation around this process and there are many things that I don't understand or think need fixing. I'll address only two now.

First of all, it's not clear, why there are two repositories for documentation. Does the first one (documentation) have any stand-alone purpose? Does it have to exist at all? With just one repository, there would be fewer integration problems. I'd just operate in the MD format (which can be simply plain text if clarity is preferred) and shift translation to HTML further in the build process. The HTML files are just artefacts. Of course there's a point in archiving them, but I wouldn't version them this way. A CI/CD line should take care of this.

The documentation repository (again, documentation) as it stands now would benefit from a clear licensing info. I see such notes in various files, but it's unclear in general, for the whole repo. Compare with the website repo, where this is explicit at the very top of the tree. The shell script linked in the migration instruction is simply unlicensed. A single SPDX line would do. But README.adoc also needs this info.

#14 Re: Installation » Bullseye migration story » 2022-08-04 02:25:36

Good luck with that!

And what's this?!

auanta wrote:

Reading state informatian... Dano

#15 Re: Installation » Bullseye migration story » 2022-08-03 21:31:59

golinux wrote:

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.

#16 Re: Installation » Bullseye migration story » 2022-08-03 21:19:38

Whatever this file is, which you cite here, it is the key to this mystery. At least to its first door.

golinux wrote:

# Migrate from Debian Bullseye to Chimaera

It's necessary to [configure your network]( 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.

#17 Re: Installation » Bullseye migration story » 2022-08-03 21:07:39

auanta wrote:

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.

#18 Re: Installation » Bullseye migration story » 2022-08-03 20:19:07

tomasz wrote:


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?

#19 Re: Installation » Bullseye migration story » 2022-08-03 19:46:31

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?

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.

#20 Re: Installation » Bullseye migration story » 2022-08-03 19:11:56


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?!

#21 Re: Installation » Bullseye migration story » 2022-08-03 17:56:12


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.

#22 Re: Installation » Bullseye migration story » 2022-08-03 16:42:55


I've got it. It may not be the best time in the life though. Tx.

#23 Re: Installation » Bullseye migration story » 2022-08-03 10:48:27

golinux wrote:

Any improvements to the current migration documentation would be appreciated.

How can this be done?

#24 Installation » Bullseye migration story » 2022-08-03 01:13:20

Replies: 45

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.

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?

#25 Re: News & Announcements » Can't register because you are a 'spammer'? » 2022-08-02 22:44:33

Good place for my first post. I got blacklisted and twice. Two addresses. I'll leave it this way. This will possibly add a nice human touch to some of my future forum registrations.

As for here, no note is printed in the registration form regarding this anti-spam mechanism. And at least on thing should be mentioned. Namely, that my IP and e-mail will be shared with a third party on the very first registration submit button click. No matter, how I set my privacy preferences in the form.

Another thing that might be mentioned there is the "do not attempt to sign up again". I'm not sure if it was missing or not at registration failure. Would it hurt to include it in the standard initial form?

Let me now say, hi forum! I've had Dev for a few days now and I like it so far.

Board footer

Forum Software