New Raspberry Pi OS installations no longer create the "pi" user account


David Ranch
 


Hey Everyone,

I saw this today and thought it would be good to send this email out.  It seems that the Raspberry Pi Foundation has changed their published Bullseye image to NO LONGER create the "pi" user account.  I personally think this is a good thing and my published documentation has always recommended to either disable or outright delete that well known account. 

   https://www.raspberrypi.com/news/raspberry-pi-bullseye-update-april-2022/


I imagine this will have a big impact on various different pre-built or automated-built amateur radio images using the Raspberry Pi.

--David
KI6ZHD


 

So how do you get into the raspberry pie, or do you have to specify the account it will build from the imager?

Tadd --- Sent from Planet X

On Apr 8, 2022, at 11:36 AM, David Ranch <rpi4hamradio-groupsio@...> wrote:


Hey Everyone,

I saw this today and thought it would be good to send this email out.  It seems that the Raspberry Pi Foundation has changed their published Bullseye image to NO LONGER create the "pi" user account.  I personally think this is a good thing and my published documentation has always recommended to either disable or outright delete that well known account. 

   https://www.raspberrypi.com/news/raspberry-pi-bullseye-update-april-2022/


I imagine this will have a big impact on various different pre-built or automated-built amateur radio images using the Raspberry Pi.

--David
KI6ZHD


David Lane
 

According to the post, yes, you will either create the user on first boot or if you run headless you will need to use the Pi imager to embed the UID/Password.

It does not mention how you would do it with 3rd party imagers. 

David
--
David A. Lane, KG4GIY
EC/RO Prince William County ARES®/RACES
+1.703.628.3868
http://www.pwcares.org/
IM/Skype: kg4giy




On Apr 8, 2022, at 11:38 AM, Tadd KA2DEW in NC via groups.io <tadd@...> wrote:

So how do you get into the raspberry pie, or do you have to specify the account it will build from the imager?

Tadd --- Sent from Planet X

On Apr 8, 2022, at 11:36 AM, David Ranch <rpi4hamradio-groupsio@...> wrote:


Hey Everyone,

I saw this today and thought it would be good to send this email out.  It seems that the Raspberry Pi Foundation has changed their published Bullseye image to NO LONGER create the "pi" user account.  I personally think this is a good thing and my published documentation has always recommended to either disable or outright delete that well known account. 

   https://www.raspberrypi.com/news/raspberry-pi-bullseye-update-april-2022/


I imagine this will have a big impact on various different pre-built or automated-built amateur radio images using the Raspberry Pi.

--David
KI6ZHD


 

I welcome this change.  I am glad they have made provisions for those of us who either run headless or without a window manager.

As stated, having a known user 'pi' is not a great risk, but in so doing it has had a well known password, which is a major security risk, especially when many newer users leave the default.

--
John D. Hays
Kingston, WA
K7VE / WRJT-215

 


N5XMT
 

It's unfortunate in some ways though, as there is a lot of pre-built software out there that requires the account to be "pi" as it's hard coded into it.

On Apr 8, 2022, at 08:36, David Ranch <rpi4hamradio-groupsio@...> wrote:

Hey Everyone,

I saw this today and thought it would be good to send this email out.  It seems that the Raspberry Pi Foundation has changed their published Bullseye image to NO LONGER create the "pi" user account.  I personally think this is a good thing and my published documentation has always recommended to either disable or outright delete that well known account. 

   https://www.raspberrypi.com/news/raspberry-pi-bullseye-update-april-2022/


I imagine this will have a big impact on various different pre-built or automated-built amateur radio images using the Raspberry Pi.

--David
KI6ZHD


 

You specify a user name and password at install time.

On 08/04/2022 11:38 Tadd KA2DEW in NC via groups.io <tadd@...> wrote:


So how do you get into the raspberry pie, or do you have to specify the account it will build from the imager?

Tadd --- Sent from Planet X

On Apr 8, 2022, at 11:36 AM, David Ranch <rpi4hamradio-groupsio@...> wrote:


Hey Everyone,

I saw this today and thought it would be good to send this email out.  It seems that the Raspberry Pi Foundation has changed their published Bullseye image to NO LONGER create the "pi" user account.  I personally think this is a good thing and my published documentation has always recommended to either disable or outright delete that well known account. 

   https://www.raspberrypi.com/news/raspberry-pi-bullseye-update-april-2022/


