Jump to content
  • 0

Does upgrading from Buster to Bullseye still break the system?


mrjpaxton
 Share

Question

Hey guys, I figured it was time to ask again...

 

Does doing an `apt full-upgrade` from Buster to Bullseye break anything like before a year ago? I kind of want to do it, but not if the eMMC issues are still around. I really prefer not using the slower SD card method.

 

And i also want to ask about stability for people that still use a Kobol with Armbian on Bullseye. Any pertinent issues with anything? A few people on here have claimed that they have gotten the vanilla Debian kernel to run on the Helios64, but I'm not sure how... Sure would be great if the vanilla Debian distro worked on this board, but I doubt that'll ever happen...

 

I love my Kobol, and I am going to have a hard time finding a good replacement for it. i just really like having full CLI access, complete understanding of all the hardware, little to no proprietary bits, and also the open-ness of the hardware. It's all great. But man, finding alternatives NASes is going to be hard for me now. Hahaha.

 

(Please ignore the fact that I posted this on April Fools Day. That's just a coincidence).

Link to comment
Share on other sites

9 answers to this question

Recommended Posts

  • 0

Hi there,

 

the emmc issues were solved by reducing read/write speed by a factor of 2 (thanks to @piter75). Unfortunately this is still the case with newer kernels 5.15.xx.

I am still using linux 5.10.43 without any issues and without the emmc speed limitation (Armbian 21.08.2 Bullseye with Linux 5.10.43-rockchip64).

 

Upgrading from Buster to Bullseye should work, but your mileage may vary depending on your specific Buster installation. The upgrade will install the newest kernel 5.15.25. I had troubles at least with rsync in this context.

 

Alternatively you can grab the latest Armbian Bullseye Image (Armbian_21.08.2_Helios64_bullseye_current_5.10.63.img.xz) from the archive and downgrade to linux 5.10.43.

To do that you just need to download those files and install them with 'dpkg -i *.deb' and disable any further Armbian updates in /etc/apt/sources.list.d/armbian.list . Debian updates will still arrive ...

The system on SD can be transferred to emmc.

 

Cheers!

Link to comment
Share on other sites

Donate and support the project!

  • 0
9 hours ago, mrjpaxton said:

vanilla Debian kernel

 

I see this a lot, and I am afraid it's a common misunderstanding.  Debian is a distribution, they distribute (mostly user space) packages from various places.  The kernels they get wholesale (from kernel.org, usually).

 

Which is why the kernels in vanilla Debian (generally speaking) are going to be so far behind Armbian's (heavily patched and customized) kernels.  In fact, this is essentially one of the main raisons d'être for Armbian in the first place.  SBC/ARM is very different from x86, which is much more standardized on a hardware level.

 

And that's also why, the user space comes pretty much straight from upstream vanilla Debian.  Because that's not what we do here.  Here we are focused on the (much more difficult) low level things, like kernels, bootloaders, etc.  Where vanilla Debian do not.

 

It will be nice if one day this is not the case, but I just don't see that happening in foreseeable future.

Link to comment
Share on other sites

  • 0
11 hours ago, ebin-dev said:

Hi there,

 

the emmc issues were solved by reducing read/write speed by a factor of 2 (thanks to @piter75). Unfortunately this is still the case with newer kernels 5.15.xx.

I am still using linux 5.10.43 without any issues and without the emmc speed limitation (Armbian 21.08.2 Bullseye with Linux 5.10.43-rockchip64).

 

Upgrading from Buster to Bullseye should work, but your mileage may vary depending on your specific Buster installation. The upgrade will install the newest kernel 5.15.25. I had troubles at least with rsync in this context.

 

Alternatively you can grab the latest Armbian Bullseye Image (Armbian_21.08.2_Helios64_bullseye_current_5.10.63.img.xz) from the archive and downgrade to linux 5.10.43.

To do that you just need to download those files and install them with 'dpkg -i *.deb' and disable any further Armbian updates in /etc/apt/sources.list.d/armbian.list . Debian updates will still arrive ...

The system on SD can be transferred to emmc.

 

Cheers!

 

So I continued to keep Buster by putting in "buster", "buster-upgrades", etc.. in my /etc/apt/sources.list files, then did an `apt full-upgrade`. It pulled in the latest kernel 5.15.25 and some other updates, and the rsync issues you were talking about did not happen to me. So it sounds like it is possible to only get kernel 5.15.25 working on Buster well enough. Either that, or I'm just lucky. But I am going to check stability for at least a week before I even consider re-flashing with Bullseye (I won't even upgrade from Buster to Bullseye within Buster, I suppose.)

 

