Jump to content

Orangepi zero 2 supported bullseye cant update

Hervé Changue

By Hervé Changue
in Beginners

 Share

Recommended Posts

Hervé Changue

Hervé Changue

Posted
Posted

Armbian monitor http://ix.io/3BGM

 

Hello updating supported bullseye 4.9 orange pi zero 2 dont work, problem with libc6 because of kernel version. I tried hacking uname -r update was successful but wont boot anymore.

 

I use clean install with clean image from website :

 

dpkg: error processing archive /var/cache/apt/archives/libc6_2.31-13+deb11u2_arm64.deb (--unpack):

 new libc6:arm64 package pre-installation script subprocess returned error exit status 1

Errors were encountered while processing:

 /var/cache/apt/archives/libc6_2.31-13+deb11u2_arm64.deb

E: Sub-process /usr/bin/dpkg returned an error code (1)

 

 

apt --fix-broken install give me :

 

ERROR: Your kernel version indicates a revision number
of 255 or greater.  Glibc has a number of built in
assumptions that this revision number is less than 255.
If you\'ve built your own kernel, please make sure that any
custom version numbers are appended to the upstreamkernel number with a dash or some other delimiter.

 

Thanks for your work

0
Link to comment
Share on other sites
tparys

tparys

Posted
Posted

Ooooh, that's a good problem ...

 

So this apparently the part of the pre-install script that's killing your update. Which is as a result of glibc storing part of the Linux kernel via unsafe assumptions as part of kernel version comparison code.

  

if [ "$system" = "Linux" ]
    then
        # Test to make sure z < 255, in x.y.z-n form of kernel version
        # Also make sure we don't trip on x.y.zFOO-n form
        kernel_rev=$(uname -r | sed 's/\([0-9]*\.\)\{1,2\}\([0-9]*\)\(.*\)/\2/')
        if [ "$kernel_rev" -ge 255 ]
        then
            echo "ERROR: Your kernel version indicates a revision number"
            echo "of 255 or greater.  Glibc has a number of built in"
            echo "assumptions that this revision number is less than 255."
            echo "If you\'ve built your own kernel, please make sure that any"
            echo "custom version numbers are appended to the upstream"
            echo "kernel number with a dash or some other delimiter."
            echo
            exit 1
        fi

 

Presumably, this script is only run on update of the libc6 package. You might be able to downgrade your kernel from 4.9.280 to 4.9.255, reboot, and then resume your update?

 

Another person suggested a slightly more hacky approach HERE, but apparently this issue has been known for some time. Also looks like the patch level is being deliberately applied via build system. Might be worth submitting a bug report? Perhaps @Igor knows more here?

0
Link to comment
Share on other sites
Hervé Changue

Hervé Changue

Posted
  • Author
Posted

Hello thanks for your reply. I tried to Switch kernel with armbian-config but it always fail dunno why, it is a clean install with last supported image Bullseye from website. I found a hack to install libc6 is basically edit uname -r script and echo Fake kernel version like 4.9.250. installation could go on but my orange pi zero 2 wont boot anymore i Guess its another problem. Im rather noob with all this stuff so i dont really know what happen. Have a nice day

 

0
Link to comment
Share on other sites
tparys

tparys

Posted
Posted

Another option is to hack libc6, and just straight up remove that check. You won't be running a signed package, but you should be able to install the package, regardless of your kernel version.

  

~ $ mkdir -p work/libc-hack/DEBIAN
~ $ cd work
work $ apt-get download libc6
work $ dpkg -x libc6_2.31-0ubuntu9.2_arm64.deb libc-hack
work $ dpkg -e libc6_2.31-0ubuntu9.2_arm64.deb libc-hack/DEBIAN

< open up unpack/DEBIAN/preinst with a text editor and remove/comment that "exit 1" (line ~149), save >

work $ fakeroot dpkg-deb --build libc-hack
dpkg-deb: building package 'libc6' in 'libc-hack.deb'.
work $ sudo dpkg -i libc-hack.deb

 

The most correct fix is renumber the kernel version with the last number 255 or less. But unless it starts using debian epoch numbering (ie - 1:linux-image-4.9.XX), upgrading from 4.9.280 without the last number going above 255 is going to be hard.

 

