Hervé Changue Posted October 14, 2021 Share Posted October 14, 2021 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 Quote Link to comment Share on other sites More sharing options...
tparys Posted October 14, 2021 Share Posted October 14, 2021 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 Quote Link to comment Share on other sites More sharing options...
Hervé Changue Posted October 15, 2021 Author Share Posted October 15, 2021 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 Quote Link to comment Share on other sites More sharing options...
Werner Posted October 15, 2021 Share Posted October 15, 2021 Best way to debug boot issues is using a serial adapter to get an idea what is happening inside. You cannot rely on HDMI output if available at all. 0 Quote Link to comment Share on other sites More sharing options...
Hervé Changue Posted October 15, 2021 Author Share Posted October 15, 2021 Hello i tried again to update to Armbian 21.08.3 bypassing libc6 bug but when i reboot it actually stay on initializing bootloader. Seems Like we cant update anymore the supported image 0 Quote Link to comment Share on other sites More sharing options...
tparys Posted October 16, 2021 Share Posted October 16, 2021 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 Quote Link to comment Share on other sites More sharing options...
christian_m Posted October 23, 2021 Share Posted October 23, 2021 (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 October 23, 2021 by christian_m 1 Quote Link to comment Share on other sites More sharing options...
Hervé Changue Posted October 28, 2021 Author Share Posted October 28, 2021 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 Quote Link to comment Share on other sites More sharing options...
Awakewithadawn Posted November 11, 2021 Share Posted November 11, 2021 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 Quote Link to comment Share on other sites More sharing options...
Jelmer Posted November 11, 2021 Share Posted November 11, 2021 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 Quote Link to comment Share on other sites More sharing options...
Jelmer Posted November 11, 2021 Share Posted November 11, 2021 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 Quote Link to comment Share on other sites More sharing options...
Jelmer Posted November 12, 2021 Share Posted November 12, 2021 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 Quote Link to comment Share on other sites More sharing options...
user131121 Posted November 13, 2021 Share Posted November 13, 2021 update/upgrade not worked, error and crash , what way to solution? 0 Quote Link to comment Share on other sites More sharing options...
Werner Posted November 13, 2021 Share Posted November 13, 2021 Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed. 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted November 13, 2021 Share Posted November 13, 2021 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 Quote Link to comment Share on other sites More sharing options...
Hervé Changue Posted November 13, 2021 Author Share Posted November 13, 2021 Hello Igor I could always reproduce the problem with last supported bullseye on website -download bullseye supported -dont change kernel -apt update & apt upgrade (dont Know if libc6 problem still present but probably still here) Thanks 0 Quote Link to comment Share on other sites More sharing options...
Igor Posted November 14, 2021 Share Posted November 14, 2021 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 Quote Link to comment Share on other sites More sharing options...
Jelmer Posted November 15, 2021 Share Posted November 15, 2021 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 Quote Link to comment Share on other sites More sharing options...
Igor Posted November 15, 2021 Share Posted November 15, 2021 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 Quote Link to comment Share on other sites More sharing options...
Jelmer Posted November 16, 2021 Share Posted November 16, 2021 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 Quote Link to comment Share on other sites More sharing options...
3actor Posted November 23, 2021 Share Posted November 23, 2021 i have same problem http://ix.io/3FTX how to fix this? 0 Quote Link to comment Share on other sites More sharing options...
-RootSar- Posted November 23, 2021 Share Posted November 23, 2021 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 Quote Link to comment Share on other sites More sharing options...
-RootSar- Posted November 23, 2021 Share Posted November 23, 2021 (edited) By the way, the kernel update came, 4.9.255-sun50iw9 and still libc6 does not want to be installed Edited November 23, 2021 by -RootSar- 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.