Jump to content
  • 0

HC1 kernel update gone wrong?


belegdol
 Share

Question

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?

Link to comment
Share on other sites

Recommended Posts

  • 0

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?

Link to comment
Share on other sites

Armbian is a community driven open source project. Do you like to contribute your code?

  • 0

@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.

 

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0
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 ;) 

Link to comment
Share on other sites

  • 0

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?

Link to comment
Share on other sites

  • 0
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)

Link to comment
Share on other sites

  • 0
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
`

 

Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0

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.

 

 

Link to comment
Share on other sites

  • 0
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.

 

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0
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

... 

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

`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

 

Link to comment
Share on other sites

  • 0
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.


 

Link to comment
Share on other sites

  • 0
$ 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

 

Link to comment
Share on other sites

  • 0

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

 

 

Link to comment
Share on other sites

  • 0

@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 сказал:

 

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.

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

@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

 

Link to comment
Share on other sites

Join the conversation

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

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

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

×   Your previous content has been restored.   Clear editor

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

Loading...
 Share

×
×
  • Create New...