Raspberry Pi OS upgraded to Debian 11 “Bullseye”

35 Replies to “Raspberry Pi OS upgraded to Debian 11 “Bullseye””

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

   Reply

   1. 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.

      Reply

      1. 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.

         Reply

         1. 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.

            Reply

            1. 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.

            2. > 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.

            3. 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.

               1 2 3

               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.

               A Raspbian minimal image ships with ~100 packages more.

            4. 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 like Debian which ends up writing +1000 MB at the filesystem layer is not made for in-place version upgrades on crappy flash storage like SD cards.

            5. 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 lack TRIM, there’s no way to tell them to consider themselves blank before writing a new image. So, each sector written will still cause a reallocation, no? I know there are some SD utilities (at least under windows) which allow you to do sort of a secure erase, but I don’t assume that everyone does that every time they upgrade a system.

               Thank you for doing all of the testing that you have done. I appreciate the effort you’ve put into this.

            6. > 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.

            7. > 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)

            8. 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 fast as the original write of the ‘blanked’ card. The write speeds were near identical. One took 377.495 seconds and the other 377.631. I also did a second read of the blanked card and saw the same read speed, so reading the blanked card didn’t make the card do anything visible.

               This tells us nothing about write amplification, though. I was hoping for a different rewrite speed since one of the writes had to perform an erase on blocks as it wrote and the other didn’t. Possibly the firmware is smart enough to erase one block when programming another so it can hide the erase cost. It’s a Samsung high end card, so that’s not imossible. I’ll try some other brands of cards.

            9. 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: 95.3 MB/s ******
               Now I blkdiscard it.
               read: 94.8 MB/s
               write: 30.5 MB/s
               read: 95.0 MB/s
               write: 30.4 MB/s
               read: 95.0 MB/s

               So this one behaved differently than the Samsung. The card when *new* appeared to behave like the blkdiscarded Samsung card. We see the read speed improved greatly after it had been fully written. But, the blkdiscard didn’t seem to cause the read speed to regress. I did verify the blkdiscard erases the Adata, but it does not cause the initial read speed to depress like the Samsung does.

               I guess Adata’s blkdiscard doesn’t put the card into the same kind of state that it does for Samsung.

            10. 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

   2. 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?

      Reply

   3. 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.

      Reply

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

         Reply

         1. x

            Reply

2. 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…

   Reply

3. > 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.

   Reply

4. > 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 🙂

   Reply

5. 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

   Reply