I imagine this will have a big impact on various different pre-built or automated-built amateur radio images using the Raspberry Pi.

--David
KI6ZHD

Nigel A. Gunn, ///shoulders.outwards.resolutions   tel +1-937-971-0366
Amateur Radio G8IFF W8IFF and GMRS WRBV701, e-mail nigel@... www http://www.ngunn.net


 

You can always create a 'pi' user.  Linux is multi-user.

--
John D. Hays
Kingston, WA
K7VE / WRJT-215

 


Teton Amateur Radio Repeater Association (TARRA)
 

You need to have both a username and a password to log in. When the username remains the same then half of the login information is already there so there is less to have to figure out for someone else to log in, only need the password. If the user name remained the same and can't be changed, then why even have one?

Mick - W7CAT

----- Original Message -----
From: "John Hays - K7VE / WRJT-215"
To: RaspberryPi-4-HamRadio@groups.io
Sent: Friday, April 08, 2022 09:55:45 AM
Subject: Re: [RaspberryPi-4-HamRadio] New Raspberry Pi OS installations no longer create the "pi" user account

> I welcome this change. I am glad they have made provisions for those of us
> who either run headless or without a window manager.
>
> As stated, having a known user 'pi' is not a great risk, but in so doing it
> has had a well known password, which is a major security risk, especially
> when many newer users leave the default.
>
> --
> John D. Hays
> Kingston, WA
> K7VE / WRJT-215
>
>
>
>
>
>
--


Larry Dighera
 

Hello David,

Thank you for the timely news.

I know you to be a *nix-savvy operator, and value your opinions. So, I'm
wondering your opinion on this technique for upgrading the OS from Buster to
Bullseye by simply editing /etc/apt/sources.list, and changing all instances
of buster to bullseye (after first creating an SD-card image with dd, of
course)?

Are you aware of any alternative techniques of upgrading the OS without
loosing all the custom files and configurations that have been created over
time? I'm thinking that after burning a new Bullseye image on a new
SD-card, perhaps rsync might be coaxed into restoring all the former Buster
customizations and personal files.

Best regards,
Larry
WB6BBB



On Fri, 8 Apr 2022 08:36:30 -0700, "David Ranch"
<rpi4hamradio-groupsio@...> wrote:


It seems that the Raspberry Pi Foundation has changed their published
Bullseye image to NO LONGER create the "pi" user account. I personally
think this is a good thing and my published documentation has always
recommended to either disable or outright delete that well known account.

https://www.raspberrypi.com/news/raspberry-pi-bullseye-update-april-2022/


Daniel Holmes
 

I followed the instructions in this forum post: https://forums.raspberrypi.com/viewtopic.php?t=323279

It worked, I had some resolution issues that were tough to track down (I run a pi4 headless, VNC was quite argumentative with me, as there were multiple locations of config files that had been left behind via multiple VNC servers.)

Next is to upgrade to 64 bit, but I think that one I’m going to do fresh. I have a lot of software that I run on this 4, so that project is a ways off. 

Thanks,
Dan

--
. Please pardon any mispelings or errors.


On Apr 10, 2022, at 10:39 AM, Larry Dighera <LDighera@...> wrote:


Hello David,

Thank you for the timely news.

I know you to be a *nix-savvy operator, and value your opinions.  So, I'm
wondering your opinion on this technique for upgrading the OS from Buster to
Bullseye by simply editing /etc/apt/sources.list, and changing all instances
of buster to bullseye (after first creating an SD-card image with dd, of
course)?  

Are you aware of any alternative techniques of upgrading the OS without
loosing all the custom files and configurations that have been created over
time?  I'm thinking that after burning a new Bullseye image on a new
SD-card,  perhaps rsync might be coaxed into restoring all the former Buster
customizations and personal files.

Best regards,
Larry
WB6BBB



On Fri, 8 Apr 2022 08:36:30 -0700, "David Ranch"
<rpi4hamradio-groupsio@...> wrote:


It seems that the Raspberry Pi Foundation has changed their published
Bullseye image to NO LONGER create the "pi" user account.  I personally
think this is a good thing and my published documentation has always
recommended to either disable or outright delete that well known account.

https://www.raspberrypi.com/news/raspberry-pi-bullseye-update-april-2022/







David Ranch
 


Hello Larry,

