Raspberry Pi OS upgraded to Debian 11 “Bullseye”

Debian 11 “Bullseye” was released in August 2021, and I was expecting Raspberry Pi OS to soon get upgraded to the latest version, especially the last time around, in 2019, Raspian Buster was released even before the official Debian 10 “Buster” release, although the reason was Raspberry Pi 4 launch.

This time around it took longer, but the good news is that Raspberry Pi OS has just been upgraded to Debian 11, meaning it benefits from the new features such as driverless printing, in-kernel exFAT module, “yescrypt” password hashing, and packages upgraded to more recent versions.

Raspberry Pi OS Debian 11 BullsEye

The Raspberry Pi Foundation goes into more details about what changed in the new Raspberry Pi OS release with GTK+3 user interface toolkit, Mutter window manager replacing OpenBox in boards with 2GB RAM or more, new KMS video and camera drivers, and more. Raspberry Pi OS “BullsEye” can be downloaded from the usual place, and I installed it on my Raspberry Pi Zero 2 W.


The Linux kernel is 5.10.63, bumped from Linux 5.10.17 in the “Buster” image.


Some changes appear in the Graphics part, with “Buster” showing:


and BullsEye:


That should be because of the switch from the Raspberry Pi-specific video driver to a standard KMS video driver.
There was no swap in Debian 10 image, but 100MB is enabled in the Debian 11 one. I can see there’s close to 100% of it used, which may explain which the Windows felt a bit sluggish in the desktop environment. It should not be an issue with Raspberry Pi boards equipped with more memory.

I’ve also run SBC bench benchmark from an SSH terminal with the goal of double-check any potential regressions and/or improvements:


It got stuck here like forever, so I tried to access the desktop without luck, and I was unable to initiate another SSH terminal or terminate sbc-bench.sh. I power cycled the board, and tried again, and I got the exact same results.

So I would not recommend upgrading a production machine right now, or you’d better perform some testing first. Note it’s not possible to upgrade Raspberry Pi OS Buster to BullsEye from the command line just yet, and this time the only solution is to flash the image to a microSD card.

Share this:

Support CNX Software! Donate via PayPal or cryptocurrencies, become a Patron on Patreon, or buy review samples

Subscribe
Notify of
guest
The comment form collects your name, email and content to allow us keep track of the comments placed on the website. Please read and accept our website Terms and Privacy Policy to post a comment.
24 Comments
oldest
newest
David Willmore
David Willmore
24 days ago

They still don’t support upgrading systems without nuking them and reinstalling. 🙁

Mihai
24 days ago

I was actually thinking that I could just do apt dist-upgrade and get the new version. Not a problem for me, as I am only using it on my RPi Zero 2 W and I need it working right now (I also just set it up last week). I will postpone its update after I see more about the new OS version.

David Willmore
David Willmore
24 days ago

If you want to try upgrading instead of nuking, here’s their guide: forums.raspberrypi.com/viewtopic.php?t=323279

Edited: Oh, tkaiser mentioned this already.

Mihai
22 days ago

I found out that there is an article on TomsHardware that does the same thing: in place update to Debian 11 on RPi. It looks like the list of commands is a little different than the forum topic. I can live with the current installation for now, not enough time to fiddle with it, I just finished set it up.

David Willmore
David Willmore
21 days ago

Being able to retain system customizations is one of the advantages of the distros which do support in place major version upgrades. The other advantage which means more to me is to be able to upgrade a machine in place. I don’t want to go to where the machine is and swap out a uSD card. I want to log into it remotely and issue some commands.

They’re starting to stand out by not offering this ability when so many other distros do support it.

tkaiser
tkaiser
21 days ago

> I want to log into it remotely and issue some commands.

Just do it with their Debian fork or whatever userland runs on your RPi.

As long as you keep in mind that you’re always dealing with 2 OS on these things and how stuff needs to be organised on the FAT partition for ThreadX to work and for their kernel and ThreadX related (firmware) packages to flawlessly update you’re absolutely fine.

tkaiser
tkaiser
20 days ago

BTW: to have a look at Write Amplification when doing an upgrade from Buster to Bullseye I simply tried it. Not with Raspbian but with Armbian and OS on a SATA SSD to query Total_LBAs_Written SMART attribute before and after. This resulted on ext4 in ~2140 MB written at the flash layer and with btrfs (with compress-lzo) even in ~13150 MB. Package count: 476 before and 506 after. 408 upgraded, 66 newly installed, 6 to remove and 0 not upgraded. Need to get 222 MB of archives. After this operation, 180 MB of additional disk space will be used. 123… Read more »

tkaiser
tkaiser
20 days ago

According to tune2fs the rootfs shows: ‘Lifetime writes: 2554 MB’. This includes transferring the rootfs from SD card (~1.2GB), a small update of 34 packages in Buster and then the distro upgrade to Bullseye. So with this Samsung SSD controller we’re talking about Write Amplification of ~2. At this point I realised that I only wasted my time with this experiment since the flash translation layer in an el cheapo SD card is most probably way more primitive and Write Amplification there with the same task could be easily 10 times higher. The problem is still: such a fat OS… Read more »

David Willmore
David Willmore
20 days ago

You make a good point. But your basic premise was that Raspbian was intentionally designed to be upgraded as an image instead of on a per-package bases because the Foundation was concerned with flash life. You’ve proven that part, but what contradicts that is their failure to tune it to decrease all of the small incidental writes that OSs generate as they go about their business. I would assert that’s the primary mechanism that Raspbian wears out cheap uSD cards. Additionally, I’m curious how much WA you get from even an image write of a cheap uSD card. Since they… Read more »