It's kind of a kernel bug, but really a glibc problem. Ultimately, it's Armbian kernel problem, falling on whomever is maintaining that kernel version, and how they want to best tackle that problem.

 

0
Link to comment
Share on other sites
christian_m

christian_m

Posted
Posted (edited)

I had the same issue.

Initially I changed the pre-install script of libc6 and installed it via "dpkg -i".

After that "apt upgrade" continued working.

But then at the end of the update process the uImage in /boot is "updated".

But the Script applies a wrong type to the new uImage.

You can see it on TTL console.

The new one is "Arm64" (?) and he stops booting with it.

If you take the original one from the Installation zip and replace it you will see that boot works again.

Type of this one in the console output is "Arm".

I guess "update script" is comming from a different Project and has not been adjusted for H616?!?

 

Give it a try...

Edited by christian_m
1
Link to comment
Share on other sites
Hervé Changue

Hervé Changue

Posted
  • Author
Posted

 

On 10/22/2021 at 7:42 PM, christian_m said:

I had the same issue.

Initially I changed the pre-install script of libc6 and installed it via "dpkg -i".

After that "apt upgrade" continued working.

But then at the end of the update process the uImage in /boot is "updated".

But the Script applies a wrong type to the new uImage.

You can see it on TTL console.

The new one is "Arm64" (?) and he stops booting with it.

If you take the original one from the Installation zip and replace it you will see that boot works again.

Type of this one in the console output is "Arm".

I guess "update script" is comming from a different Project and has not been adjusted for H616?!?

 

Give it a try...

Thanks a lot for your answer! Hopefully everything will get easier later, armbian team is so Amazing thanks a lot for your work

0
Link to comment
Share on other sites
Awakewithadawn

Awakewithadawn

Posted
Posted
23.10.2021 в 08:42, christian_m сказал:

I had the same issue.

Initially I changed the pre-install script of libc6 and installed it via "dpkg -i".

After that "apt upgrade" continued working.

But then at the end of the update process the uImage in /boot is "updated".

But the Script applies a wrong type to the new uImage.

You can see it on TTL console.

The new one is "Arm64" (?) and he stops booting with it.

If you take the original one from the Installation zip and replace it you will see that boot works again.

Type of this one in the console output is "Arm".

I guess "update script" is comming from a different Project and has not been adjusted for H616?!?

 

Give it a try...

Thank you so much! There is a magic for me!

0
Link to comment
Share on other sites
Jelmer

Jelmer

Posted
Posted

But the essence is true, bullseye for the orangepi zero2 can't be upgraded, even after the libc6 workaround, the orangepi zero2 won't boot after upgrading.

 

So, from the armbian website you can download the supported bullseye image,  Armbian 21.08.1 Bullseye with Linux 4.9.280-sun50iw9, that works fine.

And then after a apt-get update/upgrade, the board won't boot anymore out of the uboot shell. Not sure, but I think it's kernel related.

 

So stock, you'll get this after a update (apt list --upgradable) 