But if Bullseye still has issues with things on Kobol, even when re-flashing it new and copying over my config files that I've backed up, I guess I will be sticking with Buster... I have no idea how long updates to Buster are going to be supported by Armbian anyway.

Link to comment
Share on other sites

  • 0
16 hours ago, mrjpaxton said:

It pulled in the latest kernel 5.15.25 and some other updates, and the rsync issues you were talking about did not happen to me.

 

Interesting !

 

I tried again with a fresh Armbian Bullseye Image (Armbian_21.08.2_Helios64_bullseye_current_5.10.63.img.xz) on SD and used apt update && apt upgrade to install the latest kernel 5.15.25.

After a reboot, an rsync from SD to another SD attached to the USB port worked perfectly.

 

I have noticed today that SD and emmc device names have changed between linux 5.10.xx and linux 5.15.yy from /dev/mmcblk2p1 (emmc) and /dev/mmcblk1p1 (SD) to /dev/mmcblk1p1 and /dev/mmcblk0p1 respectively. Since my backup scripts use the device names they could not work correctly anymore with kernel 5.15.yy. MEA CULPA.

 

All device names are now replaced by their corresponding UUIDs in the backup scripts - so that this can't happen again.

 

So you can update your buster or bullseye installation to the latest Armbian kernel (no rsync issues) - but be aware that there are still some other issues to be resolved, in particular if you are using zfs-dkms (see the parallel threads).

 

Link to comment
Share on other sites

  • 0
7 hours ago, ebin-dev said:

 

Interesting !

 

I tried again with a fresh Armbian Bullseye Image (Armbian_21.08.2_Helios64_bullseye_current_5.10.63.img.xz) on SD and used apt update && apt upgrade to install the latest kernel 5.15.25.

After a reboot, an rsync from SD to another SD attached to the USB port worked perfectly.

 

I have noticed today that SD and emmc device names have changed between linux 5.10.xx and linux 5.15.yy from /dev/mmcblk2p1 (emmc) and /dev/mmcblk1p1 (SD) to /dev/mmcblk1p1 and /dev/mmcblk0p1 respectively. Since my backup scripts use the device names they could not work correctly anymore with kernel 5.15.yy. MEA CULPA.

 

All device names are now replaced by their corresponding UUIDs in the backup scripts - so that this can't happen again.

 

So you can update your buster or bullseye installation to the latest Armbian kernel (no rsync issues) - but be aware that there are still some other issues to be resolved, in particular if you are using zfs-dkms (see the parallel threads).

 

I am really happy to hear that you were able to narrow down the rsync issue!

 

Yeah, for me, rsync is one of those essential utilities I couldn't function without to do my backups properly. Using scp just doesn't cut it anymore! And I am not hacking it to use a Btrfs root FS on my Armbian install, so I can't just use Btrfs send and receive on snapshots to backup (or, for example, the equivalent way for ZFS).

 

My NAS is a Btrfs RAID 1, just set up with pure Armbian and NFS (no OMV) so I think I won't run into any ZFS issues... I might be good to go and try it out next week, maybe..

 

Like I said, I can always just re-flash a Bullseye Armbian image and migrate over my config files.

 

