Upgrading from Beryllium to experimental Boron

rbh · 2023-02-07 11:58:50

A thread about upgrading a Beryllium system to Boron, using the experimental packages now available
Please post hints and tips on the upgrade process, or issues you ran into.

If you have an Beryllium/Bullseye system, you can migrate to Boron/Bookworm, by editing sources. (Just avoid migrate productive system yet...).

Basic debian sources:

deb http://deb.debian.org/debian bookworm main contrib non-free non-free-firmware
deb http://deb.debian.org/debian bookworm-updates main contrib non-free non-free-firmware
deb http://deb.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware

Note: debian-security for bookworm, is a "dummy". Testing does not get any security upgrades from debian-security.
If you have auxilary sources like backports and proposed-updates, don't forget to update them to.
If you have FastTrack, disable it. It is only available for stable and oldstable.

---
Edited by johnraff - this is now the OP of its own thread so I added a header explaining the thread's purpose.

Last edited by johnraff (2023-02-09 08:33:15)

johnraff · 2023-02-08 01:02:17

Debian try hard to make the upgrade process smooth but there are usually complications, depending on the individual user's setup.

Don't forget to update the BunsenLabs source entry too:

deb https://pkg.bunsenlabs.org/debian boron main

NOTE: Debian Testing gets no updates from debian-security but it's probably a good idea to enable the repository in apt sources anyway, so as not to be caught out later. The bl-welcome script will check for it. (In fact the Debian Installer seems to enable debian-security out of the box.)

Last edited by johnraff (2023-02-09 08:29:40)

hhh · 2023-02-08 03:37:08

I've upgraded to Bookworm/Boron via apt. The recommend two-part upgrade...

sudo apt upgrade --without-new-pkgs

Reboot.

sudo apt full-upgrade

Reboot.

https://www.debian.org/releases/stable/ … ading-full

No issues, except for a couple of overwrites because I overwrote the recommended "N" options to get the new stuff.

