You are not logged in.
Thank you
pic from 1993, new guitar day.
Offline
Yesterday I upgraded from Chimaera to Daedalus without any issues. Here are the steps I followed:
Edit /etc/apt/sources.list to point to daedalus $ sudo apt-get update $ sudo apt-get upgrade $ sudo apt-get dist-upgrade # at the end there are some errors having to do with old version of linux kernel $ sudo apt-get autoremove --purge # this removes the packages that caused errors $ sudo apt-get dist-upgrade # now it completes without any errors $ sudo apt-get autoclean Reboot
I'm assume that we will be providing a note on how to upgrade as well as how to install from new and how to convert from Debian.
So I thought it might be useful to document my experience and any trip hazards I encountered.
I upgraded just over a week ago, using the same steps as described above.
Where it asked about if I wanted to accept new default config files I chose to keep those I already had.
I was already using the most recent backported 6.1 kernel prior to the upgrade.
A simple replace edit of sources list is however not entirely sufficient as you should add the 'non-free firmware' to each line.
With that change I had no problems in the upgrade as such.
I use unattended-upgrades to install any security package updates daily.
I had to change the line "o=Devuan,n=chimaera-security" to "o=Devuan,n=daedalus-security" in /etc/apt/apt.conf.d/50unattended-upgrades.
My motherboard (a MSI B550) use a custom chip to monitor fan speeds in particular.
There is a corresponding kernel module but it was not loaded. I ran
sudo modprobe nct6687.ko
to load it and then sensors could see it.
Grub no longer runs osprober by default. If you have been using it to create grub menu items to boot to alternative OS on your machine you will need to as root restore it in the file /etc/default/grub by un-commenting the line
#GRUB_DISABLE_OS_PROBER=false
and then run update-grub as root.
Also relating to grub the menu on my PC now works with my usb keyboard (it didn't on Chimaera).
rsyslog creates fewer log files, such as /var/log/mail.{info,warn,err}. The messages are still there in /var/log/mail.log.
If you have another program reading any of these, e.g. fail2ban, you will need to get it to read /var/log/mail.log instead.
Similarly /var/log/{messages,debug,daemon.log} are also no longer being updated. Their messages are still there in /var/log/syslog.
All these (and their log-rotated counterparts) can now be removed.
Logrotate itself is working as expected on my PC.
Just for info. I run Cinnamon. After the upgrade Gnome programs (such as Evolution and System Monitor) now duplicate the Max/Min/Close symbols and Title that are in the Window Title Bar in the top line of the program. Nothing fatal but it looks odd.
There are some changes in Bookworm (and hence Daedelus) that don't affect my PC but might others e.g. the packages that set the system clock and reduced accessibility support.
Changes to Bookworm (and by default Daedulus) are covered in the release notes' Chapter 5 Issues to be aware of for bookworm https://www.debian.org/releases/bookwor … on.en.html
Last edited by Marjorie (2023-07-17 20:23:53)
Offline
Yesterday I upgraded from Chimaera to Daedalus without any issues. Here are the steps I followed:
Edit /etc/apt/sources.list to point to daedalus $ sudo apt-get update $ sudo apt-get upgrade $ sudo apt-get dist-upgrade # at the end there are some errors having to do with old version of linux kernel $ sudo apt-get autoremove --purge # this removes the packages that caused errors $ sudo apt-get dist-upgrade # now it completes without any errors $ sudo apt-get autoclean Reboot
I only use the main component of the repository. In other words, my /etc/apt/sources.list now looks like this:
deb http://deb.devuan.org/merged daedalus main
Since I don't have packages from contrib or non-free, I cannot comment on the current upgrade experience if your Chimaera system includes packages from those components.
I wasn't that lucky. After upgrading, everything seems fine except that the shell (bash) and xorg (startx) will stall for like 20-30 seconds when called from a tty, which didn't happen on Chimaera.
It seems there is no cpu or disk activity during this time, it just stays there and does nothing then continues to start as normal.
This happens only with those two programs called from the ttys, even after exiting from the shell from there to force the init to start bash again it still stalls, but surprisingly none of this happens within xorg and no other programs are affected.
Any ideas? I'm not using sleep or hibernation so this basically slows down my boot time by a minute.
Offline
It seems there is no cpu or disk activity during this time, it just stays there and does nothing then continues to start as normal.
I was once affected by a very similar issue, where nothing would happen in the middle of boot process for about 30 seconds, then boot would continue as normal. In my case, the issue turned out to be that UUID of my swap partition had changed (because I deleted the old swap partition and created a new one), but initramfs had a record of the old UUID and was timing out while waiting for it to appear.
Have you changed any of your hardware or partition UUIDs recently? If so, try recreating your initramfs:
1. Boot as usual
2. Run sudo update-initramfs -u
3. Reboot
Offline
birdi wrote:It seems there is no cpu or disk activity during this time, it just stays there and does nothing then continues to start as normal.
I was once affected by a very similar issue, where nothing would happen in the middle of boot process for about 30 seconds, then boot would continue as normal. In my case, the issue turned out to be that UUID of my swap partition had changed (because I deleted the old swap partition and created a new one), but initramfs had a record of the old UUID and was timing out while waiting for it to appear.
Have you changed any of your hardware or partition UUIDs recently? If so, try recreating your initramfs:
1. Boot as usual
2. Run sudo update-initramfs -u
3. Reboot
It didn't work unfortunately, but it seems it stopped some random apparmor errors on boot which didn't impact anything. I think the problem is with openrc and agetty since if i exit bash with Ctrl-D or the exit command it still stalls just as much, no matter how many tries, this being after booting.
I will look more into it another time, as this is mostly for a testing computer where i constantly change hardware so rebooting slowly is a pain, this is why i still kept it on Chimaera.
Thanks for help anyway.
Offline
I would suspect something in /etc/profile or ~/.bash_profile, ~/.bash_login or ~/.profile might be causing the wait. I'd start by putting echo "In .bash_profile" at the start of ~/.bash_profile (or ~/.bash_login or ~/.profile, whichever you have) and see if that comes out before or after the pause. If it's after the pause (or you don't have any of ~/.bash_profile, ~/.bash_login or ~/.profile) then I would make a similar temporary change to /etc/profile to see if that's causing the pause. Then trace through the relevant script to find out what's causing the pause. Adding set -x to the script near the start could be helpful.
Keep notes of what you change so you can change it back when you have stopped investigating.
Offline
Other possibilities: network or firmware issues. Have you come across the new sub-repo for the non free firmware? You need to add non-free-firmware now to all lines in the sources.list if your hardware requires to load some firmware.
Online
@birdi, perhaps installing haveged makes a difference for you.
Offline
Thanks for all of you who tried to help me but i just fixed the problem. It turned out to be an oversight i made after the upgrade.
The problem was that the dbus-daemon service was set to start on boot. I know from experience that for some reason even small updates in general on debian re-enable services that are disabled by the user.
When i upgraded i also disabled with rc-update a lot services i don't need, but i somehow forgot about dbus. Now i have it disabled and the stall no longer happens.
Somehow dbus started from boot stalls /bin/login which is what affects bash and xorg. The dbus-launch and dbus-daemon started by xorg and other programs afterwards doesn't affect anything, everything is working just as before. I double checked this with xorg up and running and switching to the second tty and it doesn't stall.
Offline
Two important additions to the above post:
It seems that the bluetooth service has to be disabled as well or else it will start dbus-daemon on boot even if dbus itself is disabled from rc-update.
The specific problem is that when bash tries to start, the dbus-daemon seems to start a zombie subprocess and stalls bash for as long as it exists.
Hope it helps if someone else has this problem.
Offline