As a side note, the halved performance slowdown on eMMC is a minor concern. Sometimes I want to use the NAS with other services. For example, I also have it set up as my print server (CUPS), so it needs to access the spool, etc... and I'm also thinking about trying some other services on it in the future. But anyway, even `apt cache search` runs very, very slow after it gets to "50%" for some reason, and I have no idea why. I think someone on here had a fix for this, but I can't remember what it was...

Link to comment
Share on other sites

  • 0

if who has installed OMV 5, this should be updated before update to Bullseye!
OMV 5 still uses pam_tally2.so which is no longer present with the lib package in Bullseye.
With OMV 6 this is only corrected !

Link to comment
Share on other sites

  • 0

Hello here,

 

I also have a helios 64 with, Armbian 22.02.1 (Debian 10 buster), kernel 5.15.25 and OMV5

/ is mount on eMMC and I have a raid5 on sd{a,b,c,d,e} and after it's lvm; all lv are mount on /srv/dev-disk-by-uuid-*

 

On 4/2/2022 at 11:30 PM, mrjpaxton said:

As a side note, the halved performance slowdown on eMMC is a minor concern. Sometimes I want to use the NAS with other services. For example, I also have it set up as my print server (CUPS), so it needs to access the spool, etc... and I'm also thinking about trying some other services on it in the future. But anyway, even `apt cache search` runs very, very slow after it gets to "50%" for some reason, and I have no idea why. I think someone on here had a fix for this, but I can't remember what it was...

 

Yes, i have the same problem with apt search, it's very very slow.

But other than that I did not detect a problem.

 

On 4/3/2022 at 9:22 PM, TDCroPower said:

if who has installed OMV 5, this should be updated before update to Bullseye!
OMV 5 still uses pam_tally2.so which is no longer present with the lib package in Bullseye.
With OMV 6 this is only corrected !

 

 

I'm not sure I understand...
To understand two things in fact.

1) when we talk about Armbian 22.02.1, it's "two versions" in reality:
- Armbian 22.02.1 on Debian 10
- Armbian 22.02.1 on Debian 11

 

2)
If I want to switch to on armbian Debian 11 Bullseye, I must update before OMV (5 -> 6) ?
So:

Update OMV 5 -> 6
 

sed -i -e 's/usul/shaitan/g' /etc/apt/sources.list.d/*

apt update

apt upgrade

 

Upgrade armbian Debian 10 -> armbian Debian 11


 

sed -i -e 's/buster/bullseye/g' /etc/apt/sources.list.d/*

sed -i -e 's/buster/bullseye/g' /etc/apt/sources.list

apt update

apt full-upgrade

 

thx

Link to comment
Share on other sites

  • 0
On 4/2/2022 at 4:19 PM, ebin-dev said:

So you can update your buster or bullseye installation to the latest Armbian kernel (no rsync issues) - but be aware that there are still some other issues to be resolved,

 

I just had an issue with the 2.5G interface after the latest update to Armbian Bullseye 22.02.01 (linux 5.15.25):  The 2.5G Interface would not appear to work as expected anymore.

 

A 12.225 GB test file was transferred from Helios64 to a client via a 2.5G switch using netatalk with only about 120 MB/s.  The system I am normally using ( Armbian 21.08.2 Bullseye, linux downgraded to 5.10.43), transfers the file with 271 MB/s (as expected).

 

Here are the related dmesg messages :

[   11.159252] r8152 2-1.4:1.0: Direct firmware load for rtl_nic/rtl8156a-2.fw failed with error -2
[   11.159293] r8152 2-1.4:1.0: unable to load firmware patch rtl_nic/rtl8156a-2.fw (-2)
[   11.199745] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): netif_napi_add() called with weight 256
[   11.215517] r8152 2-1.4:1.0 eth1: v1.12.12
[   11.215734] usbcore: registered new interface driver r8152
[   14.606490] r8152 2-1.4:1.0 eth1: Promiscuous mode enabled
[   14.606732] r8152 2-1.4:1.0 eth1: carrier on

 

Is there anyone observing the same issue ?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...