armbian-bsp-cli-orangepizero2/bullseye 21.08.3 arm64 [upgradable from: 21.08.1]
armbian-config/bullseye,bullseye 21.08.3 all [upgradable from: 21.08]
armbian-firmware/bullseye,bullseye 21.08.3 all [upgradable from: 21.08]
armbian-zsh/bullseye,bullseye 21.08.3 all [upgradable from: 21.08]
base-files/stable 11.1+deb11u1 arm64 [upgradable from: 11.1]
libc-bin/stable 2.31-13+deb11u2 arm64 [upgradable from: 2.31-13]
libc-dev-bin/stable 2.31-13+deb11u2 arm64 [upgradable from: 2.31-13]
libc-l10n/stable,stable 2.31-13+deb11u2 all [upgradable from: 2.31-13]
libc6-dev/stable 2.31-13+deb11u2 arm64 [upgradable from: 2.31-13]
libc6/stable 2.31-13+deb11u2 arm64 [upgradable from: 2.31-13]
libgssapi-krb5-2/stable 1.18.3-6+deb11u1 arm64 [upgradable from: 1.18.3-6]
libk5crypto3/stable 1.18.3-6+deb11u1 arm64 [upgradable from: 1.18.3-6]
libkrb5-3/stable 1.18.3-6+deb11u1 arm64 [upgradable from: 1.18.3-6]
libkrb5support0/stable 1.18.3-6+deb11u1 arm64 [upgradable from: 1.18.3-6]
libntfs-3g883/stable 1:2017.3.23AR.3-4+deb11u1 arm64 [upgradable from: 1:2017.3.23AR.3-4]
libpam-modules-bin/stable 1.4.0-9+deb11u1 arm64 [upgradable from: 1.4.0-9]
libpam-modules/stable 1.4.0-9+deb11u1 arm64 [upgradable from: 1.4.0-9]
libpam-runtime/stable,stable 1.4.0-9+deb11u1 all [upgradable from: 1.4.0-9]
libpam0g/stable 1.4.0-9+deb11u1 arm64 [upgradable from: 1.4.0-9]
libperl5.32/stable 5.32.1-4+deb11u2 arm64 [upgradable from: 5.32.1-4]
libssl-dev/stable 1.1.1k-1+deb11u1 arm64 [upgradable from: 1.1.1k-1]
libssl1.1/stable 1.1.1k-1+deb11u1 arm64 [upgradable from: 1.1.1k-1]
linux-libc-dev/bullseye 21.08.2 arm64 [upgradable from: 21.05.8]
locales/stable,stable 2.31-13+deb11u2 all [upgradable from: 2.31-13]
ntfs-3g/stable 1:2017.3.23AR.3-4+deb11u1 arm64 [upgradable from: 1:2017.3.23AR.3-4]
openssl/stable 1.1.1k-1+deb11u1 arm64 [upgradable from: 1.1.1k-1]
perl-base/stable 5.32.1-4+deb11u2 arm64 [upgradable from: 5.32.1-4]
perl-modules-5.32/stable,stable 5.32.1-4+deb11u2 all [upgradable from: 5.32.1-4]
perl/stable 5.32.1-4+deb11u2 arm64 [upgradable from: 5.32.1-4]
rsync/stable 3.2.3-4+deb11u1 arm64 [upgradable from: 3.2.3-4]
tmux/stable 3.1c-1+deb11u1 arm64 [upgradable from: 3.1c-1]
tzdata/stable-updates,stable-updates 2021a-1+deb11u2 all [upgradable from: 2021a-1]

 

And after a upgrade, the boot will halt at this:

  

U-Boot 2018.05-armbian (Aug 28 2021 - 20:00:15 +0200) Xunlong Software

[00.403]CPU:   Allwinner H616
[00.406]Model: Orange Pi Zero 2
I2C:   ready
[00.411]DRAM:  1 GiB
Relocation Offset is: 35ec9000
[00.451]secure enable bit: 0
[00.453]PMU: AXP806
[00.458]CPU=1008 MHz,PLL6=600 Mhz,AHB=200 Mhz, APB1=100Mhz  MBus=400Mhz
[00.640]sunxi overlay merged okqv
[00.643]drv_disp_init
[00.672]__clk_enable: clk is null.
tv_init()950 fetch tv0 err.
[00.678]drv_disp_init finish
[00.680]gic: sec monitor mode
[00.686]flash init start
[00.688]workmode = 0,storage type = 1
[00.691]MMC: 0
[00.693]get mem for descripter OK !

card_caps:0x3000000a
host_caps:0x3000003f
[00.719]sunxi flash init ok
[00.723]Loading Environment from FAT... [00.726]get mem for descripter OK !

