Latest XU4 Kernel seems to break install Topic is solved

[equusgrevyi]

Latest XU4 kernel "27072017" 3.10.105+ came through apt update today, gave me a warning about not loading some modules and would reassemble the list on reboot. Did a reboot and get the panic blinking light of doom, no SSH connection.

Flashed a new MMC card, started a plain install and managed to get to the dietpi installer, ran the installer after the first dietpi-update and behold the blinking death light and no SSH connection again.

Code: Select all

Preparing to unpack .../linux-image-3.10.105+_3.10.105-20170727-XU3_armhf.deb ..                                                              .
The directory /lib/modules/3.10.105+ still exists. Continuing as directed.
Examining /etc/kernel/preinst.d/
run-parts: executing /etc/kernel/preinst.d/remove-old-on-upgrade 3.10.105+ /boot/vmlinuz-3.10.105+
Done.
Unpacking linux-image-3.10.105+ (3.10.105-20170727-XU3) over (3.10.105-20170611-XU3) ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.10.105+ /boot/vmlinuz-3.10.105+
Preparing to unpack .../debian-archive-keyring_2017.5~deb8u1_all.deb ...
Unpacking debian-archive-keyring (2017.5~deb8u1) over (2014.3) ...
Setting up debian-archive-keyring (2017.5~deb8u1) ...
Removing obsolete conffile /etc/apt/trusted.gpg.d/debian-archive-squeeze-automatic.gpg ...
Removing obsolete conffile /etc/apt/trusted.gpg.d/debian-archive-squeeze-stable.gpg ...
(Reading database ... 14629 files and directories currently installed.)
Preparing to unpack .../multiarch-support_2.19-18+deb8u10_armhf.deb ...
Unpacking multiarch-support (2.19-18+deb8u10) over (2.19-18+deb8u9) ...
Setting up multiarch-support (2.19-18+deb8u10) ...
(Reading database ... 14629 files and directories currently installed.)
Preparing to unpack .../locales_2.19-18+deb8u10_all.deb ...
Unpacking locales (2.19-18+deb8u10) over (2.19-18+deb8u9) ...
Setting up debconf-utils (1.5.56+deb8u1) ...
Setting up libgnutls-deb0-28:armhf (3.3.8-6+deb8u7) ...
Setting up libgnutls-openssl27:armhf (3.3.8-6+deb8u7) ...
Setting up libisc-export95 (1:9.9.5.dfsg-9+deb8u13) ...
Setting up libdns-export100 (1:9.9.5.dfsg-9+deb8u13) ...
Setting up libexpat1:armhf (2.1.0-6+deb8u4) ...
Setting up libffi6:armhf (3.1-2+deb8u1) ...
Setting up libisccfg-export90 (1:9.9.5.dfsg-9+deb8u13) ...
Setting up libirs-export91 (1:9.9.5.dfsg-9+deb8u13) ...
Setting up uboot (20170522-5+deb8u2) ...
30+0 records in
30+0 records out
15360 bytes (15 kB) copied, 0.0642831 s, 239 kB/s
28+1 records in
28+1 records out
14592 bytes (15 kB) copied, 0.0294374 s, 496 kB/s
541+1 records in
541+1 records out
277500 bytes (278 kB) copied, 1.10235 s, 252 kB/s
512+0 records in
512+0 records out
262144 bytes (262 kB) copied, 0.814054 s, 322 kB/s
32+0 records in
32+0 records out
16384 bytes (16 kB) copied, 0.0575653 s, 285 kB/s
Setting up linux-image-3.10.105+ (3.10.105-20170727-XU3) ...

 Hmm. There is a symbolic link /lib/modules/3.10.105+/build
 However, I can not read it: No such file or directory
 Therefore, I am deleting /lib/modules/3.10.105+/build


 Hmm. The package shipped with a symbolic link /lib/modules/3.10.105+/source
 However, I can not read the target: No such file or directory
 Therefore, I am deleting /lib/modules/3.10.105+/source

Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 3.10.105+ /boot/vmlinuz-3.10.105+
run-parts: executing /etc/kernel/postinst.d/copy_dtb 3.10.105+ /boot/vmlinuz-3.10.105+
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.10.105+ /boot/vmlinuz-3.10.105+
update-initramfs: Generating /boot/initrd.img-3.10.105+
run-parts: executing /etc/kernel/postinst.d/uInitrd 3.10.105+ /boot/vmlinuz-3.10.105+
run-parts: executing /etc/kernel/postinst.d/zImage 3.10.105+ /boot/vmlinuz-3.10.105+

I will shortly be trying a reinstall but marking the DietPi version of the kernel for holding with apt to see if that makes a difference.

[equusgrevyi]

Withholding the package with apt appears to have let it the install continue functioning and reboot successfully. Evidently it doesn't like something the update is or isn't doing just can't be sure what.

[Lanxon]

how can i set the package on hold ?

[trikster]

I will shortly be trying a reinstall but marking the DietPi version of the kernel for holding with apt to see if that makes a difference.

Could you please give us more details on how you did this? I have a 'dead' XU4 too.

Edit: I figured it out myself.

Code: Select all

apt-mark hold linux-image-3.10.105+

Use this command to withhold the broken kernel until it gets fixed.

[equusgrevyi]

I will shortly be trying a reinstall but marking the DietPi version of the kernel for holding with apt to see if that makes a difference.

Could you please give us more details on how you did this? I have a 'dead' XU4 too.

Edit: I figured it out myself.

Code: Select all

apt-mark hold linux-image-3.10.105+

Use this command to withhold the broken kernel until it gets fixed.

Good to see that you figured it out and that I'm not the only one that had a broken install! It seems to be some issue with the modules/symlinks detected as it begins the upgrade, not sure if it's a DietPi specific problem?

[mnc]

mount sd/mmc
edit boot.ini
change: exynos5422-odroidxu4.dtb to: exynos5422-odroidxu3.dtb
profit.

[equusgrevyi]

mount sd/mmc
edit boot.ini
change: exynos5422-odroidxu4.dtb to: exynos5422-odroidxu3.dtb
profit.

I'll check this out, not really sure why this isn't done as part of the upgrade though, seems a bit counter-intuitive for users coming from say a Pi3 where kernels just upgrade without any problems

EDIT:
This workaround seems to work, since mnc so helpfully told us the filepath to boot.ini I will repeat it here for good measure.
Changed the instances of exynoss5422-odroidxu4.dtb to exynos5422-odroidxu3.dtb in both

Code: Select all

/boot/boot.ini

and

Code: Select all

/DietPi/boot.ini

as I wasn't sure whether one, the other or both were needing the edit. Both had the same line, so I changed it in both and seemed to work.

[mnc]

since mnc so helpfully told us the filepath to boot.ini

If you end up here you probably already "bricked" your setup, so if you'll mount the sd/mmc on another device there is only the boot partition you will see, hence this is the filelocation.

[Allamur]

Glad, that this simple edit solved the boot issue - had the same issue.

[equusgrevyi]

since mnc so helpfully told us the filepath to boot.ini

If you end up here you probably already "bricked" your setup, so if you'll mount the sd/mmc on another device there is only the boot partition you will see, hence this is the filelocation.

Or, alternatively, I already bricked the install and wiped the MMC card and reflashed it, put the package on hold and reported the issue