So, I'm
wondering your opinion on this technique for upgrading the OS from Buster to
Bullseye by simply editing /etc/apt/sources.list, and changing all instances
of buster to bullseye (after first creating an SD-card image with dd, of
course)?  

Generally speaking, I never recommend inline OS upgrades it for a few major reasons (highest to lowest) though I know it's a pain to start from scratch:

   1. configuration settings change over time and settings that were being deprecated in Buster might be now FULLY deprecated in Bullseye.  The result here is things just won't work and that's frustrating

   2. As you've been using your computer over time, you naturally install, try, and abandon software.  All that brings in a lot of storage bloat, complicated dependencies, etc.  I feels it's always good to start with the clean slate.

   3. default configuration settings come in with a new OS yet you won't get them as you already have an existing configuration with possibly OLD settings

   4. Some things just outright change in newer distros but you won't learn about these changes unless you re-install and spot the differences.  It's really the only REAL way to learn IMHO

   5. Debian does try to support OS upgrades but they caveat the whole process in a LOT of places.  Check out the official Buster to Bullseye process here:

       https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.html

     As you can see, there are roughly 25 steps you have to go through and there aren't any guarantees it will work.


Btw, there are some distros that try to close those gaps by supporting a "rolling release".  Some of these distros include Arch, Debian "testing", Solus, Void, etc.   When changes come in with a rolling release distro, they show you diffs of the new config file settings are vs. what you have.  This can be helpful and informative but it's a LOT of constant work to keep up, research any conflicting settings, etc.  These distros require work to be done almost every time you just try to patch your machine.  On the pro side, your OS now never gets old but on the con side, you're constantly upgrading, disrupting, and possibly bringing in breakage.

It's really a deep personal preference if you want to be on very bleeding edge, trailing bleeding edge, rapidly aged out distros like non-LTS Ubuntu , Fedora, etc or go for very long lived LTS releases like Debian stable, Ubuntu LTS, RHEL/Rocky/ALMA, etc.  I'm personally an LTS person as I don't need bleeding edge nor want constantly re-work my OS just because I can.


Are you aware of any alternative techniques of upgrading the OS without
loosing all the custom files and configurations that have been created over
time?  I'm thinking that after burning a new Bullseye image on a new
SD-card,  perhaps rsync might be coaxed into restoring all the former Buster
customizations and personal files.

What I generally do is create backups of my critical configuration files.  Here is an example of my backup script:

   http://www.trinityos.com/HAM/CentosDigitalModes/RPi/usr/local/sbin/backup-rpi-files.sh

I then do is:

   1. Install the new OS on a SD card (ideally, I start with new cards as they have zero to a little wear on the flash cells)

   2. Get the new OS running to the point I can log into it and sudo

   3. Copy over the previous backup tar.xz file and uncompress it to a staging area

   4. I go through EACH file in the restored backup stage area and use vim's "diff mode" such as "vim -d previous-backup-os-config-file new-os-config-file" and I manually update the new OS's file to have all the settings I need, research changes I don't recognize, and complete the edit. 

That all takes time but I feel it's the best compromise for myself.

--David
K6ZHD


Larry Dighera
 

David,

Thank you very much for your thoughtful and very informative response.

After giving it some thought, I don't really have the time to deal with the
potential issues that would likely result from upgrading to Bullseye. Buster
is stable, and configured the way I want it, so I'll just remain a release
behind until I'm forced to generate a new system at some point in the
future.

I am grateful for the first hand experience and knowledge you've shared.

Best regards,
Larry
WB6BBB


On Sun, 10 Apr 2022 13:54:14 -0700, "David Ranch"
<rpi4hamradio-groupsio@...> wrote:


Hello Larry,

So, I'm
wondering your opinion on this technique for upgrading the OS from Buster to
Bullseye by simply editing /etc/apt/sources.list, and changing all instances
of buster to bullseye (after first creating an SD-card image with dd, of
course)?
Generally speaking, I never recommend inline OS upgrades it for a few
major reasons (highest to lowest) though I know it's a pain to start
from scratch:

1. configuration settings change over time and settings that were
being deprecated in Buster might be now FULLY deprecated in Bullseye.
The result here is things just won't work and that's frustrating

2. As you've been using your computer over time, you naturally
install, try, and abandon software. All that brings in a lot of storage
bloat, complicated dependencies, etc. I feels it's always good to start
with the clean slate.

