Raspberry OS / Raspbian updated to Debian 11 "Bullseye"

[obj]

@keithma

I’m pretty sure that one or two of my Pis are on Jessie and some others still running Stretch. If they work, and they’re not external facing, I see no reason to change them.

I appreciate the “if it’s not broke…” logic but we do not plan to build new packages for jessie forever (PiAware 6 might be the last ones) so you’ll be on an old version.

(Plus, if it’s on the network – even if not directly exposed to the world – you really do want security updates, and they’re no longer available for jessie)

[abcd567]

My Pis as of today:

(1) RPi Model 4 - Piaware SD card image Buster 6.1

 

(2) OrangePiPC - Armbian Bullseye with piaware 6.1, dump1090-fa 6.1, dump978-fa 6.1

 

(3) RPi model4 - DietPi Bullseye 64-bit with piaware 6.1, dump1090-fa 6.1, and dump978-fa 6.1

 

(4) RPi model 4 - Raspberry Pi OS Bullseye with piaware 6.1, dump1090-fa 6.1, and dump978-fa 6.1

 

[abcd567]

I have stopped disturbing commissioned/running install for upgrade. Now I have started using a spare microSD Card and a spare Pi.

I write latest image to spare microSD card, slip it into spare Pi, install and configure feeders, graphs and any other required software, let it run for a while, and if all is ok, replace old card of main Pi with freshly prepared spare microSD card.

This is a very safe way to upgrade.

 

 

[keithma]

@obj

I appreciate the “if it’s not broke…” logic but we do not plan to build new packages for jessie forever (PiAware 6 might be the last ones) so you’ll be on an old version.

I wasn’t specifically referring to Pis running ADS-B, they are definitely external facing. A couple that spring to mind are ones that run little Christmas trees with flashing LEDs

[foxhunter]

@keithma

little Christmas trees with flashing LEDs

We will see this on your installation?
Hopefully it will not impact LHR traffic because of confused pilots

[keithma]

@foxhunter

We will see this on your installation?

I’ve got two of them, one gets set up in my office and the other one is in the front room

Sparkly RPi Christmas tree

@foxhunter

because of confused pilots

[abcd567]

Piaware SD Card image ver 6.1 - Upgraded from Buster to Bullseye

https://flightaware.com/adsb/stats/user/abcd567#stats-5252

This was just an experiment. It has no advantage as Buster is still supported. Although after running for 18 hrs, I did not notice any issues, but there are no warranties, and if you want to try it, do it on your own risk.

(1) Edited file /etc/apt/sources.list

1.1 - Added following line to add raspberrypi’s Bullseye repo:
deb http://raspbian.raspberrypi.org/raspbian/ bullseye main contrib non-free rpi

1.2 - Commented out following line to comment out Flightaware’s Buster repo:
#deb http://flightaware.com/mirror/raspbian/raspbian/ buster main contrib non-free rpi

(Please see screenshot below).

 

(2) Updated & upgraded
sudo apt-get update
sudo apt-get full-upgrade

Upgrade command took about 40 minutes to complete. After comletion, rebooted Pi. The OS is upgraded to Bullseye. Please see screenshot below.

 

[foxhunter]

I sucessfully ran an upgrade of my Raspberry 3B by changing the sources list from buster to bullseye, followed by apt update and apt upgrade

On that device the additional feeders for Radarbox and Planefinder are running, data is coming from readsb installed on the same Pi3 which catches the stream from my Jetvision device

In addition the WeeWX weather station is running on it.

All went fine, still working after reboot.
I only needed to manually start the weewx service it was flagged as “dead”.

As neither dump1090 nor piaware is running on it (this is going to FA directly from the Jetvision device) i cannot answer if this would work as well.

Update was done in approx 15-20 Minutes (did not check stop watch)

[foxhunter]

The Raspberry Imager with the (hidden) option to set the parameters for WiFi, hostname etc which can be opened by STRG-SHIFT-X seem to have an issue with the new image, even if it can be selected for installation.

After writing the image to the device, it shows an error that config.txt does not exist.
But it’s there.

Overclocking seem to be working. I used one of my spare Pi4 with 2Gig and the flag in config.txt