6. 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.

   Reply

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

      Reply

      1. Mostly because our scripts currently count on the legacy interface names and because as far as I could see, the simple identifying names “eth” and “wlan” are still preferred by most users compared to the more cryptic predictable enpNsM/”wlpNsM styled ones. I haven’t heard of any DietPi system where the network interfaces really got random different classic indices on every boot, hence the reason for “predictable” interface names seems to be a rare case, probably large network switch or server racks, not sure.

         One of the next releases will have the network config script reworked, which will then support predictable interface names as well. But this doesn’t necessarily mean that we ship them as default.

         Reply

         1. > simple identifying names “eth” and “wlan” are still preferred by most users

            IMO a system where end users have to deal with the device names of network interfaces is somewhat broken or at least not ‘user friendly’ at all 🙂

            Asides that problems already appear with USB Ethernet adapters and not just ‘large network switch or server racks’. At least as long as managing the network with anachronisms…

            Reply

            1. You don’t need to deal with interface names, at least not when setting up a common Internet network connection via WiFi or Ethernet, or a WiFi access point with shared Ethernet Internet connection. But like on any other non-GUI Linux distribution, for a more complex network setup, you need to create/edit some own configs, and then of course one needs to deal with those. We plan to extend the abilities of our network setup script, as mentioned, but until then for other than mentioned cases, /etc/network/interfaces.d can be used for custom ifupdown configs, or any other network stack or GUI tool of choice, Webmin or whatsever can be installed and used. We cannot and do not aim to provide everything in every use case with our scripts, which isn’t possible anyway, but they offer the selected set of features which we were able to implement until now. I know you are working for another project with some overlap, so you know what I am talking about :).

            2. > IMO a system where end users have to deal with the device names of network interfaces is somewhat broken or at least not ‘user friendly’ at all

               For me it’s the opposite. My activities consists in using network interfaces all the time. “ip” and “ethotool” are commands I can use a hundred times a day. The newer atrocious names are totally unusable and make me set the wrong interface very frequently. It’s very easy to remember “eth12”, but “en63s2p6f0y7” is not an interface name but a password. I was actually very happy when I found this setting that I could add to the boot loader of machines suffering from this stuff.

               In addition, for production servers, the cryptic names even prevent one from writing portable configurations. Having a network application bind to eth0 is easy. Having it bind to en63s2p6f0y7 on one machine and en36s1 on another one is a big problem. Usually admins face this when they buy new servers with a slightly different motherboard where the name doesn’t match anymore.

               I can’t even imagine how the absurd names are called “predictable”, because for me the only predictable ones are the sequential ones. The other ones force you to type “ip -br a” first to get a listing of your interface names to know what to work with. That’s a real pain in network environments!

            3. I don’t think you qualify for an ‘end user’ role 😉

               And even for your type of work (administrator, system integrator?) at least I would prefer to have predictable names where after HW changes device names disappear and new ones appear compared to a ‘silent renaming’ of this eth stuff.

               Sounds like fun when after some minor HW changes the NICs come up in different order and now firewall rules for one segment are applied to another and vice versa since the same eth names now are associated with other NICs 🙂

            4. > I don’t think you qualify for an ‘end user’ role
               Well, I have yet to meet a single person who finds them useful to anything. For pure end-users, this brings nothing at all, and for admins it’s a nightmare.

               > at least I would prefer to have predictable names

               Please, these are *not* “predictable”. “predictable” means “someone remote can guess the name prior to connecting to the machine”. “eth0” is predictable. These are “stable names” at best.

               > where after HW changes device names disappear and new ones appear compared to a ‘silent renaming’ of this eth stuff

               That’s not that often true, because by the time a NIC dies and you have to replace it, you get a slightly different model that gets completely different names. With regular names, if you replace a single-port NIC with a dual-port one (classical case with 10G NICs for example), and the old one was called “eth1”, you can be sure that one port will be “eth1” and the other port “eth2”. With the funny naming the ports will completely change with an “f0” or “f1” being appended as the NIC exposes two functions.

               This mechanism was built by people who anticipated a problem they have never faced themselves and they tried to address it in a way that absolutely does not match reality in field, and in practice requires to modify configs everywhere on the FS or even on centralized repos to accommodate for an almost transparent change.

               And I’ve had the problem you mention happen with firewalls in the past. But it was extremely rare. Nowadays it’s systematical 🙁

               Also it’s fun to see that someone who just moves a NIC by one slot to arrange cables at the back gets a different config afterwards 🙁

            5. > For pure end-users, this brings nothing at all

               My point above was that end users should never need to know NIC device names anyway (something that can be achieved by using network-manager on Linux for example).

               > by the time a NIC dies and you have to replace it, you get a slightly different model that gets completely different names.

               As long as you put the new one in the same PCIe slot why should the name change?

               > one port will be “eth1” and the other port “eth2”

               Yeah, and the former eth2 now being eth3 or something else since order of brought up interfaces changes due to different drivers now…

            6. > As long as you put the new one in the same PCIe slot why should the name change?

               Just because the new one comes with a slightly different chip providing two functions instead of one, or because the new one is located behind a transparent PCIe bridge that eases production of NIC variants. The flawed assumption behind this concept is that you will replace one NIC with *exactly* the same one. But that’s not the reality in field. NICs rarely die, but they have to be upgraded for driver reasons, to get better optims, or higher bandwidth (e.g. upgrade 10G to 25G). And now the name even depends on the driver :-/

               > > one port will be “eth1” and the other port “eth2”
               > Yeah, and the former eth2 now being eth3 or something else since order of brought up interfaces changes due to different drivers now…

               Sure but at least you can anticipate what changes and how to reorder your ports because they all continue to exist. Many times I’ve unplugged and replugged ports in firewalls or load balancers without trouble. With the new scheme you have to revisit your config and run sed on them… or get into trouble when the config is centralized and the names change depending on the machines. So you quickly end up fixing the trouble with the boot option!

            7. We’re really getting off-topic here especially below a blog post dealing with an OS for an SBC where the old naming scheme definitely doesn’t work at all (think of multiple USB Ethernet or wireless dongles).

               Anyway: the ‘boot option’ is not a fix but a fight against a more modern and flexible system. If now something called udev tries to create predictable interface names and your ‘style’ of configuration depends on the old naming scheme… this is just asking for troubles.

               If you want those names to be really predictable in a way you control it’s always up to you to define the relevant rules (e.g. based on MAC addresses) and drop them into /etc/udev/rules.d/ on the target machine.

               If you don’t know the new NIC’s MAC addresses yet or want to know the other criteria available to base rules on then it’s time to run udevadm info -a -p /sys/class/net/enX (maybe in another PC prior to final deployment of the card)

            8. > If you want those names to be really predictable in a way you control it’s always up to you to define the relevant rules

               Yes, as usual with so called “modern” distros, it’s up to the users to write configs to undo the stuff that gets in their way and that breaks by default simple things that normally work out of the box 🙁

               But I agree we’re getting off-topic. It’s just that you were the one asking where this “obsession” comes from and I gave you my point of view based on my painful experience of this misfeature.

            9. I was asking a guy working on a distro targeted at end users why they continue to still use a broken scheme (just try it out: use 2 USB Ethernet dongles, boot, check names, shutdown, change USB ports, boot again et voilà).

               The answer: outdated scripts that fail to cope with OS reality and user expectations. The latter I do understand since the searchable web is a huge pile of crap full of outdated stuff that gets copy&pasted over and over again by another blog post, gist or whatever. Linux users are trained to look at ethX and wlanX and as such they create support efforts if you switch to something else.

               For your use case the amount of time this useless discussion takes is probably higher than accepting reality and simply switching from ‘random names that most of the times work as expected’ (net.ifnames=0) to really predictable names by simply using MAC addresses.

Leave a Reply

Connect with:

Your email address will not be published. Required fields are marked *

Comment *

Name *

Email *

Website