Package: u-boot-sunxi
Version: 2018.01+dfsg1-2
Severity: normal
Hi,
the system in question is a Banana Pi, booting off an sd card. /boot is
already on the SATA disk, and was an ext4 file system when the issue
appeared.
According to the availability of the ext4* commands, this u-boot should
be able to handle an ext4fs, I therefore used it as /boot. This has
worked until recently, when I installed the 4.15.6 kernel. Booting this
kernel failed with "file not found" for the dtb file laoded from
/dtbs/4.15.6/sun7i-a20-bananapi.dtb. Setting fk_kvers to 4.15.5 made the
system boot 4.15.5 just fine.
Examining /boot from the running system didn't show any visible
difference while u-boot still complained that there was no dtb for
4.15.6.
I then noticed that ls -l /boot/dtbs | wc -l returned 64. This made me
suspicious, and I cleaned up /boot/dtbs a bit, with the behavior
unchanged.
I then renamed /boot/dtbs to /boot/dtbs-old and did mkdir /boot/dtbs, cp
-a /boot/dtbs-old/* /boot/dtbs/. Starting with this, u-boot started
claiming that /dtbs was completely empty.
I finally solved the issue by reformatting /boot as ext2, which made the
system immediately boot even 4.15.6.
I therefore conclude that:
- u-boot has some weird issues regarding directories in /boot
- these can either be triggered by having /boot/dtbs grow over 64
entries or by
- re-creating /boot/dtbs anew from a recent kernel
The (now gone) ext4fs had the following attributes:
Filesystem features: has_journal ext_attr resize_inode dir_index filetype
needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink
extra_isize metadata_csum
Is is possible that u-boot won't handle some of the advanced ext4
features?
Greetings
Marc
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: armhf (armv7l)
Kernel: Linux 4.15.6-zgbpi-armmp-lpae (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
-- no debconf information