Win, Kernel 6 (if BL isn't controlling your grub then you have to sudo update-grub from your main OS that controls Grub).

Lose, the power-manager sytray icon is still black. We'll get that sorted.

hhh · 2023-02-08 03:41:16

And yes, keep the dummy sources list security entries, they'll go live when Bookworm does.

johnraff · 2023-02-09 08:22:19

Upgrading can be trickier than a clean install, depending on what customizations a user might have done on their system.

Last edited by johnraff (2023-02-09 08:33:52)

johnraff · 2023-02-14 07:10:44

I checked over Debian's recommendations for upgrading Buster>Bullseye and the still WIP bookworm release notes before trying an upgrade on a Beryllium VM I had been using for a while, to see how it went on a system with some extra packages and customizations, and also as a practice run before upgrading my laptop.

I'll maybe write this up into a proper HOW-TO later, but for now, some things picked up from those two documents:

First, make sure the system is right up to date, and remove any packages you no longer need. They will slow down and complicate the upgrade.

sudo apt update
sudo apt upgrade
sudo apt autoremove
sudo apt autoclean
sudo apt install deborphan
deborphan
# remove unwanted packages eg compton gnome-themes-standard)
# remove deborphan if you don't want to keep it

“Obsolete and Locally Created Packages” can be listed and purged from the commandline with:

apt list '~o'
# and possibly:
sudo apt purge '~o'

But check carefully before purging!

Clean up leftover configuration files

sudo find /etc -name '*.dpkg-*' -o -name '*.ucf-*' -o -name '*.merge-error'

Remove files if really unwanted.
(I got /etc/bunsen/picom-startup.dpkg-old )

Use synaptic to check over big packages - do you need them all?
Settings>Preferences>Columns and Fonts: make sure "size" column is displayed, move it near the top.
Then in main display on the left choose Status>Installed, click on the Size column to get the biggest ones at the top.

If you know your hardware - and what firmware it needs - well, some of the firmware packages are pretty big and might possibly be candidates for removal.

If you have manually added other packages or files, like fonts, then you should remove them before starting the upgrade. They can be the cause of mysterious errors, eg https://forums.bunsenlabs.org/viewtopic … 65#p126265
You can re-add such software after the upgrade if you still need it.
---
Tidy up apt sources:

Change every occurrence in your apt sources of bullseye to bookworm and beryllium to boron.

If you have non-free firmware installed (you very likely do) add non-free-firmware to your debian lines in /etc/apt/sources.list
https://forums.bunsenlabs.org/viewtopic … 66#p125866

If you have Debian or BunsenLabs backports enabled, comment those lines out. After the upgrade, the backported packages you were using might be in the regular repos, but you can re-enable the backports later, if you want.

"If you have listed the proposed-updates section in your APT source-list files, you should remove it before attempting to upgrade your system. This is a precaution to reduce the likelihood of conflicts."

The same probably applies to Debian Updates.

Temporarily comment out any 3rd party sources you may be using, and after the upgrade, check if there are bookworm versions, and maybe reconsider if you need them anyway.

Disable any apt pinning.
see: https://www.debian.org/releases/bookwor … pt-pinning

"Regardless of the method used for upgrading, it is recommended that you check the status of all packages first,
and verify that all packages are in an upgradable state. The following command will show any packages which have a status of Half-Installed or Failed-Config, and those with any error status"

sudo dpkg --audit

(nothing for me)

"It is desirable to remove any holds before upgrading. If any package that is essential for the upgrade is on hold, the upgrade will fail."

apt-mark showhold

(nothing for me)

---
The system upgrade:
Now apt sources have been edited:

sudo apt update

I got "1271 packages can be upgraded".

Check needed space:

sudo apt -o APT::Get::Trivial-Only=true full-upgrade

I got: "After this operation, 1,468 MB of additional disk space will be used."

If you've got a gnarly system, consider doing the upgrade in CLI to keep graphics issues out of the picture.
Reboot and choose the "TTY login" option before continuing.

Do a minimal upgrade of the system first:
" By doing the upgrade in two steps, we ease the job of the package management tools
and often ensure that we have the latest versions of those, which might have accumulated bugfixes and improvements required to complete the full distribution upgrade."

sudo apt upgrade --without-new-pkgs

Even the "minimal" upgrade will probably be big enough, but when that's over,

Reboot
(Tested this yesterday - it's probably a good idea to reboot here so the new kernel gets loaded, for example.)

Then do

sudo apt full-upgrade

which is big too!

You'll see the dpkg Ominous Warning

and

"Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry."
https://forums.bunsenlabs.org/viewtopic.php?id=8418

After all those new packages have been installed you can reclaim some disk space by running:

sudo apt autoremove

to get rid of the packages which are no longer needed.

Check for possible post-install issues:
https://www.debian.org/releases/bookwor … ml#trouble

---------------------------------------------------------
If you've got apt-listchanges installed (it comes with the "standard system utilities" on offer when you do a netinstall) you'll get a lot of helpful messages about package upgrades that come in. Most of them are probably safe to ignore, but I copied out a few:

adduser (3.123) unstable; urgency=medium

The default for DIR_MODE has been set to 0700 for this release, again,
after adduser 3.122 had DIR_MODE set to 2700. Previous versions of
adduser defaulted to 0700 for the majority of this century. The default
for SYS_DIR_MODE is still 0755.

Note that the default for DIR_MODE is a change from historical defaults,
which were more permissive for normal user home directories.
Adjustments may need to be made for setups like public_html
web content, or in-homedir mail configurations.

System Administrators wanting a different default can set DIR_MODE
in /etc/adduser.conf to their desired value after installation.
The one user created during system installation needs to have the
home directory mode bits adjusted to the preferred value after
installation of the system since there is no possibility to have this
directly set in the Installer.

See /usr/share/doc/adduser/README.Debian for detailed reasoning.

systemd (251.3-2) unstable; urgency=medium

systemd-resolved has been split into a separate package.
This new systemd-resolved package will not be installed automatically on
upgrades. If you are using systemd-resolved, please install this new
package manually.

anacron (2.3-36) unstable; urgency=medium

If you run Debian testing/unstable and ever installed anacron 2.3-33 on
a systemd based system, then anacron will no longer be enabled and the
daily/weekly/monthly cron jobs will not be run until it is.

Since not all cron jobs have migrated to systemd timers, Debian
testing/unstable systems with systemd and anacron may be missing
some essential cron jobs, such as making backups of aptitude state.

To see if a system is affected you can use these commands:

zgrep -i anacron.*2.3-33 /var/log/apt/history.log*
systemctl status anacron.service anacron.timer

To re-enable anacron you can use these commands:

sudo systemctl enable anacron.service anacron.timer
sudo systemctl start anacron.service anacron.timer

openssh (1:9.0p1-1) unstable; urgency=medium

OpenSSH 9.0 includes a number of changes that may affect existing
configurations:

* This release switches scp(1) from using the legacy scp/rcp protocol to
using the SFTP protocol by default.

Legacy scp/rcp performs wildcard expansion of remote filenames (e.g.
"scp host:* .") through the remote shell. This has the side effect of
requiring double quoting of shell meta-characters in file names
included on scp(1) command-lines, otherwise they could be interpreted
as shell commands on the remote side.

This creates one area of potential incompatibility: scp(1) when using
the SFTP protocol no longer requires this finicky and brittle quoting,
and attempts to use it may cause transfers to fail. We consider the
removal of the need for double-quoting shell characters in file names
to be a benefit and do not intend to introduce bug-compatibility for
legacy scp/rcp in scp(1) when using the SFTP protocol.

Another area of potential incompatibility relates to the use of remote
paths relative to other user's home directories, for example - "scp
host:~user/file /tmp". The SFTP protocol has no native way to expand a
~user path. However, sftp-server(8) in OpenSSH 8.7 and later support a
protocol extension "expand-path@openssh.com" to support this.

In case of incompatibility, the scp(1) client may be instructed to use
the legacy scp/rcp using the -O flag.

openssh (1:8.7p1-1) unstable; urgency=medium

OpenSSH 8.7 includes a number of changes that may affect existing
configurations:

* scp(1): this release changes the behaviour of remote to remote copies
(e.g. "scp host-a:/path host-b:") to transfer through the local host by
default. This was previously available via the -3 flag. This mode
avoids the need to expose credentials on the origin hop, avoids
triplicate interpretation of filenames by the shell (by the local
system, the copy origin and the destination) and, in conjunction with
the SFTP support for scp(1) mentioned below, allows use of all
authentication methods to the remote hosts (previously, only
non-interactive methods could be used). A -R flag has been added to
select the old behaviour.

policykit-1 (121+compat0.1-2) experimental; urgency=medium

This version of polkit changes the syntax used for local policy rules:
it is now the same JavaScript-based format used by the upstream polkit
project and by other Linux distributions.

System administrators can override the default security policy by
installing local policy overrides into /etc/polkit-1/rules.d/*.rules,
which can either make the policy more restrictive or more
permissive. Some sample policy rules can be found in the
/usr/share/doc/polkitd/examples directory. Please see polkit(8) for
more details.

Some Debian packages include security policy overrides, typically to
allow members of the sudo group to carry out limited administrative
actions without re-authenticating. These packages should install their
rules as /usr/share/polkit-1/rules.d/*.rules. Typical examples can be
found in packages like flatpak, network-manager and systemd.

Older Debian releases used the "local authority" rules format from
upstream version 0.105 (.pkla files with an .desktop-like syntax,
installed into subdirectories of /etc/polkit-1/localauthority
or /var/lib/polkit-1/localauthority). The polkitd-pkla package
provides compatibility with these files: if it is installed, they
will be processed at a higher priority than most .rules files. If the
polkitd-pkla package is removed, .pkla files will no longer be used.

grep (3.8-1) unstable; urgency=low
The confusing GREP_COLOR environment variable is now obsolescent.
Instead of GREP_COLOR='xxx', use GREP_COLORS='mt=xxx'. grep now
warns if GREP_COLOR is used and is not overridden by GREP_COLORS.
Also, grep now treats GREP_COLOR like GREP_COLORS by silently
ignoring it if it attempts to inject ANSI terminal escapes.

Regular expressions with stray backslashes now cause warnings, as
their unspecified behavior can lead to unexpected results.
For example, '\a' and 'a' are not always equivalent
<https://bugs.gnu.org/39678>. Similarly, regular expressions or
subexpressions that start with a repetition operator now also cause
warnings due to their unspecified behavior; for example, *a(+b|{1}c)
now has three reasons to warn. The warnings are intended as a
transition aid; they are likely to be errors in future releases.

Regular expressions like [:space:] are now errors even if
POSIXLY_CORRECT is set, since POSIX now allows the GNU behavior.

libreoffice (1:7.4.2~rc1-1) unstable; urgency=low

* LibreOffice 7.4.0/7.4.1 contained a bug about wrongly remembering the
size of the LibreOffice windows. (Most prominently showing inside KDE).
.
This has been fixed in 7.4.2 but you experience this problem even after
a second start of the new LibreOffice you might either need to reset your
user profile or remove the affecting keys from it manuallly
(ooSetupFactoryWindowAttributes in
~/.config/libreofficei/4/user/registrymodifications.xcu)

Last edited by johnraff (2023-02-25 06:48:19)

hhh · 2023-02-14 10:42:05

^ That all looks ominous and intimidating! It's not, though... on a current Beryllium system it's still basically change sources, update sources, then...

sudo apt upgrade --without-new-pkgs

Reboot.

sudo apt full-upgrade

Reboot.

Edited my previous post, it's pkgs not packages.

sleekmason · 2023-02-14 13:55:53

^^ Thank you for putting all the upgrade info together. Good notes to have on hand.

johnraff · 2023-02-15 02:12:42

@hhh you're right - for most people those two commands will do it, what else you want to do depends on just how important it is to you that the upgrade doesn't break.

If it's a throwaway toy VM then sure just go ahead.

Beyond that, it's balancing the extra work that fixing up a broken upgrade would mean, against the extra work trying to minimize that risk. And your assessment of how high that risk is.

For now, I just wanted to pull out what looked like the most useful hints for BL users from the Debian documentation. I'll definitely do all that stuff when I upgrade my laptop - its disk is encrypted, which makes directly installing a new system to a partition more complicated. Further down the line it would be good to have a "proper" HOW-TO with sections like "If you're short of disk space" that people can ignore if they don't apply.

---
PS On thought, rebooting often straightens out messed up configs after a package upgrade but during a system upgrade I think it could be dangerous. The necessary bits might not yet all be in place, so we shouldn't necessarily be advising people to reboot at random times. I've been caught out that way in the past - the system looked fine while it was running, but failed to boot. But rebooting after the "minimal upgrade" ought to be helpful I guess...

...and will load the new kernel, since it's probably been updated. Good to have all the tools up to date before going on to the full-upgrade.

Last edited by johnraff (2024-01-25 05:33:06)

hhh · 2023-02-15 06:27:37

^ Heard that. As usual, your advice is on point.

For the record, though, my new Beryllium install upgraded, rebooted, full-upgraded to Boron and rebooted again without issues. Intel hardware for the win.

johnraff · 2023-02-16 02:22:50

Yes, and the more people who try the experimental Boron (even though the BL packages are almost unchanged at this point) the better the chance we'll have to iron out the bugs for a timely release.

dhalgren · 2023-02-17 04:13:29

Just did the two part upgrade/migration, and everything went fine but for some confusion with LaTex/texlive. (mktexlsr will not run as it is looking for updmap* in /etx/texmf, but updmap remains where it always has been on this system. However, LyX and Latex continue to run perfectly, so not a biggie, despite tex-common not installing properly. I will continue to try to sort out what is happening and if it has any effect on the use of Latex. At the moment, however, it seems that running update texmf has enabled the runing of mktexlsr.)

Everything else seems to be working as expected, but will report anything not up to spec.

Cheers, and thank you for the explicit guide to this process.

johnraff · 2023-02-17 05:41:55

^Thanks for the feedback!

Sorry I can't help you with LaTex - a quick search through my Debian mailing list archive brought up nothing useful-looking. It sounds from what you say that there's been some change in the configs during the upgrade, which the packages didn't 100% cope with. With luck the Debian developers will have it sorted out by the time of the official Bookworm release. Meanwhile you could try web searching on the error messages you get...

dhalgren · 2023-02-17 06:02:54

The error messages assure me that it is a dpkg error, and that I did not accept a config change (which was not, in fact, offered). As it is all working I am not too bothered at the moment. I assume it will be sorted before it actually becomes an issue, which it isn't at the moment.

johnraff · 2023-02-19 04:27:09

I just did the upgrade on a 2006 32 bit laptop following the hints above and it all seemed to go OK.

That laptop boots up to ~360MB RAM on Boron, out of its total of 1GB.
Seems to run pretty well, though I haven't attempted to eg use Firefox on a modern website...

Last edited by johnraff (2023-02-20 02:09:30)

dhalgren · 2023-02-25 01:41:45

Texlive update...

I do not know how many people here use TeX/LaTeX, but I thought I should report that I have now found the problem, and what the prblem was, just in case similar difficulties arise for others.

The problem was that I had manually installed Minion Pro and Myriad Pro fonts, and the upgrade did not handle these manual installations well.

The solution was to remove the file mentioning these fonts and run "update updmap", followed by "updmap".

Although it is reported that packages such as tex-common have not been configured, they have in fact been configured.

Interestingly, any attempt to reinstall them results in the following message:

E: Internal Error, No file name for tex-common:amd64

I am not quite sure what this "means", but there you go.

johnraff · 2023-02-25 01:56:59

^Thanks for the report. It's good to have this on record as an example of what can happen upgrading a system with "non-standard" stuff installed.

Glad you got it sorted, though that "Internal Error" is suspicious.

In retrospect, maybe uninstalling those manually added fonts before doing the upgrade, then putting them back afterwards, might have been the way to go? Maybe I should add a note about that to the post.

dhalgren · 2023-02-25 04:02:02

Yes, I thought the "internal error" was extremely odd, if nothing else. However, if the package is uninstalled, it installs without difficulty. This can be added to the oddity and suspicion.

As for my issues with fonts---I had forgotten that I installed them, which is a danger with additions which are not used very often, and I don't use them often enough to bother re-installing them.

But it is a warning for others in respect of forgotten manual installations of packages et cetera which are not used often.

Editing the upgrade instructions to reflect the need to check for manual installations and sort them out before upgrading may well be a very good idea.

Last edited by dhalgren (2023-02-25 04:03:39)

johnraff · 2023-02-25 06:49:59

That post above is at the moment just a rough list, but I've added a note about manually added packages. Around release time we should have a cleaned-up HOW-TO for upgrading.

johnraff · 2023-02-26 02:28:41

dhalgren wrote:

As for my issues with fonts---I had forgotten that I installed them, which is a danger with additions which are not used very often, and I don't use them often enough to bother re-installing them.

I just thought - for fonts which aren't available as packages from the regular Debian repositories, if you're going to install manually is it even necessary to install a package? Up to now, I've always just copied the font file (usually .ttf) into ~/.local/share/fonts and run 'fc-cache -f -v ~/.local/share/fonts'.

#1 2023-02-07 11:58:50

Re: Upgrading from Beryllium to experimental Boron

#2 2023-02-08 01:02:17

Re: Upgrading from Beryllium to experimental Boron

#3 2023-02-08 03:37:08

Re: Upgrading from Beryllium to experimental Boron

#4 2023-02-08 03:41:16

Re: Upgrading from Beryllium to experimental Boron

#5 2023-02-09 08:22:19