** Bad device mmc 1 **
Failed (-5)
[00.741]usb burn from boot
delay time 0
weak:otg_phy_config
[00.755]usb prepare ok
[01.558]overtime
[01.562]do_burn_from_boot usb : no usb exist
[01.566]boot_gui_init:start
card_caps:0x3000000a
host_caps:0x3000003f
190 bytes read in 9 ms (20.5 KiB/s)
Set HDMI disp_mode to 1080p60
190 bytes read in 10 ms (18.6 KiB/s)
Set fb0_width to 1280
Set fb0_height to 720
[01.887]boot_gui_init:finish
[01.889]bmp_name=/boot/boot.bmp
230454 bytes read in 20 ms (11 MiB/s)
[01.923]update dts
Net:   [01.926]No ethernet found.
Hit any key to stop autoboot:  1  0 
no mmc device at slot 1
card_caps:0x3000000a
host_caps:0x3000003f
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
2612 bytes read in 12 ms (211.9 KiB/s)
## Executing script at 43100000
U-boot loaded from SD
Boot script loaded from mmc
190 bytes read in 9 ms (20.5 KiB/s)
6701030 bytes read in 298 ms (21.4 MiB/s)
24127560 bytes read in 1023 ms (22.5 MiB/s)
## Booting kernel from Legacy Image at 41000000 ...
   Image Name:   
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    24127496 Bytes = 23 MiB
   Load Address: 41000000
   Entry Point:  41000000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 43300000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    6700966 Bytes = 6.4 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
No Linux ARM Ramdisk Image
Ramdisk image is corrupt or invalid
SCRIPT FAILED: continuing...
No ethernet found.
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-sunxi
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
No ethernet found.
Config file not found
No ethernet found.
armbian#

 

I know for sure it's not a SD-card or other H/W failure, because it will boot perfectly fine without upgrading, you can see some difference in ramdisk and booting kernel parameters, so just for comparisation, here is one log from a stock image which boots perfect right before a upgrade:

  

[31]HELLO! BOOT0 is starting May 13 2020 14:10:04!
[36]BOOT0 commit : 593cf83
[39]set pll start
[41]periph0 has been enabled
[44]set pll end
[46]unknow PMU
[48]PMU: AXP806
[55]vaild para:1  select dram para0
[58]board init ok
[60]DRAM BOOT DRIVE INFO: V0.52
[63]the chip id is 0x5000
[66]chip id check OK
[68]DRAM_VCC set to 1500 mv
[72]read_calibration error 
[76]read_calibration error 
[79]read_calibration error 
[83]read_calibration error 
[87]read_calibration error 
[91]read_calibration error 
[95]read_calibration error 
[99]read_calibration error 
[102]read_calibration error 
[106]read_calibration error 
[109]retraining final error 
[114][AUTO DEBUG]32bit,1 ranks training success!
[121]DRAM CLK =720 MHZ
[123]DRAM Type =3 (3:DDR3,4:DDR4,7:LPDDR3,8:LPDDR4)
[130]Actual DRAM SIZE =1024 M
[133]DRAM SIZE =1024 MBytes, para1 = 30fa, para2 = 4000000, dram_tpr13 = 6041
[146]DRAM simple test OK.
[148]rtc standby flag is 0x0, super standby flag is 0x0
[153]dram size =1024
[156]*****dram handle ok****
[159]card no is 0
[161]sdcard 0 line count 4
[164][mmc]: mmc driver ver 2019-12-19 10:41
[168][mmc]: sdc0 spd mode error, 2
[171][mmc]: set f_max to 50M, set f_max_ddr to 25M
[176][mmc]: mmc 0 bias 0
[184][mmc]: Wrong media type 0x0
[187][mmc]: ***Try SD card 0***
[197][mmc]: HSSDR52/SDR25 4 bit
[200][mmc]: 50000000 Hz
[202][mmc]: 122240 MB
[204][mmc]: ***SD/MMC 0 init OK!!!***
[303]Loading boot-pkg Succeed(index=0).
[307]Entry_name        = u-boot
[316]Entry_name        = monitor
[320]Entry_name        = dtbo
[323]Entry_name        = dtb
[326]Jump to second Boot.
NOTICE:  BL3-1: v1.0(debug):9fecd83
NOTICE:  BL3-1: Built : 17:08:29, 2020-05-28
NOTICE:  BL3-1 commit: 8
ERROR:   Error initializing runtime service tspd_fast
NOTICE:  BL3-1: Preparing for EL3 exit to normal world
NOTICE:  BL3-1: Next image address = 0x4a000000
NOTICE:  BL3-1: Next image spsr = 0x1d3


U-Boot 2018.05-armbian (Aug 28 2021 - 20:00:15 +0200) Xunlong Software

