belegdol Posted January 22, 2022 Posted January 22, 2022 I tried updating my kernel to self-built 5.4.173 as usual. I got some errors during installation due to low space on /boot, but after removing leftovers of 5.4.168 the installation worked as expected. Something went wrong though, as my HC1 no longer boots. This is shown via UART: Quote U-Boot 2017.05-armbian (Oct 13 2020 - 18:57:02 +0200) for ODROID-XU4 CPU: Exynos5422 @ 800 MHz Model: Odroid XU4 based on EXYNOS5422 Board: Odroid XU4 based on EXYNOS5422 Type: xu4 DRAM: 2 GiB MMC: EXYNOS DWMMC: 0, EXYNOS DWMMC: 1 MMC Device 0 ( SD ): 14.8 GiB Card did not respond to voltage select! mmc_init: -95, time 12 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: No ethernet found. Press quickly 'Enter' twice to stop autoboot: 0 12489 bytes read in 16 ms (761.7 KiB/s) ## Executing script at 43e00000 ** File not found /boot/armbianEnv.txt ** ** Unrecognized filesystem type ** 64 bytes read in 13 ms (3.9 KiB/s) ** File not found /boot/zImage ** ** Unrecognized filesystem type ** 7340760 bytes read in 734 ms (9.5 MiB/s) ** File not found /boot/uInitrd ** ** Unrecognized filesystem type ** 11220072 bytes read in 8034 ms (1.3 MiB/s) ** File not found /boot/.next ** ** Unrecognized filesystem type ** 0 bytes read in 8 ms (0 Bytes/s) Found mainline kernel configuration ** File not found /boot/dtb/exynos5422-odroidhc1.dtb ** ** Unrecognized filesystem type ** ** File not found dtb/exynos5422-odroidhc1.dtb ** libfdt fdt_check_header(): FDT_ERR_BADMAGIC No FDT memory address configured. Please configure the FDT address via "fdt addr <address>" command. Aborting! Kernel image @ 0x40008000 [ 0x000000 - 0x7002d8 ] ## Loading init Ramdisk from Legacy Image at 42000000 ... Image Name: uInitrd Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 11220008 Bytes = 10.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ERROR: Did not find a cmdline Flattened Device Tree Could not find a valid device tree ** File not found /boot/boot.ini ** ## Executing script at 43e00000 ** File not found /boot.scr ** ## Executing script at 43e00000 Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** ## Executing script at 43e00000 Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** ## Executing script at 43e00000 Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** ## Executing script at 43e00000 mmc_init: -110, time 121 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... starting USB... USB0: USB EHCI 1.00 USB1: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.00 USB2: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 1 for devices... cannot reset port 1!? 1 USB Device(s) found scanning bus 2 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found USB device 0: unknown device Waiting for Ethernet connection... done. BOOTP broadcast 1 All the files seem to be on the SD card: $ ls -l insgesamt 32447 -rw-r--r--. 1 root root 64 8. Jan 16:27 armbianEnv.txt -rw-r--r--. 1 root root 0 6. Sep 2019 armbianEnv.txt.out -rw-r--r--. 1 root root 1536 29. Mai 2018 armbian_first_run.txt.template -rw-r--r--. 1 root root 38518 29. Mai 2018 boot.bmp -rw-r--r--. 1 root root 4882 29. Mai 2018 boot-desktop.png -rw-r--r--. 1 root root 12489 16. Jan 2021 boot.ini -rw-r--r--. 1 root root 0 25. Jun 2019 boot.ini.out -rw-r--r--. 1 root root 169645 22. Jan 10:57 config-5.4.173-odroidxu4 drwxr-xr-x. 3 root root 3072 22. Jan 15:34 dtb-5.4.173-odroidxu4 -rw-r--r--. 1 root root 11220008 22. Jan 15:23 initrd.img-5.4.173-odroidxu4 drwx------. 2 root root 12288 29. Mai 2018 lost+found -rw-r--r--. 1 root root 3194528 22. Jan 10:57 System.map-5.4.173-odroidxu4 lrwxrwxrwx. 1 root root 25 22. Jan 15:23 uInitrd -> uInitrd-5.4.173-odroidxu4 -rw-r--r--. 1 root root 11220072 22. Jan 15:23 uInitrd-5.4.173-odroidxu4 -rwxr-xr-x. 1 root root 7340760 22. Jan 10:57 vmlinuz-5.4.173-odroidxu4 lrwxrwxrwx. 1 root root 25 22. Jan 15:34 zImage -> vmlinuz-5.4.173-odroidxu4 Any ideas where to look? 0 Quote
belegdol Posted January 22, 2022 Author Posted January 22, 2022 Turns out the dtb symlink to dtb-5.4.173-odroidxu4 was missing. In case this happened due to lack of empty space: isn't 58 MB a bit low for /boot partition in 2022? Is this still the default, or am I just carrying it back from OMV 4? 0 Quote
Igor Posted January 22, 2022 Posted January 22, 2022 2 hours ago, belegdol said: Turns out the dtb symlink to dtb-5.4.173-odroidxu4 was missing. @going Any relation with our changes in packaging? 0 Quote
going Posted January 23, 2022 Posted January 23, 2022 @belegdol I don't use an odroid, but if you write down which image was originally recorded on the memory card and how the update took place, maybe I can fix it for a future release. And of course yes, 58 megabytes to accommodate the boot partition is not enough. 1 Quote
belegdol Posted January 23, 2022 Author Posted January 23, 2022 If I recall correctly, I originally installed an OMV 4 image with balena etcher which I then upgraded to 5 and 6 with omv-release-upgrade. In OMV 4 timeframe OMV would provide their own images. As far as the kernel updates, I install them with $ sudo apt install ./linux-{dtb,image}-current-odroidxu4_21.08.6.3_armhf.deb As I tried to install 5.4.173, I got out-of-space errors because there were 5.4.168 leftovers in addition to the then-installed 5.4.170 in /boot. I also got some errors about /var/lib/initramfs-tools not being available, which I fixed with mkdir. 0 Quote
Igor Posted January 23, 2022 Posted January 23, 2022 4 minutes ago, belegdol said: If I recall correctly, I originally installed an OMV 4 image with balena etcher which I then upgraded to 5 and 6 with omv-release-upgrade. In OMV 4 timeframe OMV would provide their own images. Some very old builds in a combination with OMV ... It's amazing that it worked this far 0 Quote
belegdol Posted January 23, 2022 Author Posted January 23, 2022 Well, it was not without hiccups, until this one most of the issues were minor. The supported alternative would be to install armbian fresh, add OMV on top of it and configure everything from scratch, correct? 0 Quote
Igor Posted January 23, 2022 Posted January 23, 2022 57 minutes ago, belegdol said: Well, it was not without hiccups, until this one most of the issues were minor. The supported alternative would be to install armbian fresh, add OMV on top of it and configure everything from scratch, correct? That would be the best way, yes. (or even without OMV, if you can live without) 0 Quote
going Posted January 23, 2022 Posted January 23, 2022 16 часов назад, Igor сказал: @going Any relation with our changes in packaging? I think the problem here is that the memory chip has broken sectors\cells and the file system is mounted read-only at some point of overwriting. This is the first thing I check in this case. @belegdol Check the /boot partition with the fsck utility. ` ls /usr/sbin/ | grep fsck ` 0 Quote
belegdol Posted January 23, 2022 Author Posted January 23, 2022 Quote julas@odroidxu4:~$ sudo umount /boot julas@odroidxu4:~$ sudo fsck /boot fsck from util-linux 2.36.1 e2fsck 1.46.2 (28-Feb-2021) /dev/mmcblk0p1: clean, 73/16384 files, 42257/65536 blocks 0 Quote
going Posted January 23, 2022 Posted January 23, 2022 6 часов назад, belegdol сказал: As far as the kernel updates, I install them with $ sudo apt install ./linux-{dtb,image}-current-odroidxu4_21.08.6.3_armhf.deb As I tried to install 5.4.173, I got out-of-space errors because there were 5.4.168 leftovers in addition to the then-installed 5.4.170 in /boot. I also got some errors about /var/lib/initramfs-tools not being available, which I fixed with mkdir. If I understand correctly, have you installed packages from a local folder? Did you build these packages yourself and use the armbian build system? If yes, then you need to look inside the kernel package. What scripts are there? And try to build a fresh kernel and then compare the scripts from the fresh kernel and the one you installed. Unfortunately, I do not see many details and I find it difficult to give any advice. 1 Quote
belegdol Posted January 23, 2022 Author Posted January 23, 2022 I am using armbian build system: I git pull the master branch, edit the VERSION file, put the latest patches in patch/kernel/archive/odroidxu4-5.4/ and then run: $ ./compile.sh BOARD=odroidxu4 BRANCH=current KERNEL_ONLY=yes KERNEL_CONFIGURE=no USE_CCACHE=no KEEP_KERNEL_CONFIG=no I will have a closer look what happens once 5.4.174 is out. My suspicion is that it was either the missing /var/lib/initramfs-tools or the low free space which caused the update to abort in the middle, leaving the system in an unusable state. 31 minutes ago, going said: Unfortunately, I do not see many details and I find it difficult to give any advice. This is OK, I think my system is working now and I know what to do in case this happens again or how to check the state after next kernel update to make sure it doesn't. Thank you for the advice so far. 0 Quote
going Posted January 26, 2022 Posted January 26, 2022 23.01.2022 в 18:57, belegdol сказал: I am using armbian build system: I git pull the master branch, edit the VERSION file, put the latest patches in patch/kernel/archive/odroidxu4-5.4/ and then run: What is your goal when you edit the VERSION file? Or, what do you write there? And most importantly, what do you actually want, what needs to be implemented? Today, the contents of this file are assigned as a version to several packages at once, which from my point of view does not look like correct behavior. That's the reason I want to discuss this. 0 Quote
belegdol Posted January 26, 2022 Author Posted January 26, 2022 I edit it so that I get a version of the kernel higher than what is in the repos, yet not too high so that if an update from armbian comes it gets recognised as an update for my build. For the most recent kernel, I entered 21.08.6.3. 0 Quote
going Posted January 26, 2022 Posted January 26, 2022 58 минут назад, belegdol сказал: I edit it so that I get a version of the kernel higher than what is in the repos, yet not too high so that if an update from armbian comes it gets recognised as an update for my build. For the most recent kernel, I entered 21.08.6.3. @Igor That means I'm not alone. I want to fix it. So that there would be no torment in the future and that it would be possible to prescribe dependencies on a specific kernel version for libraries that need it. 0 Quote
Igor Posted January 26, 2022 Posted January 26, 2022 35 minutes ago, going said: That means I'm not alone. I want to fix it. So that there would be no torment in the future and that it would be possible to prescribe dependencies on a specific kernel version for libraries that need it. We need to make a bugfix builds, so we can go over those versions easily. Some other solution is needed. 0 Quote
going Posted January 26, 2022 Posted January 26, 2022 2 часа назад, Igor сказал: We need to make a bugfix builds, so we can go over those versions easily. Some other solution is needed. It seems to me that I did not understand your arguments. The user built the kernel with version =N. The user added several fixes for the driver. And assembled the core again. The version must be version=N+1. Then he discovered and corrected the error. Reassembled the core. Version=N+2 ... This should be an accessible mechanism for each package on the user side. That is, changing the version only for one loader or one kernel is very correct. During the build of a release or test, armbian can set all these versions to one value, as it did before. 0 Quote
Igor Posted January 27, 2022 Posted January 27, 2022 11 hours ago, going said: The user built the kernel with version =N. The user added several fixes for the driver. And assembled the core again. The version must be version=N+1. Then he discovered and corrected the error. Reassembled the core. Version=N+2 ... This should be an accessible mechanism for each package on the user side. That is, changing the version only for one loader or one kernel is very correct. The problem is we are releasing packages with release number N. Then someone creates its own kernel and put it on a board. Until his number is bigger than ours, his kernel won't be overwritten, right? Now there are many ways how to solve this problem: - put apt hold mark on a kernel package (must be done by user) - we implement some mechanism this is done by default if not our official kernel used ... 0 Quote
belegdol Posted February 5, 2022 Author Posted February 5, 2022 Looks like there are some issues cleaning up the old kernels. I used `apt reinstall` instead of `apt install` by accident but nevertheless: $ sudo df -h Filesystem Size Used Avail Use% Mounted on udev 926M 0 926M 0% /dev tmpfs 200M 4.0M 196M 2% /run /dev/mmcblk0p2 15G 1.8G 12G 13% / tmpfs 996M 0 996M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 996M 8.0K 996M 1% /tmp /dev/sda1 458G 277G 182G 61% /srv/dev-disk-by-label-omv armbian-ramlog 50M 6.9M 44M 14% /var/log /dev/mmcblk0p1 58M 36M 21M 64% /boot tmpfs 200M 0 200M 0% /run/user/1000 julas@odroidxu4:~$ sudo ls -lh /boot total 32M -rw-r--r-- 1 root root 64 Jan 22 16:47 armbianEnv.txt -rw-r--r-- 1 root root 0 Sep 6 2019 armbianEnv.txt.out -rw-r--r-- 1 root root 1.5K May 29 2018 armbian_first_run.txt.template -rw-r--r-- 1 root root 38K May 29 2018 boot.bmp -rw-r--r-- 1 root root 4.8K May 29 2018 boot-desktop.png -rw-r--r-- 1 root root 13K Jan 16 2021 boot.ini -rw-r--r-- 1 root root 0 Jun 25 2019 boot.ini.out -rw-r--r-- 1 root root 166K Jan 22 10:57 config-5.4.173-odroidxu4 lrwxrwxrwx 1 root root 21 Jan 22 16:51 dtb -> dtb-5.4.173-odroidxu4 drwxr-xr-x 3 root root 3.0K Jan 22 15:34 dtb-5.4.173-odroidxu4 -rw-r--r-- 1 root root 11M Jan 30 13:28 initrd.img-5.4.173-odroidxu4 drwx------ 2 root root 12K May 29 2018 lost+found -rw-r--r-- 1 root root 3.1M Jan 22 10:57 System.map-5.4.173-odroidxu4 lrwxrwxrwx 1 root root 25 Jan 30 13:28 uInitrd -> uInitrd-5.4.173-odroidxu4 -rw-r--r-- 1 root root 11M Jan 30 13:28 uInitrd-5.4.173-odroidxu4 -rwxr-xr-x 1 root root 7.1M Jan 22 10:57 vmlinuz-5.4.173-odroidxu4 lrwxrwxrwx 1 root root 25 Jan 22 15:34 zImage -> vmlinuz-5.4.173-odroidxu4 julas@odroidxu4:~$ sudo apt reinstall ./linux-{dtb,image}-current-odroidxu4_21.08.8.1_armhf.deb Reading package lists... Done Building dependency tree... Done Reading state information... Done Note, selecting 'linux-dtb-current-odroidxu4' instead of './linux-dtb-current-odroidxu4_21.08.8.1_armhf.deb' Note, selecting 'linux-image-current-odroidxu4' instead of './linux-image-current-odroidxu4_21.08.8.1_armhf.deb' The following packages will be upgraded: linux-dtb-current-odroidxu4 linux-image-current-odroidxu4 2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/30.4 MB of archives. After this operation, 15.4 kB of additional disk space will be used. Get:1 /home/julas/linux-dtb-current-odroidxu4_21.08.8.1_armhf.deb linux-dtb-current-odroidxu4 armhf 21.08.8.1 [120 kB] Get:2 /home/julas/linux-image-current-odroidxu4_21.08.8.1_armhf.deb linux-image-current-odroidxu4 armhf 21.08.8.1 [30.3 MB] (Reading database ... 48781 files and directories currently installed.) Preparing to unpack .../linux-dtb-current-odroidxu4_21.08.8.1_armhf.deb ... Unpacking linux-dtb-current-odroidxu4 (21.08.8.1) over (21.08.6.3) ... Preparing to unpack .../linux-image-current-odroidxu4_21.08.8.1_armhf.deb ... Unpacking linux-image-current-odroidxu4 (21.08.8.1) over (21.08.6.3) ... Setting up linux-image-current-odroidxu4 (21.08.8.1) ... update-initramfs: Generating /boot/initrd.img-5.4.176-odroidxu4 W: Possible missing firmware /lib/firmware/xc3028L-v36.fw for built-in driver tuner_xc2028 W: Possible missing firmware /lib/firmware/xc3028-v27.fw for built-in driver tuner_xc2028 W: Possible missing firmware /lib/firmware/dvb-fe-xc5000c-4.1.30.7.fw for built-in driver xc5000 W: Possible missing firmware /lib/firmware/dvb-fe-xc4000-1.4.fw for built-in driver xc4000 W: Possible missing firmware /lib/firmware/dvb-fe-xc4000-1.4.1.fw for built-in driver xc4000 update-initramfs: Converting to u-boot format Setting up linux-dtb-current-odroidxu4 (21.08.8.1) ... julas@odroidxu4:~$ sudo df -h Filesystem Size Used Avail Use% Mounted on udev 926M 0 926M 0% /dev tmpfs 200M 4.0M 196M 2% /run /dev/mmcblk0p2 15G 1.8G 12G 14% / tmpfs 996M 0 996M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 996M 8.0K 996M 1% /tmp /dev/sda1 458G 277G 182G 61% /srv/dev-disk-by-label-omv armbian-ramlog 50M 6.9M 44M 14% /var/log /dev/mmcblk0p1 58M 57M 0 100% /boot tmpfs 200M 0 200M 0% /run/user/1000 julas@odroidxu4:~$ sudo ls -lh /boot total 54M -rw-r--r-- 1 root root 64 Jan 22 16:47 armbianEnv.txt -rw-r--r-- 1 root root 0 Sep 6 2019 armbianEnv.txt.out -rw-r--r-- 1 root root 1.5K May 29 2018 armbian_first_run.txt.template -rw-r--r-- 1 root root 38K May 29 2018 boot.bmp -rw-r--r-- 1 root root 4.8K May 29 2018 boot-desktop.png -rw-r--r-- 1 root root 13K Jan 16 2021 boot.ini -rw-r--r-- 1 root root 0 Jun 25 2019 boot.ini.out -rw-r--r-- 1 root root 166K Feb 5 11:18 config-5.4.176-odroidxu4 lrwxrwxrwx 1 root root 21 Feb 5 11:23 dtb -> dtb-5.4.176-odroidxu4 drwxr-xr-x 3 root root 3.0K Feb 5 11:21 dtb-5.4.176-odroidxu4 -rw-r--r-- 1 root root 11M Jan 30 13:28 initrd.img-5.4.173-odroidxu4 -rw-r--r-- 1 root root 11M Feb 5 11:23 initrd.img-5.4.176-odroidxu4 drwx------ 2 root root 12K May 29 2018 lost+found -rw-r--r-- 1 root root 3.1M Feb 5 11:18 System.map-5.4.176-odroidxu4 lrwxrwxrwx 1 root root 25 Feb 5 11:23 uInitrd -> uInitrd-5.4.176-odroidxu4 -rw-r--r-- 1 root root 11M Jan 30 13:28 uInitrd-5.4.173-odroidxu4 -rw-r--r-- 1 root root 11M Feb 5 11:23 uInitrd-5.4.176-odroidxu4 -rwxr-xr-x 1 root root 7.1M Feb 5 11:18 vmlinuz-5.4.176-odroidxu4 lrwxrwxrwx 1 root root 25 Feb 5 11:23 zImage -> vmlinuz-5.4.176-odroidxu4 DTB link has been created successfully, but the old initrd files are still there and the /boot partition is full. I am assuming that if I install one more kernel without removing the kernels manually, I am going to end up in the same situation as before. The kernel was build from git dc9722b5354ea21b927a66044c244f8aae2e6fcb with VERSION edited to 21.08.8.1. 0 Quote
belegdol Posted February 5, 2022 Author Posted February 5, 2022 `apt reinstall` vs `apt install` appears to make no difference: $ sudo ls -lh /boot total 54M -rw-r--r-- 1 root root 64 Feb 5 11:41 armbianEnv.txt -rw-r--r-- 1 root root 0 Sep 6 2019 armbianEnv.txt.out -rw-r--r-- 1 root root 1.5K May 29 2018 armbian_first_run.txt.template -rw-r--r-- 1 root root 38K May 29 2018 boot.bmp -rw-r--r-- 1 root root 4.8K May 29 2018 boot-desktop.png -rw-r--r-- 1 root root 13K Jan 16 2021 boot.ini -rw-r--r-- 1 root root 0 Jun 25 2019 boot.ini.out -rw-r--r-- 1 root root 166K Feb 5 15:38 config-5.4.177-odroidxu4 lrwxrwxrwx 1 root root 21 Feb 5 15:42 dtb -> dtb-5.4.177-odroidxu4 drwxr-xr-x 3 root root 3.0K Feb 5 15:41 dtb-5.4.177-odroidxu4 -rw-r--r-- 1 root root 11M Feb 5 11:23 initrd.img-5.4.176-odroidxu4 -rw-r--r-- 1 root root 11M Feb 5 15:42 initrd.img-5.4.177-odroidxu4 drwx------ 2 root root 12K May 29 2018 lost+found -rw-r--r-- 1 root root 3.1M Feb 5 15:38 System.map-5.4.177-odroidxu4 lrwxrwxrwx 1 root root 25 Feb 5 15:42 uInitrd -> uInitrd-5.4.177-odroidxu4 -rw-r--r-- 1 root root 11M Feb 5 11:23 uInitrd-5.4.176-odroidxu4 -rw-r--r-- 1 root root 11M Feb 5 15:42 uInitrd-5.4.177-odroidxu4 -rwxr-xr-x 1 root root 7.1M Feb 5 15:38 vmlinuz-5.4.177-odroidxu4 lrwxrwxrwx 1 root root 25 Feb 5 15:42 zImage -> vmlinuz-5.4.177-odroidxu4 0 Quote
going Posted February 6, 2022 Posted February 6, 2022 05.02.2022 в 13:27, belegdol сказал: julas@odroidxu4:~$ sudo df -h Filesystem Size Used Avail Use% Mounted on udev 926M 0 926M 0% /dev tmpfs 200M 4.0M 196M 2% /run /dev/mmcblk0p2 15G 1.8G 12G 14% / tmpfs 996M 0 996M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 996M 8.0K 996M 1% /tmp /dev/sda1 458G 277G 182G 61% /srv/dev-disk-by-label-omv armbian-ramlog 50M 6.9M 44M 14% /var/log /dev/mmcblk0p1 58M 57M 0 100% /boot tmpfs 200M 0 200M 0% /run/user/1000 /dev/mmcblk0p1 58M 57M 0 100% /boot Yes! 100% full. I have an assumption that the key in this situation is: 23.01.2022 в 12:11, belegdol сказал: If I recall correctly, I originally installed an OMV 4 image with balena etcher which I then upgraded to 5 and 6 with omv-release-upgrade. The armbian image contains its own original rules for updating the kernel. Two options: Manually adjust in your system to this: https://github.com/armbian/build/tree/master/packages/bsp/common/etc Or use the armbian image. 0 Quote
belegdol Posted February 6, 2022 Author Posted February 6, 2022 I went through the files and all of them are identical to the ones in my install. 0 Quote
going Posted February 6, 2022 Posted February 6, 2022 1 час назад, belegdol сказал: I went through the files and all of them are identical to the ones in my install. does this file exist? https://github.com/armbian/build/blob/master/packages/bsp/common/etc/kernel/preinst.d/initramfs-cleanup in path /etc/kernel/preinst.d/initramfs-cleanup 0 Quote
belegdol Posted February 6, 2022 Author Posted February 6, 2022 $ sudo cat /etc/kernel/preinst.d/initramfs-cleanup #!/bin/sh version="$1" [ -x /usr/sbin/update-initramfs ] || exit 0 # passing the kernel version is required if [ -z "$version" ]; then echo >&2 "W: initramfs-tools: ${DPKG_MAINTSCRIPT_PACKAGE:-kernel package} did not pass a version number" exit 0 fi # avoid running multiple times if [ -n "$DEB_MAINT_PARAMS" ]; then eval set -- "$DEB_MAINT_PARAMS" if [ -z "$1" ] || [ "$1" != "upgrade" ]; then exit 0 fi fi STATEDIR=/var/lib/initramfs-tools version_list="$(ls -1 "$STATEDIR" | linux-version sort --reverse)" for v in $version_list; do if ! linux-version compare $v eq $version; then # try to delete delete old initrd images via update-initramfs INITRAMFS_TOOLS_KERNEL_HOOK=y update-initramfs -d -k $v 2>/dev/null # delete unused state files find $STATEDIR -type f ! -name "$version" -printf "Removing obsolete file %f\n" -delete # delete unused initrd images find /boot -name "initrd.img*" -o -name "uInitrd-*" ! -name "*$version" -printf "Removing obsolete file %f\n" -delete fi done exit 0 0 Quote
going Posted February 7, 2022 Posted February 7, 2022 This issue requires additional attention. I'll get to it in a few days. I have questions. They most likely have nothing to do with the described problem. But please tell me which file systems are on the disks? /dev/mmcblk0p1 /dev/mmcblk0p2 /dev/sda1 0 Quote
belegdol Posted February 7, 2022 Author Posted February 7, 2022 /dev/mmcblk0p1 is ext4, /dev/mmcblk0p2 is btrfs and /dev/sda1 ext4. 0 Quote
going Posted February 22, 2022 Posted February 22, 2022 @belegdol I repeated the process of creating packages and images for your board, including creating a separate partition for the /boot folder. But the check showed that the problem you described is only a small part of the problems that I found and they are common to all. 06.02.2022 в 20:46, going сказал: does this file exist? https://github.com/armbian/build/blob/master/packages/bsp/common/etc/kernel/preinst.d/initramfs-cleanup in path /etc/kernel/preinst.d/initramfs-cleanup This script was last modified: git log -- packages/bsp/common/etc/kernel/preinst.d/initramfs-cleanup commit 2c0115d780816528a7b6bff2c8df2ba2ce0621a5 Author: zador-blood-stained <zador-blood-stained@users.noreply.github.com> Date: Mon Jul 24 16:38:00 2017 +0300 Refactor BSP directory structure And it doesn't work today. If you are still interested in the question of how to make everything work correctly, I can provide you with scripts that can fix the current situation. 0 Quote
belegdol Posted February 23, 2022 Author Posted February 23, 2022 Sure, please go ahead. Having to delete the old kernel leftovers after every update is somewhat annoying. Having said that, it is interesting that the last change is from 2017 but the issue only appeared now. 0 Quote
going Posted February 23, 2022 Posted February 23, 2022 @belegdol Delete this file /etc/kernel/preinst.d/initramfs-cleanup Create a new one in postrm.d: /etc/kernel/postrm.d/initramfs-cleanup With the following content: #!/bin/sh version="$1" [ -x /usr/sbin/update-initramfs ] || exit 0 # passing the kernel version is required if [ -z "$version" ]; then echo >&2 "W: initramfs-tools: ${DPKG_MAINTSCRIPT_PACKAGE:-kernel package} did not pass a version number" exit 0 fi MOD_DIR=/lib/modules/ files="$(find /boot -maxdepth 1 -name 'initrd.img-*' -o -name 'uInitrd-*')" for f in $files; do if [ ! -d /lib/modules/"${f#*-}" ]; then echo "Remove unused generated file: $f"; rm $f fi done check_boot_dev (){ available_size_boot_device=$(df | awk '/boot$/{print $4}') echo "Free space after deleting the package $DPKG_MAINTSCRIPT_PACKAGE in /boot: $available_size_boot_device" >&2 } mountpoint -q /boot && check_boot_dev exit 0 chmod +x /etc/kernel/postrm.d/initramfs-cleanup 0 Quote
belegdol Posted February 23, 2022 Author Posted February 23, 2022 Thanks, I will give it a shot tomorrow. 0 Quote
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.