3. default configuration settings come in with a new OS yet you
won't get them as you already have an existing configuration with
possibly OLD settings

4. Some things just outright change in newer distros but you won't
learn about these changes unless you re-install and spot the
differences. It's really the only REAL way to learn IMHO

5. Debian does try to support OS upgrades but they caveat the whole
process in a LOT of places. Check out the official Buster to Bullseye
process here:

https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.html

As you can see, there are roughly 25 steps you have to go through
and there aren't any guarantees it will work.


Btw, there are some distros that try to close those gaps by supporting a
"rolling release". Some of these distros include Arch, Debian
"testing", Solus, Void, etc. When changes come in with a rolling
release distro, they show you diffs of the new config file settings are
vs. what you have. This can be helpful and informative but it's a LOT
of constant work to keep up, research any conflicting settings, etc.
These distros require work to be done almost every time you just try to
patch your machine. On the pro side, your OS now never gets old but on
the con side, you're constantly upgrading, disrupting, and possibly
bringing in breakage.

It's really a deep personal preference if you want to be on very
bleeding edge, trailing bleeding edge, rapidly aged out distros like
non-LTS Ubuntu , Fedora, etc or go for very long lived LTS releases like
Debian stable, Ubuntu LTS, RHEL/Rocky/ALMA, etc. I'm personally an LTS
person as I don't need bleeding edge nor want constantly re-work my OS
just because I can.


Are you aware of any alternative techniques of upgrading the OS without
loosing all the custom files and configurations that have been created over
time? I'm thinking that after burning a new Bullseye image on a new
SD-card, perhaps rsync might be coaxed into restoring all the former Buster
customizations and personal files.
What I generally do is create backups of my critical configuration
files. Here is an example of my backup script:

http://www.trinityos.com/HAM/CentosDigitalModes/RPi/usr/local/sbin/backup-rpi-files.sh

I then do is:

1. Install the new OS on a SD card (ideally, I start with new cards
as they have zero to a little wear on the flash cells)

2. Get the new OS running to the point I can log into it and sudo

3. Copy over the previous backup tar.xz file and uncompress it to a
staging area

4. I go through EACH file in the restored backup stage area and use
vim's "diff mode" such as "vim -d previous-backup-os-config-file
new-os-config-file" and I manually update the new OS's file to have all
the settings I need, research changes I don't recognize, and complete
the edit.

That all takes time but I feel it's the best compromise for myself.

--David
K6ZHD





Bob K4RCG
 

Larry, I took the same approach. I use 5 RasPi4 for various ham projects….all set the way I like, and still on Buster.  My pi skills are weak; I’m reluctant to tempt fate with upgrade to Bullseye!!  I plan to attempt an upgrade in the future as a learning opportunity. But for now, I’m remaining as-is.

73 de Bob
K4RCG

On Sun, Apr 10, 2022 at 19:17 Larry Dighera <LDighera@...> wrote:

David,

Thank you very much for your thoughtful and very informative response. 

After giving it some thought, I don't really have the time to deal with the
potential issues that would likely result from upgrading to Bullseye. Buster
is stable, and configured the way I want it, so I'll just remain a release
behind until I'm forced to generate a new system at some point in the
future.

I am grateful for the first hand experience and knowledge you've shared.

Best regards,
Larry
WB6BBB


On Sun, 10 Apr 2022 13:54:14 -0700, "David Ranch"
<rpi4hamradio-groupsio@...> wrote:

>
>Hello Larry,
>
>> So, I'm
>> wondering your opinion on this technique for upgrading the OS from Buster to
>> Bullseye by simply editing /etc/apt/sources.list, and changing all instances
>> of buster to bullseye (after first creating an SD-card image with dd, of
>> course)?
>
>Generally speaking, I never recommend inline OS upgrades it for a few
>major reasons (highest to lowest) though I know it's a pain to start
>from scratch:
>
>    1. configuration settings change over time and settings that were
>being deprecated in Buster might be now FULLY deprecated in Bullseye. 
>The result here is things just won't work and that's frustrating
>
>    2. As you've been using your computer over time, you naturally
>install, try, and abandon software.  All that brings in a lot of storage
>bloat, complicated dependencies, etc.  I feels it's always good to start
>with the clean slate.
>
>    3. default configuration settings come in with a new OS yet you
>won't get them as you already have an existing configuration with
>possibly OLD settings
>
>    4. Some things just outright change in newer distros but you won't
>learn about these changes unless you re-install and spot the
>differences.  It's really the only REAL way to learn IMHO
>
>    5. Debian does try to support OS upgrades but they caveat the whole
>process in a LOT of places.  Check out the official Buster to Bullseye
>process here:
>
>https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.html
>
>      As you can see, there are roughly 25 steps you have to go through
>and there aren't any guarantees it will work.
>
>
>Btw, there are some distros that try to close those gaps by supporting a
>"rolling release".  Some of these distros include Arch, Debian
>"testing", Solus, Void, etc.   When changes come in with a rolling
>release distro, they show you diffs of the new config file settings are
>vs. what you have.  This can be helpful and informative but it's a LOT
>of constant work to keep up, research any conflicting settings, etc. 
>These distros require work to be done almost every time you just try to
>patch your machine.  On the pro side, your OS now never gets old but on
>the con side, you're constantly upgrading, disrupting, and possibly
>bringing in breakage.
>
>It's really a deep personal preference if you want to be on very
>bleeding edge, trailing bleeding edge, rapidly aged out distros like
>non-LTS Ubuntu , Fedora, etc or go for very long lived LTS releases like
>Debian stable, Ubuntu LTS, RHEL/Rocky/ALMA, etc.  I'm personally an LTS
>person as I don't need bleeding edge nor want constantly re-work my OS
>just because I can.
>
>
>> Are you aware of any alternative techniques of upgrading the OS without
>> loosing all the custom files and configurations that have been created over
>> time?  I'm thinking that after burning a new Bullseye image on a new
>> SD-card,  perhaps rsync might be coaxed into restoring all the former Buster
>> customizations and personal files.
>
>What I generally do is create backups of my critical configuration
>files.  Here is an example of my backup script:
>
>http://www.trinityos.com/HAM/CentosDigitalModes/RPi/usr/local/sbin/backup-rpi-files.sh
>
>I then do is:
>
>    1. Install the new OS on a SD card (ideally, I start with new cards
>as they have zero to a little wear on the flash cells)
>
>    2. Get the new OS running to the point I can log into it and sudo
>
>    3. Copy over the previous backup tar.xz file and uncompress it to a
>staging area
>
>    4. I go through EACH file in the restored backup stage area and use
>vim's "diff mode" such as "vim -d previous-backup-os-config-file
>new-os-config-file" and I manually update the new OS's file to have all
>the settings I need, research changes I don't recognize, and complete
>the edit.
>
>That all takes time but I feel it's the best compromise for myself.
>
>--David
>K6ZHD
>
>
>
>
>






Mark Griffith
 

Beware the shift to 64 bits.  I installed the latest 64 bit image from RasPi foundation, and it worked fine until I tried to run a long time popular piece of software and it failed to run.  It acted as if the file was non-executable.  Installed the latest 32bit version and it all worked perfectly.  That piece of software was compiled as a 32bit executable, but it should not have made a difference.

I also tried the upgrade-in-place option on two different Pi 4s and one worked OK and the other ended up half-way upgraded with a bunch of errors.  Once that happens is is pretty much impossible to work it all out so a new image needs to be installed.

This is a common problem with open sourced software and is the main reason that big companies pay the license fees for SuSe Linux or RedHat Linux.  They guarantee any upgrades will not break previous installed software or make undocumented changes to the OS, but you pay big bucks for that.  If you ran into an upgrade issue with RedHat, they would get involved and work it out for you.

Basically, open source software uses the user community as their beta test group.  You can't expect too much as the software is free.  The Raspi foundation has done a huge amount of work for the global community and are to be applauded for their efforts.  Just don't expect too much.

Just my 2 cents.

Mark
KD0QYN


On Sunday, April 10, 2022, 12:15:11 PM CDT, Daniel Holmes <danielh@...> wrote:


I followed the instructions in this forum post: https://forums.raspberrypi.com/viewtopic.php?t=323279

It worked, I had some resolution issues that were tough to track down (I run a pi4 headless, VNC was quite argumentative with me, as there were multiple locations of config files that had been left behind via multiple VNC servers.)

Next is to upgrade to 64 bit, but I think that one I’m going to do fresh. I have a lot of software that I run on this 4, so that project is a ways off. 

Thanks,
Dan

--
. Please pardon any mispelings or errors.


On Apr 10, 2022, at 10:39 AM, Larry Dighera <LDighera@...> wrote:


Hello David,

Thank you for the timely news.

I know you to be a *nix-savvy operator, and value your opinions.  So, I'm
wondering your opinion on this technique for upgrading the OS from Buster to
Bullseye by simply editing /etc/apt/sources.list, and changing all instances
of buster to bullseye (after first creating an SD-card image with dd, of
course)?  

Are you aware of any alternative techniques of upgrading the OS without
loosing all the custom files and configurations that have been created over
time?  I'm thinking that after burning a new Bullseye image on a new
SD-card,  perhaps rsync might be coaxed into restoring all the former Buster
customizations and personal files.

Best regards,
Larry
WB6BBB



On Fri, 8 Apr 2022 08:36:30 -0700, "David Ranch"
<rpi4hamradio-groupsio@...> wrote:


It seems that the Raspberry Pi Foundation has changed their published
Bullseye image to NO LONGER create the "pi" user account.  I personally
think this is a good thing and my published documentation has always
recommended to either disable or outright delete that well known account.

https://www.raspberrypi.com/news/raspberry-pi-bullseye-update-april-2022/







shulerb
 

You’ve got to go to 64 bit software. There is a 32 bit framework you can load but 32 bit software doesn’t run on 64 bit 
If there is a 64 bit version compile that. I used to code 16 bit and swapping to 32 bits caused the same issues. Leave 32 bits behind if you’re on 64.  Programs will eventually catch up.

On Sun, Apr 10, 2022 at 7:43 PM Mark Griffith via groups.io <mdgriffith2003=yahoo.com@groups.io> wrote:
Beware the shift to 64 bits.  I installed the latest 64 bit image from RasPi foundation, and it worked fine until I tried to run a long time popular piece of software and it failed to run.  It acted as if the file was non-executable.  Installed the latest 32bit version and it all worked perfectly.  That piece of software was compiled as a 32bit executable, but it should not have made a difference.

I also tried the upgrade-in-place option on two different Pi 4s and one worked OK and the other ended up half-way upgraded with a bunch of errors.  Once that happens is is pretty much impossible to work it all out so a new image needs to be installed.

This is a common problem with open sourced software and is the main reason that big companies pay the license fees for SuSe Linux or RedHat Linux.  They guarantee any upgrades will not break previous installed software or make undocumented changes to the OS, but you pay big bucks for that.  If you ran into an upgrade issue with RedHat, they would get involved and work it out for you.

Basically, open source software uses the user community as their beta test group.  You can't expect too much as the software is free.  The Raspi foundation has done a huge amount of work for the global community and are to be applauded for their efforts.  Just don't expect too much.

Just my 2 cents.

Mark
KD0QYN


On Sunday, April 10, 2022, 12:15:11 PM CDT, Daniel Holmes <danielh@...> wrote:


I followed the instructions in this forum post: https://forums.raspberrypi.com/viewtopic.php?t=323279

It worked, I had some resolution issues that were tough to track down (I run a pi4 headless, VNC was quite argumentative with me, as there were multiple locations of config files that had been left behind via multiple VNC servers.)

Next is to upgrade to 64 bit, but I think that one I’m going to do fresh. I have a lot of software that I run on this 4, so that project is a ways off. 

Thanks,
Dan

--
. Please pardon any mispelings or errors.


On Apr 10, 2022, at 10:39 AM, Larry Dighera <LDighera@...> wrote:


Hello David,

Thank you for the timely news.

I know you to be a *nix-savvy operator, and value your opinions.  So, I'm
wondering your opinion on this technique for upgrading the OS from Buster to
Bullseye by simply editing /etc/apt/sources.list, and changing all instances
of buster to bullseye (after first creating an SD-card image with dd, of
course)?  

Are you aware of any alternative techniques of upgrading the OS without
loosing all the custom files and configurations that have been created over
time?  I'm thinking that after burning a new Bullseye image on a new
SD-card,  perhaps rsync might be coaxed into restoring all the former Buster
customizations and personal files.

Best regards,
Larry
WB6BBB



On Fri, 8 Apr 2022 08:36:30 -0700, "David Ranch"
<rpi4hamradio-groupsio@...> wrote:


It seems that the Raspberry Pi Foundation has changed their published
Bullseye image to NO LONGER create the "pi" user account.  I personally
think this is a good thing and my published documentation has always
recommended to either disable or outright delete that well known account.

https://www.raspberrypi.com/news/raspberry-pi-bullseye-update-april-2022/






--
photo
Shuler Burton
Consultant, Burton Consulting
803.480.1561 | shulerburton@...
551 W Church St.,   Batesburg-Leesville SC 29006

Please consider your environmental responsibility. Before printing this e-mail message, ask yourself whether you really need a hard copy.

IMPORTANT: The contents of this email and any attachments are confidential. They are intended for the named recipient(s) only. If you have received this email by mistake, please notify the sender immediately and do not disclose the contents to anyone or make copies thereof.


David Ranch
 


Hello Larry,

After giving it some thought, I don't really have the time to deal with the
potential issues that would likely result from upgrading to Bullseye. Buster
is stable, and configured the way I want it, so I'll just remain a release
behind until I'm forced to generate a new system at some point in the
future.

I can appreciate the pain and work required but please understand that running an old operating system can eventually cause you security and application issues if your devices are connected to the Internet.  Yes, Raspberry Pi OS's old-stable "Buster" release still gets Debian level OS package updates and security fixes but the *kernel* won't get fixes, security updates, etc. anymore.  You can learn more about that behavior here:

   https://forums.raspberrypi.com/viewtopic.php?t=297441

The kernel not getting updates isn't good as a LOT of security issues come from the kernel side of things.  Debian's side of Buster support should still receive updates for 2yrs after it was released ( https://forums.raspberrypi.com/viewtopic.php?t=281783 ) aka.. it's EOL is slated for 08/2022 ( https://wiki.debian.org/DebianReleases#Current_Releases.2FRepositories ) but that's only FOUR more months!  One positive thing to consider is if you carefully read that previous Debian URL, there are other groups that try to extend the lifetime of various releases outside of the official Debian ecosystem.  They operate these LTS and ELTS repos for old distros so you might try to give them a try though read the "issues to be aware of" document VERY CAREFULLY to see if there are any key gotchas.

I know this is all a pain but I would encourage you that once a new Raspberry Pi OS versions released, you really should try to move your systems to the new version about +6mo after the new OS is available.  If that's not possible,  try using on of these LTS or ELTS repos to keep things going for a year or two longer.

--David
KI6ZHD


Charles Gallo
 

On 2022-04-10 19:42, Mark Griffith via groups.io wrote:

 
Beware the shift to 64 bits.  I installed the latest 64 bit image from RasPi foundation, and it worked fine until I tried to run a long time popular piece of software and it failed to run.  It acted as if the file was non-executable.  Installed the latest 32bit version and it all worked perfectly.  That piece of software was compiled as a 32bit executable, but it should not have made a difference.

Hahahaha - I work for a company and we do a lot of RPi code - and guess what?  Doesn't work on 64 bit - it is a .Net6 (was .net Core 3.1) app, and is compiled as Arm32 (compiling as Portable doesn't work) - and it plain doesn't work.  Lot of I2C stuff, bunch of GPIO pin code, designed primarily around running the official RPi touch screen (although works fine on any screen I've tried - all HTML/Blazor code - just screen layouts can get odd)

--
Charles Gallo - KG2V
http://www.thegallos.com


David Ranch
 


Hello Everyone,

Beware the shift to 64 bits.  I installed the latest 64 bit image from RasPi foundation, and it worked fine until I tried to run a long time popular piece of software and it failed to run.  It acted as if the file was non-executable.  Installed the latest 32bit version and it all worked perfectly.  That piece of software was compiled as a 32bit executable, but it should not have made a difference.

When you install a "clean" 64bit OS, it's only going to support 64bit binaries and like Mark observed, 32bit binaries will NOT execute.  What you can do is install all the 32bit version of all the libraries required for your 32bit program to run.  This can dramatically increase the size of your OS by substantial amounts.  What I generally recommend to do is NEVER install anything 32bit on a modern 64bit OS if you can help it.  This absolutely means that some older software will no longer be available to you and you might have to look for alternative programs that ARE available in 64bit form.  Your decision.

On a Raspberry Pi SBC, the performance benefits for the 64bit OS is questionable compared to the 32bit version.  Yes.. some specific use cases can get sped up by a bit but overall, I don't think the combination of additional consumed RAM + additional consumed storage space to get minimal performance gains is worth it.


I also tried the upgrade-in-place option on two different Pi 4s and one worked OK and the other ended up half-way upgraded with a bunch of errors.  Once that happens is is pretty much impossible to work it all out so a new image needs to be installed.

Exactly and I've seen similar upgrade efforts go this way.  It really can be unpredictable. 

--David
KI6ZHD


David Lane
 

Maybe a silly question, but why not just recompile the software for 64bit? (Since I don’t know what the actual software in question is, I just assume the source is available). 


--
David A. Lane, KG4GIY
EC/RO Prince William County ARES®/RACES
+1.703.628.3868
http://www.pwcares.org/
IM/Skype: kg4giy




On Apr 11, 2022, at 1:33 PM, David Ranch <rpi4hamradio-groupsio@...> wrote:


Hello Everyone,

Beware the shift to 64 bits.  I installed the latest 64 bit image from RasPi foundation, and it worked fine until I tried to run a long time popular piece of software and it failed to run.  It acted as if the file was non-executable.  Installed the latest 32bit version and it all worked perfectly.  That piece of software was compiled as a 32bit executable, but it should not have made a difference.

When you install a "clean" 64bit OS, it's only going to support 64bit binaries and like Mark observed, 32bit binaries will NOT execute.  What you can do is install all the 32bit version of all the libraries required for your 32bit program to run.  This can dramatically increase the size of your OS by substantial amounts.  What I generally recommend to do is NEVER install anything 32bit on a modern 64bit OS if you can help it.  This absolutely means that some older software will no longer be available to you and you might have to look for alternative programs that ARE available in 64bit form.  Your decision.

On a Raspberry Pi SBC, the performance benefits for the 64bit OS is questionable compared to the 32bit version.  Yes.. some specific use cases can get sped up by a bit but overall, I don't think the combination of additional consumed RAM + additional consumed storage space to get minimal performance gains is worth it.


I also tried the upgrade-in-place option on two different Pi 4s and one worked OK and the other ended up half-way upgraded with a bunch of errors.  Once that happens is is pretty much impossible to work it all out so a new image needs to be installed.

Exactly and I've seen similar upgrade efforts go this way.  It really can be unpredictable. 

--David
KI6ZHD


David Ranch
 


Generally speaking, most people don't know how to compile things and only want to install pre-built packages.  The other side is that there is a lot of legacy amateur radio programs for Linux that quite old that won't successfully build on 64bit, depend on deprecated dependencies, libraries, etc.  It's really unclear which programs will get updates and what programs will just fade away into the history books.

--David
KI6ZHD




On 04/11/2022 10:45 AM, David Lane wrote:
Maybe a silly question, but why not just recompile the software for 64bit? (Since I don’t know what the actual software in question is, I just assume the source is available). 


--
David A. Lane, KG4GIY
EC/RO Prince William County ARES®/RACES
+1.703.628.3868
http://www.pwcares.org/
IM/Skype: kg4giy




On Apr 11, 2022, at 1:33 PM, David Ranch <rpi4hamradio-groupsio@...> wrote:


Hello Everyone,

Beware the shift to 64 bits.  I installed the latest 64 bit image from RasPi foundation, and it worked fine until I tried to run a long time popular piece of software and it failed to run.  It acted as if the file was non-executable.  Installed the latest 32bit version and it all worked perfectly.  That piece of software was compiled as a 32bit executable, but it should not have made a difference.

When you install a "clean" 64bit OS, it's only going to support 64bit binaries and like Mark observed, 32bit binaries will NOT execute.  What you can do is install all the 32bit version of all the libraries required for your 32bit program to run.  This can dramatically increase the size of your OS by substantial amounts.  What I generally recommend to do is NEVER install anything 32bit on a modern 64bit OS if you can help it.  This absolutely means that some older software will no longer be available to you and you might have to look for alternative programs that ARE available in 64bit form.  Your decision.

On a Raspberry Pi SBC, the performance benefits for the 64bit OS is questionable compared to the 32bit version.  Yes.. some specific use cases can get sped up by a bit but overall, I don't think the combination of additional consumed RAM + additional consumed storage space to get minimal performance gains is worth it.


I also tried the upgrade-in-place option on two different Pi 4s and one worked OK and the other ended up half-way upgraded with a bunch of errors.  Once that happens is is pretty much impossible to work it all out so a new image needs to be installed.

Exactly and I've seen similar upgrade efforts go this way.  It really can be unpredictable. 

--David
KI6ZHD