[00.403]CPU:   Allwinner H616
[00.406]Model: Orange Pi Zero 2
I2C:   ready
[00.411]DRAM:  1 GiB
Relocation Offset is: 35ec9000
[00.451]secure enable bit: 0
[00.454]PMU: AXP806
[00.458]CPU=1008 MHz,PLL6=600 Mhz,AHB=200 Mhz, APB1=100Mhz  MBus=400Mhz
[00.640]sunxi overlay merged okqv
[00.644]drv_disp_init
[00.672]__clk_enable: clk is null.
tv_init()950 fetch tv0 err.
[00.678]drv_disp_init finish
[00.681]gic: sec monitor mode
[00.686]flash init start
[00.688]workmode = 0,storage type = 1
[00.691]MMC: 0
[00.693]get mem for descripter OK !

card_caps:0x3000000a
host_caps:0x3000003f
[00.720]sunxi flash init ok
[00.723]Loading Environment from FAT... [00.726]get mem for descripter OK !

** Bad device mmc 1 **
Failed (-5)
[00.742]usb burn from boot
delay time 0
weak:otg_phy_config
[00.755]usb prepare ok
[01.558]overtime
[01.562]do_burn_from_boot usb : no usb exist
[01.566]boot_gui_init:start
card_caps:0x3000000a
host_caps:0x3000003f
190 bytes read in 10 ms (18.6 KiB/s)
Set HDMI disp_mode to 1080p60
190 bytes read in 10 ms (18.6 KiB/s)
Set fb0_width to 1280
Set fb0_height to 720
[01.887]boot_gui_init:finish
[01.889]bmp_name=/boot/boot.bmp
230454 bytes read in 21 ms (10.5 MiB/s)
[01.923]update dts
Net:   [01.926]No ethernet found.
Hit any key to stop autoboot:  1  0 
no mmc device at slot 1
card_caps:0x3000000a
host_caps:0x3000003f
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
2612 bytes read in 12 ms (211.9 KiB/s)
## Executing script at 43100000
U-boot loaded from SD
Boot script loaded from mmc
190 bytes read in 10 ms (18.6 KiB/s)
6695987 bytes read in 298 ms (21.4 MiB/s)
24127560 bytes read in 1023 ms (22.5 MiB/s)
## Booting kernel from Legacy Image at 41000000 ...
   Image Name:   
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    24127496 Bytes = 23 MiB
   Load Address: 41000000
   Entry Point:  41000000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 43300000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    6695923 Bytes = 6.4 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Ramdisk to 4999d000, end 49fffbf3 ... OK
   reserving fdt memory region: addr=48000000 size=1000000
## Linux machid: 00000000, FDT addr: 7be89580

Starting kernel ...

Loading, please wait...
Starting version 247.3-6
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems
done.
Begin: Will now check root file system ... fsck from util-linux 2.36.1
[/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 
/dev/mmcblk0p1: clean, 40715/8869696 files, 921706/30972928 blocks
done.
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... done.

 

0
Link to comment
Share on other sites
Jelmer

Jelmer

Posted
Posted

So, excuse me for starting another post right after the big one above, but just for clarification, I see this difference:

 

booting before upgrade:

  

## Booting kernel from Legacy Image at 41000000 ...
   Image Name:   
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    24127496 Bytes = 23 MiB
   Load Address: 41000000
   Entry Point:  41000000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 43300000 ...
   Image Name:   uInitrd
Image Type:      ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    6695923 Bytes = 6.4 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
   Loading Ramdisk to 4999d000, end 49fffbf3 ... OK
   reserving fdt memory region: addr=48000000 size=1000000
## Linux machid: 00000000, FDT addr: 7be89580

Starting kernel ...

 

not booting after upgrade:

  

## Booting kernel from Legacy Image at 41000000 ...
   Image Name:   
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    24127496 Bytes = 23 MiB
   Load Address: 41000000
   Entry Point:  41000000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 43300000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    6700966 Bytes = 6.4 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
No Linux ARM Ramdisk Image
Ramdisk image is corrupt or invalid
SCRIPT FAILED: continuing...

 

0
Link to comment
Share on other sites
Jelmer

Jelmer

Posted
Posted

I managed to upgrade to orangepi Zero2 by restoring the old uInitrd after a upgrade, right before rebooting.

 

Don't know why the upgrade proces is converting uInitrd to a AArch64 type while it was a ARM (which is correct) image type.

It happens here in the upgrade proces:

  

Processing triggers for initramfs-tools (0.140) ...
update-initramfs: Generating /boot/initrd.img-4.9.280-sun50iw9
update-initramfs: Converting to u-boot format

 

I'm all good now, but don't know if my approach was the correct one ;)

