Debian 11 (bullseye) Testing Images

Silly question, I’m updating a fleet of PocketBeagles which started out running Debian Stretch-based images.

The last OS update to Buster was achieved by adjusting /etc/apt/sources.list and doing an apt-get update && apt-get dist-upgrade -y, and that seemed to go fine.

I did the same trick yesterday on one of the nodes, and had the update fall flat on its face. I should hook up a serial console to see where it’s failing, but effectively it bricked the OS.

For now I just took a back-up of that failed update, then flashed the latest console image and I’m trying an apt-get dist-upgrade to Bullseye on that now. Update: Having done this, the PocketBeagle boots, but it appears the USB gadget support is broken by this sort of update, making the device inaccessible unless serial console is connected.

Looking in Index of /rootfs/debian-armhf/2021-12-12 I don’t see the console image listed. Are there plans to release such an image? In the application I’m using these for, we’re not using the Cloud9 and NodeRED features that are part of the IoT image, so keeping to a plain and minimal image is desirable.

Hi @sjlongland

I’l need to write some more directions on moving from stretch/buster to bullseye…

I’ve dropped conman for systemd-networkd, this allows us to use simple udev rules to enable a lot of things we did in stretch/buster (some of which is not backwards portable to stretch/buster due to new systemd features…)

the opt scripts directory is gone, everything has a debian package now…

yeah, i think we are ready for console/iot images for Bullseye, i’ve got most things works now days on Bullseye…

Regards,

2 Likes

Hi Beagleboard community, Hi @RobertCNelson ,

In 2019 I finally finished my BBB-based NAS (with laser-cut housing). If you’re interested, read about it here.

Since 2018 it didn’t really get any proper software update, and other than the security issues (it’s not internet accessible right now), I’m also very limited by the packages still available.

I’m currently running on Ubuntu 14.04.6 LTS (GNU/Linux 4.4.21-ti-r45 armv7l).

With Debian 11, I could upgrade to the v5 kernel and get kernel support for exFAT so that our removable storage works on all OSses (windows + mac + linux).

Long story short: I’ve not been very active with embedded software in recent years and could use some advice on which image is stable to do a fresh install on the BBB. My goal is to have another rock-solid system that can last for years.

Features I’ve been using

  • EXT4 filesystem on eMMC (set up to auto-fix when power goes off unexpectedly)
  • EXT4 filesystem on SSD + HD (I’m spinning the drive down automatically when not used)
  • Solid kernel (the first one I had wasn’t stable)

Want to add

  • Set up a solid rsync backup
  • exFAT to backup external drives

Nothing too crazy, it just needs to be solid and low maintenance for years to come :slight_smile:

Thanks for all of your work!

Hi @phalox , so our 5.4.x-ti, 5.10.x-ti and 5.15.x-bone branches have exfat built-in. For the am335x you really don’t see an advantage between ti the branch and mainline anymore. As 99% of everything is mainline…

Most of my current testing is on v5.10.x and v5.15.x… I’m just finally starting to EOL v4.19.x in my test farm this week… (how many years of testing is that; Nov 2018… so 3 years…)

For the am335x i’d say start with v5.15.x and let me know if you have issues. Right now I’ve got 4 boards in my automatic tester running v5.15x, with more being transited later in the next few weeks…

Starting the 1st of the year, i will have Monthy Bullseye images, you can see a sneak peak with:

https://rcn-ee.net/rootfs/bb.org/testing/2021-12-28/bullseye-iot/

Regards,

Almost 2 months later! It’s about time I get started on this. But before I break my production system running off of the EMMC, I wanted to double check some things.

I see the latest testing image is am335x-debian-11.2-iot-armhf-2022-02-03-4gb.img.xz
Use balenaEtcher - Flash OS images to SD cards & USB drives to put it on an SD card
Plug it into the bbb, power it and it will boot from the SD card instead?

That’s great for testing!

How would I then proceed to flash it to emmc?

For reference, (as this thread) has a few old ones, latest can be found here…

@phalox, once you booted the first time (on microSD)… Just run:

sudo enable-beagle-flasher
sudo reboot

and it’ll set the bits needed to make it into an eMMC flasher image…

Regards,

Hi I have upgraded Buster to Bullseye. Most things go well. Anyway I would like to clear below problems which are seen during boot

debug: [bootz 0x82000000 0x88080000:6911b0 88000000] …

Flattened Device Tree blob at 88000000

Booting using the fdt blob at 0x88000000
Loading Ramdisk to 8f96e000, end 8ffff1b0 … OK
Loading Device Tree to 8f8e2000, end 8f96dfff … OK

Starting kernel …

[ 0.002172] timer_probe: no matching timers found
[ 0.196984] l4_wkup_cm:clk:0010:0: failed to disable
[ 1.439860] omap_voltage_late_init: Voltage driver support not added
rootfs: clean, 132204/1888768 files, 977845/7790720 blocks
[ 8.833523] cgroup: cgroup2: unknown option “memory_recursiveprot”

Debian GNU/Linux 10 beaglebone ttyS0

BeagleBoard.org Debian Buster IoT Image 2020-04-06

Could you please guide me how I can proceed with that?

Hi @Michal_Poterek i see lots of ‘warnings’ but no real problems…

Please pin point which line you are woried about… PS your kernel might be too old, so please add the value of uname -r so we can help…

Regards,

Hi Robert, I’m running the new image now. On my legacy setup, I forced FSCK to auto fix any issues that might occur on the root file system (usually after power was dropped). I was now trying to reimplement this on the new image, but I’m not sure how to pass the ‘fsck -y’ to the systemd. Any advice?

Also, any clue why my root file system is absolutely full? Did the image size itself grow significantly or did I fill it up for some reason?

sudo du -h --max-depth=1
1.4M    ./root
4.0K    ./srv
11M     ./bin
4.0K    ./media
48K     ./tmp
7.2M    ./sbin
1.9G    ./usr <--------------
16K     ./lost+found
2.2M    ./run
714M    ./opt <--------------
0       ./proc
296M    ./lib
196K    ./home
16K     ./mnt
0       ./sys
467M    ./var <----------------
22M     ./etc
0       ./dev
34M     ./boot
3.4G    .

Is /usr/lib/arm-linux-gnueabihf (913M) installed by default? Or did I somehow put a compiler on this system? It’s so full right now that I cannot even do anything anymore :slight_smile: So I’m trying to figure out what to delete.

1 Like

sudo beaglecfg is the command to bring a SD Card to the full memory widths.

Seth

P.S. There is an option in that entry field for SD Card. If you have a higher GB SD Card, that command can work.

Just reboot…

The resize script auto runs on first boot, but it doesn’t finish till the 2nd…

Regards,

1 Like

I’m using the internal EMMC, which is 4GB. So it’s full right now!
Let me check what installed the compiler, which I think was not installed by default?

Any hint about FSCK? Where can I configure this?

add it to /boot/uEnv.txt (cmdline) line…

Regards,

1 Like

Hi All,

I did a clean install with am335x-debian-11.2-iot-armhf and checked df -h on the eMMC. It seems that this image fills up majority of the eMMC.

toon@BeagleBone:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            213M     0  213M   0% /dev
tmpfs            49M  1.3M   47M   3% /run
/dev/mmcblk1p1  3.5G  3.2G  125M  97% /
tmpfs           241M     0  241M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            49M     0   49M   0% /run/user/1000

Is there anything obvious that can be removed? With this amount of default install, it becomes hard to still use the eMMC. Should I switch to running of an SD card?

I tried the minimal image, and that seems the be better.

debian@BeagleBone:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            215M     0  215M   0% /dev
tmpfs            49M  1.3M   48M   3% /run
/dev/mmcblk1p1  3.5G  856M  2.5G  26% /
tmpfs           242M     0  242M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            49M     0   49M   0% /run/user/1000

I’ve installed samba which takes up 100MB, but otherwise it seems to be fitting…

Hi there,

Apologies in advance if this is the wrong thread to post my question…

I have a BeagleBone Blue and tried out a recent ‘bullseye’ image from here and also latest ‘buster’ console image from here - both running from sdcard.

When I run ‘rc_test_drivers’ (from librobotcontrol) I get this (expected) result under ‘buster’:

root@beaglebone:~# rc_test_drivers

Kernel: 4.19.94-ti-r42
BeagleBoard_org Debian Buster Console Image 2020-04-06
Debian: 10.12

PASSED: gpio 0
PASSED: gpio 1
PASSED: gpio 2
PASSED: gpio 3
PASSED: pwm0
PASSED: pwm1
PASSED: pwm2
PASSED: eqep0
PASSED: eqep1
PASSED: eqep2
PASSED: pru-rproc
PASSED: uart1
PASSED: uart2
PASSED: uart4
PASSED: uart5
PASSED: i2c1
PASSED: i2c2
PASSED: spi
PASSED: LED
PASSED: ADC iio

Currently running on a:
MODEL_BB_BLUE
Robot Control library Version:
1.0.5

However, the result under ‘bullseye’ is not so good:

root@BeagleBone:~# rc_test_drivers

Kernel: 5.10.109-ti-r43
BeagleBoard_org Debian Bullseye Minimal Image 2022-05-01
Debian: 11.3

PASSED: gpio 0
PASSED: gpio 1
PASSED: gpio 2
PASSED: gpio 3
ERROR: ti-pwm driver not loaded for hrpwm0
ERROR: ti-pwm driver not loaded for hrpwm1
ERROR: ti-pwm driver not loaded for hrpwm2
ERROR: ti-eqep driver not loaded for eqep0
ERROR: ti-eqep driver not loaded for eqep1
ERROR: ti-eqep driver not loaded for eqep2
PASSED: pru-rproc
ERROR: uart1 driver not loaded
ERROR: uart2 driver not loaded
ERROR: uart4 driver not loaded
ERROR: uart5 driver not loaded
ERROR: i2c1 driver not loaded
PASSED: i2c2
ERROR: spi driver not loaded
PASSED: LED
PASSED: ADC iio

Currently running on a:
MODEL_BB_BLUE
Robot Control library Version:
1.0.5

After enabling some extra overlays (guessing) in uEnv.txt:

uname_r=5.10.109-ti-r43
dtb=am335x-boneblue.dtb
enable_uboot_overlays=1
uboot_overlay_pru=AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
uboot_overlay_addr0=BB-I2C1-00A0.dtbo
uboot_overlay_addr1=BB-SPIDEV0-00A0.dtbo
uboot_overlay_addr2=BB-SPIDEV1-00A0.dtbo
uboot_overlay_addr3=BB-UART1-00A0.dtbo
uboot_overlay_addr4=BB-UART4-00A0.dtbo
uboot_overlay_addr5=BB-UART5-00A0.dtbo
uboot_overlay_addr6=BB-UART4-RTSCTS-00A0.dtbo
uboot_overlay_addr7=BB-I2C2-RTC-DS1338.dtbo
disable_uboot_overlay_video=1
dtb_overlay=dev-USB-PWR-CTL-00A1.dtbo
enable_uboot_cape_universal=1
console=ttyS0,115200n8
cmdline=coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100

…made only slight difference:

root@BeagleBone:/boot# rc_test_drivers

Kernel: 5.10.109-ti-r43
BeagleBoard_org Debian Bullseye Minimal Image 2022-05-01
Debian: 11.3

PASSED: gpio 0
PASSED: gpio 1
PASSED: gpio 2
PASSED: gpio 3
ERROR: ti-pwm driver not loaded for hrpwm0
ERROR: ti-pwm driver not loaded for hrpwm1
ERROR: ti-pwm driver not loaded for hrpwm2
ERROR: ti-eqep driver not loaded for eqep0
ERROR: ti-eqep driver not loaded for eqep1
ERROR: ti-eqep driver not loaded for eqep2
PASSED: pru-rproc
ERROR: uart1 driver not loaded
ERROR: uart2 driver not loaded
ERROR: uart4 driver not loaded
ERROR: uart5 driver not loaded
PASSED: i2c1
PASSED: i2c2
PASSED: spi
PASSED: LED
PASSED: ADC iio

Currently running on a:
MODEL_BB_BLUE
Robot Control library Version:
1.0.5

I found there is a ti-eqep kernel module but loading it didn’t make any difference …not sure about the others

So, am I expecting too much from a ‘testing’ image or do I simply need to understand/do more with my configuration to have ‘rc_test_drivers’ produce a 100% PASSED result?

BTW, in case anyone is wondering, I had to manually replace the ‘.’ with a ‘_’ (re ‘BeagleBoard_org’ text in above rc_test_drivers output) as this forum wont let me post more than two links (as a new user) …even though I am not explicitly specifying that text as a link

Hi @RobertCNelson

Am hoping you may be able to comment on my post (above) …suspect my expectations re ‘testing’ images is likely too-high/premature but also hoping full functionality is not too far away?

1 Like

@pka ,

I am not sure how far along you are in this build of librobotcontrol for the am335x-boneblue.dts and kernel 5.10.x but…

  1. GitHub - beagleboard/librobotcontrol: Robotics Focused library for embedded Linux computers.

Seth

P.S. This may help. Also, looking into the issues section could provide some feedback from already configured answers. I am issue 213 on the list. So, w/ time and effort, comes things and stuff. Jump on in!

The Robot Control library has a lot of kernel dependency built into it… Right now it really only supports v4.19.x-ti…

it needs to be ported to v5.4.x-ti/v5.10.x-ti…

Regards,