System:    Host: Raspi4 Kernel: 5.10.63-v7l+ armv7l bits: 32 compiler: gcc v: 10.2.1 Console: tty 0 
           Distro: Raspbian GNU/Linux 11 (bullseye) 
Machine:   Type: ARM Device System: Raspberry Pi 4 Model B Rev 1.2 details: BCM2711 rev: b03112 
           serial:  
Memory:    RAM: total: 1.9 GiB used: 217 MiB (11.1%) gpu: 76 MiB 
           RAM Report: unknown-error: Unknown dmidecode error. Unable to generate data. 
CPU:       Info: Quad Core model: ARMv7 v7l variant: cortex-a72 bits: 32 type: MCP arch: v7l rev: 3 
           bogomips: 1296 
           Speed: 1800 MHz min/max: 600/1800 MHz Core speeds (MHz): 1: 1800 2: 1800 3: 1800 4: 1800 
           Features: crc32 edsp evtstrm fastmult half idiva idivt lpae neon thumb tls vfp vfpd32 vfpv3 vfpv4

Haven’t tried it before and if it was already working on Buster. Stability needs check.

[abcd567]

@foxhunter

followed by apt update and apt upgrade

Which one of following upgrade commands you used?:

apt upgrade
apt dist-upgrade
apt full-upgrade

I am not sure what is the difference between the above 3 commands. May be some one who knows, or @obj kindly take the trouble to explain.

 

[foxhunter]

If you switch from buster to bullseye in the sources.list, the first command is obviously sufficient, that’s what i was using.

The main difference is the automatic resolution of dependency issues from what i found in other discussions.
But for me it was working flawless

I only needed to answer a couple of times if the existing config should be overwritten with a new default one.
I always selected “no” to keep my config files.

That can be a problem if the config structure changes, but it was not the case during my install/upgrade

https://askubuntu.com/questions/194651/why-use-apt-get-upgrade-instead-of-apt-get-dist-upgrade

[foxhunter]

quick correction after checking my history on the 3B. I needed to use a --fix-missing in between and utilized the update/upgrade again. But i did neither use dist nor full

  439  sudo nano sources.list
  440  sudo apt update
  441  sudo apt upgrade
  442  sudo apt --fix-missing
  443  sudo apt update
  444  sudo apt upgrade
  445  sudo reboot now

[abcd567]

@foxhunter

I only needed to answer a couple of times if the existing config should be overwritten with a new default one.
I always selected “no” to keep my config files.

 

Yes, this happened with me also. Please see below:

@abcd567

(4) Updated:
sudo apt update

(5) Upgraded:
sudo apt dist-upgrade

Above command resulted in a very lengthy upgrade process (about 45 minutes). Had to be patient.
In between upgrade process:

• It gave some info about apt, and stopped with a line having only colon ( : ).
  Exited this by pressing q key.
• It asked if you want to stop services without asking with No button highlighted red. Changed to Yes highlighted red and pressed Enter to proceed.
• it asked if I want to keep existing configurations, and default is to keep (N). Typed N and pressed Enter key to accept “keep”.

[abcd567]

I Googled to find answer to my question about difference between apt upgrade, apt dist-upgrade and apt full-upgrade.

Here is what I found:

For reference:

• apt(8) — apt — Debian bookworm — Debian Manpages
• https://manpages.ubuntu.com/apt

apt upgrade will upgrade all packages that can be upgraded without the need to install additional packages or remove any conflicting installed packages. Basically it will apply all package upgrades that do not include changed dependencies.

apt full-upgrade (the correct equivalent for apt-get dist-upgrade ) applies package upgrades as well if they require either the install of new packages or the removal of conflicting installed packages. Basically it will apply all package upgrades including those with changed dependencies.

On stable distro suites, when not adding new APT sources, one will face changed dependencies rarely, hence usually apt full-upgrade is not required or does not apply any additional upgrades compared to apt upgrade , except for Linux image package upgrades. Linux image packages are usually shipped as meta packages, e.g. linux-image-amd64, which then depends on the actual versioned package, e.g. linux-image-4.19.0-9-amd64. When one uses apt upgrade , the Linux image meta package will usually not be upgraded, since it would required to install a new versioned Linux image package. Running apt full-upgrade on the other hand will do the upgrade, furthermore it might remove the old versioned package, if the new one has a related conflict defined (which is usually not the case for Linux image packages, just as example!).

Due to the nature that installed packages can be removed by apt full-upgrade , it should not be called non-interactively. I personally ran into situations while testing the new Raspbian testing suite, where due to unresolved dependencies or conflicting repository updates the whole webserver stack would have been removed. I needed to wait until that repository inconsistency was resolved, before I was able to do the upgrades without causing havoc. However on stable suites I never faced such issue. I personally ran into situations while testing the new Raspbian testing suite, where due to unresolved dependencies or conflicting repository updates the whole webserver stack would have been removed. I needed to wait until that repository inconsistency was resolved, before I was able to do the upgrades without causing havoc. However on stable suites I never faced such issue.

[abcd567]

(1) One confusing thing is difference between apt-get and apt. Which one to use where?

(2) In Google search results, I found another person claims that both dist-upgrade and full-upgrade are the same thing. I quote him below.

Yes they are the same command. This part of apt’s cmdline/apt.cc source file proves it:

static std::vector<aptDispatchWithHelp> GetCommands()            /*{{{*/
{
   return {
      // [snip]
    
      // system wide stuff
      {"update", &DoUpdate, _("update list of available packages")},
      {"upgrade", &DoUpgrade, _("upgrade the system by installing/upgrading packages")},
      {"full-upgrade", &DoDistUpgrade, _("upgrade the system by removing/installing/upgrading packages")},
    
      // misc
      {"edit-sources", &EditSources, _("edit the source information file")},
      {"moo", &DoMoo, nullptr},
    
      // for compat with muscle memory
      {"dist-upgrade", &DoDistUpgrade, nullptr},
    
      // [snip]
   };
}

And for completeness, cmdline/apt-get.cc:

static std::vector<aptDispatchWithHelp> GetCommands()           /*{{{*/
{
   return {
      // [snip]
      {"dist-upgrade", &DoDistUpgrade, _("Distribution upgrade, see apt-get(8)")},
      {"full-upgrade", &DoDistUpgrade, nullptr},
      // [snip]
   };
}

For both apt and apt-get , full-upgrade and dist-upgrade both refer to the same DoDistUpgrade function and therefore do the exact same thing.

 

[jnrfalcon]

Did somebody do something to server configuration this morning? I upgraded to bullseye a couple days ago. Without updating any of adsb software, everything was working fine. But this morning both dump1090-fa and dump978-fa quit working…

[jnrfalcon]

BTW if you have Pi 3B+ and are having trouble with Wifi being blocked every time you restart after upgrading to Bullseye, do this:

apt purge connman

[obj]

@jnrfalcon

Did somebody do something to server configuration this morning? I upgraded to bullseye a couple days ago. Without updating any of adsb software, everything was working fine. But this morning both dump1090-fa and dump978-fa quit working…

Server configuration doesn’t affect your local decoders. You have a local problem.

[jnrfalcon]

Reinstalling following this guide now… It’s taking a long time for those extra packages…

[abcd567]

@jnrfalcon

Did somebody do something to server configuration this morning? I upgraded to bullseye a couple days ago. Without updating any of adsb software, everything was working fine. But this morning both dump1090-fa and dump978-fa quit working

No, all ok with my 3 bullseye Pis

 

(1) Pi #1 with Piaware SD card image Buster on RPi model 4.
I upgraded it to Bullseye by adding bullseye repo to file /etc/apt/sources.list and then sudo apt-get update followed by sudo apt-get full-upgrade . It is 2 days now and is working ok. You can check it here:
https://flightaware.com/adsb/stats/user/abcd567#stats-5252

 

(2) Pi #2 with Armbian Bullseye image on OrangePiPC.
The image was originally Bullseye, and no upgraging done by me. Working ok since one week. You can check it here:

https://flightaware.com/adsb/stats/user/abcd567#stats-6396

 

(3) Pi #3 with Raspberry Pi OS Bullseye on RPi model 4.
The image was originally Bullseye, and no upgraging done by me. Working ok since two days You can check it here:

https://flightaware.com/adsb/stats/user/abcd567#stats-76000