0
Link to comment
Share on other sites
Igor

Igor

Posted
Posted
On 11/12/2021 at 3:22 PM, Jelmer said:

Don't know why the upgrade proces is converting uInitrd to a AArch64 type while it was a ARM (which is correct) image type.


This is probably the problem, yes. Just need to figure out why this happens ... probably you started with some beta builds, which don't have (INITRD_ARCH=arm) or you are using some Armbian based OS that is missing this info?

  

root@orangepizero2:/etc/initramfs/post-update.d# more 99-uboot 
#!/bin/sh

. /etc/armbian-release

echo "update-initramfs: Converting to u-boot format" >&2
tempname="/boot/uInitrd-$1"
mkimage -A $INITRD_ARCH -O linux -T ramdisk -C gzip -n uInitrd -d $2 $tempname >
 /dev/null

ln -sf $(basename $tempname) /boot/uInitrd > /dev/null 2>&1 || mv $tempname /boo
t/uInitrd
exit 0

  

cat /etc/armbian-release | grep INITRD_ARCH
INITRD_ARCH=arm

 

But I couldn't reproduce this problem. What I did?

- download legacy buster image

- change apt to beta where newer kernels are

 

apt update / apt upgrade

 

0
Link to comment
Share on other sites
Igor

Igor

Posted
Posted
11 hours ago, Hervé Changue said:

dont Know if libc6 problem still present but probably still here


Yes it is.

 

On 10/15/2021 at 12:04 AM, tparys said:

Also looks like the patch level is being deliberately applied via build system.


Another workaround would be to remove those files?
 

Spoiler 
patch-4.9.254-255.patch
patch-4.9.255-256.patch
patch-4.9.256-257.patch
patch-4.9.257-258.patch
patch-4.9.258-259.patch
patch-4.9.259-260.patch
patch-4.9.260-261.patch
patch-4.9.261-262.patch
patch-4.9.262-263.patch
patch-4.9.263-264.patch
patch-4.9.264-265.patch
patch-4.9.265-266.patch
patch-4.9.266-267.patch
patch-4.9.267-268.patch
patch-4.9.268-269.patch
patch-4.9.269-270.patch
patch-4.9.270-271.patch
patch-4.9.271-272.patch
patch-4.9.272-273.patch
patch-4.9.273-274.patch
patch-4.9.274-275.patch
patch-4.9.275-276.patch
patch-4.9.276-277.patch
patch-4.9.277-278.patch
patch-4.9.278-279.patch
patch-4.9.279-280.patch
patch-4.9.280-281.patch
patch-4.9.281-282.patch
patch-4.9.282-283.patch
patch-4.9.283-284.patch
patch-4.9.284-285.patch
patch-4.9.285-286.patch
patch-4.9.286-287.patch
patch-4.9.287-288.patch
patch-4.9.288-289.patch

 


 

0
Link to comment
Share on other sites
Jelmer

Jelmer

Posted
Posted

Hi Igor,

 

I downloaded the legacy buster image for  the opz2 on the armbian website, I didn't edit anything yet: 

root@orangepizero2:/etc/initramfs/post-update.d# more 99-uboot
#!/bin/sh

. /etc/armbian-release

echo "update-initramfs: Converting to u-boot format" >&2
tempname="/boot/uInitrd-$1"
mkimage -A $INITRD_ARCH -O linux -T ramdisk -C gzip -n uInitrd -d $2 $tempname >
 /dev/null

ln -sf $(basename $tempname) /boot/uInitrd > /dev/null 2>&1 || mv $tempname /boo
t/uInitrd
exit 0