tkaiser
tkaiser
20 days ago

> your basic premise was that Raspbian was intentionally designed

Nope, Raspbian is a mess when it comes to SD cards. No log2ram but swap on SD card and default ext4 commit interval will result in SD cards wearing out way faster than necessary.

Just wanted to hint that you can do a distro upgrade on Raspberries (regardless of the userland) and that the very same process is bad for SD cards with such a fat OS like Debian or Ubuntu which involves way too much fs activity when upgrading.

tkaiser
tkaiser
20 days ago

> I know there are some SD utilities (at least under windows) which allow you to do sort of a secure erase

It’s block erase and the SD Card Formatter tool can do this on macOS or Windows. For SBC != Raspberries that’s the only useful task this tool does (on Raspberries using NOOBS it helps reformatting larger SD cards from ExFAT to FAT since ‘good old’ VideoCore can’t deal with anything newer)

David Willmore
David Willmore
20 days ago

I replied to the wrong post before, sorry. There is a command called blkdiscard. I tried it on a card and… Simple/dumb test. I ran blkdiscard on a Samsung Pro+ 32GB uSD card. It took a few seconds. I then performed the following full drive ‘dd’ operations: Read: 50.6MB/s Write: 84.8MB/s Read: 92.4MB/s Write: 84.8MB/s Read: 92.3MB/s That seems pretty consistent and shows us that the command does do *something*. It did erase the card as I verified with a separate operation. I wanted to do a rewrite of the whole card to see if the overwrite would be as… Read more »

David Willmore
David Willmore
19 days ago

Tried another card. This one is an Adata Premier uSD 32GB 100MB/s (AUSDH32GUICL10A1-RA1). They were supposedly identical to many other cards I purchased of the same type, but they had a slightly different capacity and my initial simple read speed tests showed poor performance. I suspected that they had changed vendors or something as the writing on the back of the card was different, but it was still MIK like I’d prefer. With the results of the previos test in mind I picked one of them for this testing because *I had a hunch*.Okay, tests:read: 30.4 MB/s write: 94.5 MB/s… Read more »

tkaiser
tkaiser
18 days ago

I documented what to do when running Raspberry Pi OS and trying to extend the SD card’s lifespan: https://github.com/ThomasKaiser/Knowledge/blob/master/articles/Quick_Review_of_RPi_Zero_2_W.md#sd-card-endurance

tkaiser
tkaiser
24 days ago

Upgrading their Debian flavour is possible and it works the usual way. But they know their customers well enough to realize that vast majority of them are overwhelmed by a 10 step copy&paste shell commands sequence and as such they officially state ‘not possible’.

Better think about who the users are: if you run Linux on a PC you’re most probably a Linux expert able to deal with minor or even major Linux issues (and there are tons of them). If you run a Desktop Linux on an RPi most probably you were just after cheap hardware?

tkaiser
tkaiser
24 days ago

And then there’s the ‘crappy storage’ dilemma as well: while in 2021 some SBC users might have heard of random IO vs. sequential IO and know they should look for A1 rated quality SD cards… majority still has no clue.

Writing a new OS image to an SD card is only sequential IO with Write Amplification close to 1. Doing a distro upgrade on an SD card is pure random IO with Write Amplification magnitudes higher. On slow/crappy SD cards this process can take ages and there’s a good chance the card will die of this.

David Willmore
David Willmore
20 days ago

It looks like there’s a linux tool called blkdiscard. I’m trying it on a card now.

David Willmore
David Willmore
20 days ago

x

wboz88
wboz88
24 days ago

So interesting. Am very interested in reading the News post in detail. I only glance at it now. I never use a LXDE without Openbox before …

I had long been thinking the stop* in LXDE development would be a challenge for rPi. Anything with only 512MB memory needs ideally <100MB used once you get to desktop. So is this the start of a “forced fork” of the DE by rPi developers? (It is a lot of work …)

*Not total stop. Github still active…

tkaiser
tkaiser
24 days ago

> kernel is 5.10.63, bumped from Linux 5.10.17

If you recently did an ‘apt upgrade’ on Buster you were on 5.10.63 too. The Bullseye image shares also same ThreadX version and (Integer) performance is more or less the same: ix.io/3EgS vs. ix.io/3EpV

One difference is shipped GCC version (and I would assume packages were all built with same version): 8.3 vs. 10.2.

tkaiser
tkaiser
24 days ago

> I was unable to initiate another SSH terminal or terminate sbc-bench.sh

Your board locked up while compiling cpuminer most probably due to underpowering (overheating is close to impossible). On my Zero 2 W same performance numbers as with former Buster installation: ix.io/3Eq3

BTW: cpuminer doesn’t build with armhf userland anyway 🙂

tkaiser
tkaiser
22 days ago

It seems running the Bullseye image significantly increases temperatures and consumption, especially when overclocking/overvolting is at play: https://github.com/ThomasKaiser/Knowledge/blob/master/articles/Quick_Review_of_RPi_Zero_2_W.md#performance-and-consumption

StephanStS
3 days ago

There is an upgrade description which deals with Buster -> Bullseye ans has some more additional changes for the transition:
https://dietpi.com/blog/?p=811
Although it has some specialities for DietPi (a Debian based lightweight distribution) it may give some hints where to look at other distributions when upgrading.

tkaiser
tkaiser
3 days ago

Where does this obsession for net.ifnames=0 comes from?

Advertisement