root@orangepizero2:/etc/initramfs/post-update.d# cat /etc/armbian-release | grep INITRD_ARCH
INITRD_ARCH=arm64

 

I think arm64 is not correct for the opz2, should be arm (without 64) right?

 

I now tested your approach and just switched to Nightly to test the apt update/upgrade.

The outcome is:

 

no errors (so no libc hack needed on buster, but is on bullseye), but boot fails for exactly the same reason.

So summary, download official armbian release for opz2, doesn't matter if it is bullseye or buster, alpha or beta, a update/upgrade wil break your boot.

 

So there has to be some changes before a update/upgrade.

 

I am now running on buster nightly, because I manually recreated uInitrd with before reboot.

mkimage -A arm -O linux -T ramdisk -C gzip -n uInitrd -d /boot/initrd.img-4.9.289-sun50iw9 /boot/uInitrd-4.9.289-sun50iw9

 

output of armbian-release is unedited: 

root@orangepizero2:# cat /etc/armbian-release | grep ARCH
ARCH=arm64
INITRD_ARCH=arm64

 

mkimage -A arm64 will make an image type AArch64, which doesn't work for some reason on the opz2, it needs ARM.

0
Link to comment
Share on other sites
Igor

Igor

Posted
Posted
11 hours ago, Jelmer said:

I think arm64 is not correct for the opz2, should be arm (without 64) right?


Correct. Now we need to find out why this was not set right. For the libc, I'll simply drop patches and it will be alright.

0
Link to comment
Share on other sites
Jelmer

Jelmer

Posted
Posted
2 hours ago, Igor said:


Correct. Now we need to find out why this was not set right. For the libc, I'll simply drop patches and it will be alright.

 

I think it went like this.

Downloaded buster image from armbian website, everything is ok.

update/upgrade and the first thing that changes is INITRD_ARCH=arm64 in armbian-release, causing troubles.

 

Some manual tweaking got me booted up again, then I switched to nightly to see if that also causes things to break and, it didn't. It actually changed the INITRD_ARCH=arm to the right value again.

 

So it is something in that first update/upgrade of Buster, which didn't caused me any trouble with libc this time, didn't need to apply the 'hack'.

 

I abandoned Bullseye because I just chose to run Buster again, now I'm running  Armbian 21.11.0-trunk.58 Buster with Linux 4.9.289-sun50iw9 without any issues. dmesg looks ok-ish (sunxi-mmc, zswap and wifi ini path errors), but that is for another story.

0
Link to comment
Share on other sites
-RootSar-

-RootSar-

Posted
Posted
14.10.2021 в 07:44, Hervé Changue сказал:

Armbian monitor http://ix.io/3BGM

 

Hello updating supported bullseye 4.9 orange pi zero 2 dont work, problem with libc6 because of kernel version. I tried hacking uname -r update was successful but wont boot anymore.

 

I use clean install with clean image from website :

 

dpkg: error processing archive /var/cache/apt/archives/libc6_2.31-13+deb11u2_arm64.deb (--unpack):

 new libc6:arm64 package pre-installation script subprocess returned error exit status 1

Errors were encountered while processing:

 /var/cache/apt/archives/libc6_2.31-13+deb11u2_arm64.deb

E: Sub-process /usr/bin/dpkg returned an error code (1)

 

 

apt --fix-broken install give me :

 

ERROR: Your kernel version indicates a revision number
of 255 or greater.  Glibc has a number of built in
assumptions that this revision number is less than 255.
If you\'ve built your own kernel, please make sure that any
custom version numbers are appended to the upstreamkernel number with a dash or some other delimiter.

 

Thanks for your work

Change temporarily  4.9.*-sun50iw9 to 4.9.255
$uname -r
4.9.255-sun50iw9

1) mv /bin/uname /bin/uname.orig
2) nano /bin/uname


#!/bin/sh
echo Uname 4.9.255
/bin/uname.orig

 

3) chmod 755 /bin/uname

4) apt full-upgrade

5) rm -r /bin/uname

6) mv /bin/uname.orig /bin/uname

7) reboot

 

It helped me^_^

0
Link to comment
Share on other sites
This thread is quite old. Please consider starting a new thread rather than reviving this one.

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
Reply to this topic...

×   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
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept