Dietpi: Image | Odroid HC4

Created on 10 Nov 2020  ·  30Comments  ·  Source: MichaIng/DietPi

Formal device information

Is the SBC officially supported by the Debian installer?

  • Doesn't look like it, only C2 mentioned in the Debian wiki

If not, is a reliable 3rd party Debian image available for this SBC?

  • Only Ubuntu AFAIK

If not, are there install instructions for Debian available?

  • Unknown

Further information

  • The HC4 is supposed to be identical to the C4, but features a SATA controller instead of USB3
Image Request Image update Odroid C4 Solution available Testintesters required
Source
picture JSchoeck

Most helpful comment

Not partitioning, just a mountpoint.
They created /media/boot as an empty folder and mount the bootfs into that folder.

It makes somewhat sense in the aftermath as Kernel is normally installed to /boot and tries to create symlinks, but symlinks can't be created on FAT partitions, so having /boot as part of the ext4 partition makes that work, and you only copy the required files uInitrd, Image and dtb to the bootfs.
With that, the bootfs can be kept relatively small as it never has to deal with multiple versions, it never has to deal with the initramfs either that is created before the uInitrd is created and so on.

While it all sounds logical I doubt it was there original idea, as they did this even before they were using .deb packages to deploy Kernels.
At first they only had .tar.gz files which where huge as they had unstripped kernel modules which were over 300 MB in size (Kernel 3.0 back then).
They had no versioning and simply downloaded the latest .tar.gz over and over again even if you already had it installed, they had no Kernel Headers, so DKMS was not possible, and so on.

I showed them originally how to create linux-image and -header files, after I provided them for my images already for over half a year before they asked me how it works.
By now they use their own system which does no longer create image and header files, but one big .deb file that has both inside, but that of cause also fails on all guides that say you need to install headers for your Kernel with apt install linux-headers-$(uname -r) or things like that, as this does not exist on their repos.

Regarding the /media/boot issue. That one is also fixed in 4.9.241-20210105-C4.
/etc/kernel/preinst.d/remove-old-on-upgrade had a line:
find /media/boot -maxdepth 1 -name "*.dtb" -delete || true
which of cause fails if /media/boot does not exist. So I added a precondition to check if it exists before using the find command.
But as I said, this will only work starting from the next update, as it's a PRE-installation task, so BEFORE the NEXT installation.

picture meveric on 7 Jan 2021
👍2 ❤1

All 30 comments

Many thanks for your request. Indeed It's basically a C4 so our C4 image should work fine. I'm not 100% sure about the current kernel/device tree but I think even SATA should work, same is XU4 image works on HC1/HC2/MC1 as well, including SATA.

Would be great, if you could simply test it (if you already have one at hand) 🙂: https://dietpi.com/downloads/images/DietPi_OdroidC4-ARMv8-Buster.7z

MichaIng picture MichaIng on 10 Nov 2020

Many thanks for your request. Indeed It's basically a C4 so our C4 image should work fine. I'm not 100% sure about the current kernel/device tree but I think even SATA should work, same is XU4 image works on HC1/HC2/MC1 as well, including SATA.

Would be great, if you could simply test it (if you already have one at hand) 🙂: https://dietpi.com/downloads/images/DietPi_OdroidC4-ARMv8-Buster.7z

Yep, I really wanted to finally setup the Nextcloud setup of my dreams. I'll try it out - thanks a lot for the great information and encouragement!

JSchoeck picture JSchoeck on 10 Nov 2020
❤1

First report:

  • Flashing the C4 image and booting the HC4 works. The dietpi-launcher and many tools work and do their thing
  • I added a SSD in one of the HC4 SATA slots and was able to format it (I chose BTRFS) with the drive-manager tool
  • Rebooting with the (BTRFS-formated) SSD leads to no output via HDMI except for a blinking cursor. The petitboot menu shows up beforehand (from SPI flash memory on the HC4). The blue heartbeat LED is active.
  • Removing the SSD again didn't reliably change anything, even after power-cycling and doing a reset-start (power-cycle with the HC4 reset button pressed). I did get a successfull reboot, but it takes several minutes, is this normal?
JSchoeck picture JSchoeck on 11 Nov 2020

Many thanks for testing.

You mean only the presence (being attached) of the SSD prevented boot, or delayed it significantly? Or did you try to boot the OS from the SSD?

One thing to check:

dmesg -l emerg,alert,crit,err

You could also try to max the verbosity of the kernel logs on boot. For this add loglevel=8 to /boot/boot.ini setenv bootargs line, e.g. that it looks like:

setenv bootargs "root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwait rw ${condev} ${amlogic} no_console_suspend fsck.repair=yes net.ifnames=0 elevator=noop hdmimode=${hdmimode} cvbsmode=576cvbs max_freq_a55=${max_freq_a55} max_freq_a73=${max_freq_a73} maxcpus=${maxcpus} voutmode=${voutmode} ${cmode} disablehpd=${disablehpd} cvbscable=${cvbscable} overscan=${overscan} ${hid_quirks} monitor_onoff=${monitor_onoff} logo=osd0,loaded ${cec_enable} sdrmode=${sdrmode} loglevel=8"
MichaIng picture MichaIng on 11 Nov 2020

Do you mean in the partition BOOT (where modifying the boot.ini didn't change anything in the behaviour) or in the partition rootfs and there in the folder /boot/ (which is empty)?

Does it matter at all if ethernet is connected? I always had either eithernet or a display so far. Just want to avoid silly things causing pain.

JSchoeck picture JSchoeck on 13 Nov 2020

Ah I mean in the first partition (BOOT) the existing boot.ini.

I always had either eithernet or a display so far.

At best have both, so that you can directly run an update: dietpi-update 1
But yes, any of both works, as without display, Ethernet allows you to use SSH instead.

MichaIng picture MichaIng on 13 Nov 2020

Did you find time to further check the boot issues? I'm currently updating the image btw. It should not contain major changes, but at least a cleaner and faster first boot experience.
EDIT: https://forum.odroid.com/viewtopic.php?p=311490#p311490
I.e. the new image seems to support HC4 better. Strange that it even booted in your case. New build in process, takes a while as I still build in x86_64 VM, native arm64 (RK3399) build server will be deployed the next days to speed things up.

EDIT2: Done, that one should now work better or at all with Odroid HC4: https://dietpi.com/downloads/images/DietPi_OdroidC4-ARMv8-Buster.7z

MichaIng picture MichaIng on 29 Dec 2020

@MichaIng
while you are working on the HC4 image, there is a report about not working SATA drive on Odroid HC4. Both, Armbian as well as plain Debian seems to be working. But on DietPi it is not recognised at all. Probably a missing package?

https://dietpi.com/phpbb/viewtopic.php?f=11&t=8459

Joulinar picture Joulinar on 29 Dec 2020

Hi,
I had a nice a quick boot on an SD with this latest image, however, trying to boot from SSD or detect SSD/HDDs from the SD boot didn't work :'C
Using the latest debian buster from here atm
http://ppa.linuxfactory.or.kr/images/raw/arm64/buster/

eyduh picture eyduh on 4 Jan 2021

It seems that the current kernel version broke SATA detection, I forwarded it to Meveric: https://forum.odroid.com/viewtopic.php?p=317246#p317246
I could try to extract the kernel from the functional base image: https://dietpi.com/meveric/images/Buster/Debian-Buster64-1.1-20201112-C4.img.xz
Same Linux 4.9.236, but an older package build.

MichaIng picture MichaIng on 4 Jan 2021

@eyduh
Which SATA drive are you using? And if you have the DietPi SD card still at hand, could you check for some kernel messages and how much of the drive or controller is detected at all?

fdisk -l
apt install lspci
lspci -t
MichaIng picture MichaIng on 4 Jan 2021

A new kernel version is available, probably that helps:

apt update
apt install linux-image-arm64-odroid-c4
MichaIng picture MichaIng on 4 Jan 2021

A new kernel version is available, probably that helps:

apt update
apt install linux-image-arm64-odroid-c4

I had flashed another image over the old one but I'll try with this one.

could I flash this on an SD, boot, install new kernel and then dd the SD with the new kernel over to the ssd?

eyduh picture eyduh on 5 Jan 2021

A new kernel version is available, probably that helps:

apt update
apt install linux-image-arm64-odroid-c4

I flashed the same dietpi image on an SD again and I get this error at software install phase of the initial run:

           ┌─────────────────────────────────────────────────┤ DietPi-Software ├──────────────────────────────────────────────────┐
           │ APT upgrade                                                                                                          │ 
           │  - Command: apt-get -qq upgrade                                                                                      │ 
           │  - Exit code: 100                                                                                                    │ 
           │  - DietPi version: v6.34.3 (MichaIng/master) | HW_MODEL: 16 | HW_ARCH: 3 | DISTRO: 5                                 │ 
           │  - Image creator: DietPi Core Team                                                                                   │ 
           │  - Pre-image: Meveric                                                                                                │ 
           │  - Error log:                                                                                                        │ 
           │ E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).                      │ 
           │                                                                                                                      │ 
           │                         Retry          : Re-run the last command that failed                                         │ 
           │                         DietPi-Config  : Edit network, APT/NTP mirror settings etc                                   │ 
           │                         Open subshell  : Open a subshell to investigate or solve the issue                           │ 
           │                         Send report    : Uploads bugreport containing system info to DietPi                          │ 
           │                                        ●─ Devs only ──────────────────────────────────────●                          │ 
           │                         Change command : Adjust and rerun the command                                                │ 
           │                                                                                                                      │ 
           │                                                                                                                      │ 
           │                                  <Ok>                                      <Exit>                                    │ 
           │                                                                                                                      │ 
           └──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

And if I exit and try to `apt --fix-broken install´ I'm met with:

Reading package lists... Done
Building dependency tree       
Reading state information... Done
Correcting dependencies... Done
The following package was automatically installed and is no longer required:
  linux-firmware-image-4.9.236-arm64
Use 'apt autoremove' to remove it.
The following additional packages will be installed:
  linux-image-4.9.241-arm64
The following NEW packages will be installed:
  linux-image-4.9.241-arm64
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
Need to get 20.2 MB of archives.
After this operation, 76.4 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 https://dietpi.com/meveric all/c4 arm64 linux-image-4.9.241-arm64 arm64 4.9.241-20210104-C4 [20.2 MB]
Fetched 20.2 MB in 5s (4075 kB/s)                    
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 14613 files and directories currently installed.)
Preparing to unpack .../linux-image-4.9.241-arm64_4.9.241-20210104-C4_arm64.deb ...
find: ‘/media/boot’: No such file or directory
Unpacking linux-image-4.9.241-arm64 (4.9.241-20210104-C4) ...
dpkg: error processing archive /var/cache/apt/archives/linux-image-4.9.241-arm64_4.9.241-20210104-C4_arm64.deb (--unpack):
 trying to overwrite '/boot/meson64_odroidc4.dtb', which is also in package linux-image-4.9.236-arm64 4.9.236-20201220-C4
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/linux-image-4.9.241-arm64_4.9.241-20210104-C4_arm64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

If I go apt install && apt install linux-image-arm64-odroid-c4
I get this:

All packages are up to date.
Reading package lists... Done
Building dependency tree       
Reading state information... Done
linux-image-arm64-odroid-c4 is already the newest version (4.9.241-arm64-1).
You might want to run 'apt --fix-broken install' to correct these.
The following packages have unmet dependencies:
 linux-image-arm64-odroid-c4 : Depends: linux-image-4.9.241-arm64 but it is not going to be installed
E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).

As to your previous question:

# apt install lspci
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package lspci

and attached:
dmesg.txt
fdisk.txt

I am currently trying a boot of that same image on the SSD I wanted to use but hooked up to the USB port on the back using the same usb3-sata adapter I used to flash it. I made it all the way to reboot thus far c:

eyduh picture eyduh on 5 Jan 2021

I am currently trying a boot of that same image on the SSD I wanted to use but hooked up to the USB port on the back using the same usb3-sata adapter I used to flash it. I made it all the way to reboot thus far c:

Finished reboot, sshd into it and:

# apt update && apt install linux-image-arm64-odroid-c4
Hit:1 https://deb.debian.org/debian buster InRelease
Hit:2 https://deb.debian.org/debian buster-updates InRelease
Hit:3 https://deb.debian.org/debian-security buster/updates InRelease
Hit:4 https://deb.debian.org/debian buster-backports InRelease
Hit:5 https://dietpi.com/meveric all InRelease
Hit:6 https://dietpi.com/meveric buster InRelease
Reading package lists... Done
Building dependency tree       
Reading state information... Done
All packages are up to date.
Reading package lists... Done
Building dependency tree       
Reading state information... Done
linux-image-arm64-odroid-c4 is already the newest version (4.9.241-arm64-1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

sudo shutdown now unplug the ssd, insert it into native SATA ports aaand...

blinky cursor.. gonna leave it overnight see if it sorts itself out. At least I know booting ssd from USB works.

edit: 9h later and it's still blinking. I don't think it'll sort itself out :'c

eyduh picture eyduh on 5 Jan 2021

It seems like the kernel never really got installed:

dpkg: error processing archive /var/cache/apt/archives/linux-image-4.9.241-arm64_4.9.241-20210104-C4_arm64.deb (--unpack):
 trying to overwrite '/boot/meson64_odroidc4.dtb', which is also in package linux-image-4.9.236-arm64 4.9.236-20201220-C4

Probably there is tag in the kernel package missing that it "replaces" the previous one. Normally the old one should then automatically be removed before the new one is installed. Let me test here.

MichaIng picture MichaIng on 5 Jan 2021

there is tag in the kernel package missing that it "replaces" the previous one

so on the SD I got that error message, on the SSD install it didnt give me any error message, however:

/media/ada/BOOT$ tree -L 1
.
├── boot.ini
├── config-4.9.236-arm64
├── config-4.9.241-arm64
├── dietpi
├── dietpi-CHANGELOG.txt
├── dietpi-LICENSE.txt
├── dietpi-README.md
├── dietpi.txt
├── dietpi-wifi.txt
├── Image
├── Image.gz
├── initrd.img-4.9.236-arm64
├── initrd.img-4.9.241-arm64
├── meson64_odroidc4.dtb
├── meson64_odroidhc4.dtb
├── overlays
├── System.map-4.9.236-arm64
├── System.map-4.9.241-arm64
├── uInitrd
├── uInitrd-4.9.236-arm64
├── uInitrd-4.9.241-arm64
├── vmlinuz-4.9.236-arm64
└── vmlinuz-4.9.241-arm64

2 directories, 21 files

I'll move all the old ones into a backup folder and relink the symbolic links to the new files.

eyduh picture eyduh on 5 Jan 2021

Okay during first boot installs at least the packages upgrade fine:

[ INFO ] DietPi-Software | APT dist-upgrade, please wait...
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package linux-firmware-image-4.9.241-arm64.
(Reading database ... 14583 files and directories currently installed.)
Preparing to unpack .../linux-firmware-image-4.9.241-arm64_4.9.241-20210104-C4_arm64.deb ...
Unpacking linux-firmware-image-4.9.241-arm64 (4.9.241-20210104-C4) ...
Selecting previously unselected package linux-image-4.9.241-arm64.
Preparing to unpack .../linux-image-4.9.241-arm64_4.9.241-20210104-C4_arm64.deb ...
/usr/bin/find: ‘/media/boot’: No such file or directory
Unpacking linux-image-4.9.241-arm64 (4.9.241-20210104-C4) ...
Replacing files in old package linux-image-4.9.236-arm64 (4.9.236-20201220-C4) ...
Preparing to unpack .../linux-image-arm64-odroid-c4_4.9.241-arm64-1_arm64.deb ...
Unpacking linux-image-arm64-odroid-c4 (4.9.241-arm64-1) over (4.9.236-arm64-1) ...
Setting up linux-image-4.9.241-arm64 (4.9.241-20210104-C4) ...
update-initramfs: Generating /boot/initrd.img-4.9.241-arm64
Image Name:   uInitrd
Created:      Tue Jan  5 21:24:22 2021
Image Type:   AArch64 Linux RAMDisk Image (uncompressed)
Data Size:    8003891 Bytes = 7816.30 KiB = 7.63 MiB
Load Address: 00000000
Entry Point:  00000000
Setting up linux-firmware-image-4.9.241-arm64 (4.9.241-20210104-C4) ...
Setting up linux-image-arm64-odroid-c4 (4.9.241-arm64-1) ...
[  OK  ] DietPi-Software | APT dist-upgrade

Notable Replacing files in old package linux-image-4.9.236-arm64 (4.9.236-20201220-C4) ....

In your case /lib/modules/4.9.241-arm64 exists, right?

....

I think I found a (the) bug in the kernel. Please do: mv /boot/Image.gz /boot/Image.gz.bak; mv /boot/Image /boot/Image.gz
The postinst script only does this for Odroid N2 and C4, not for HC4:

if [ `cat /proc/cpuinfo | grep -c ODROID-N2` -ge 1 ] || [ `cat /proc/cpuinfo | grep -c ODROID-C4` -ge 1 ]; then
        if [ -f /media/boot/Image ]; then
                [ -f /media/boot/Image.gz ] && mv /media/boot/Image.gz /media/boot/Image.gz.bak
                mv /media/boot/Image /media/boot/Image.gz
        else
                [ -f /boot/Image.gz ] && mv /boot/Image.gz /boot/Image.gz.bak
                mv /boot/Image /boot/Image.gz
        fi
fi

@meveric
I guess either ODROID-HC4 needs to be added to the conditions or alternatively, the whole check removed, as long as that script is not shared with other kernel packages?

Alternatively the boot.ini could be adjusted and that renaming skipped, or is it intended to have a backup in place?

fatload mmc ${devno}:1 ${k_addr} Image.gz

=>

fatload mmc ${devno}:1 ${k_addr} Image
MichaIng picture MichaIng on 5 Jan 2021

hmm I thought I fixed that last time.
Wonder if it's using some old scripts, I changed quite a lot, to get rid of most of the conditions, as it's a hassle to keep track of all the different boards.

I'll check for that particular problem.
I only tested the update on my C4 not HC4 as that one is currently busy, but obviously that would work with that condition.

If I find something I'll probably upload a new image. Pretty much the same image again with a new date as the version.

I also thought I fixed the entire /usr/bin/find: ‘/media/boot’: No such file or directory issue already, which is why I assume I somehow ended up with old scripts again sighs

meveric picture meveric on 5 Jan 2021

ok uploaded a new Kernel, this time it's doing what it's suppose to be doing.
Checked on my HC4 and it worked.
The /media/boot thing will be done on the next update, it replaces the pre-install scripts and they only work for the next install, but you can test with apt install --reinstall linux-image-4.9.241-arm64 if you want to see that the /media/boot is gone after this update.

meveric picture meveric on 6 Jan 2021

but you can test with apt install --reinstall linux-image-4.9.241-arm64 if you want to see that the /media/boot is gone after this update.

Tested this while booting from USB3->SATA SSD, output below:

# apt update && apt install --reinstall linux-image-4.9.241-arm64
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 20.2 MB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 https://dietpi.com/meveric all/c4 arm64 linux-image-4.9.241-arm64 arm64 4.9.241-20210104-C4 [20.2 MB]
Fetched 20.2 MB in 2s (8127 kB/s)                     
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 20739 files and directories currently installed.)
Preparing to unpack .../linux-image-4.9.241-arm64_4.9.241-20210104-C4_arm64.deb ...
find: ‘/media/boot’: No such file or directory
Unpacking linux-image-4.9.241-arm64 (4.9.241-20210104-C4) over (4.9.241-20210104-C4) ...
Setting up linux-image-4.9.241-arm64 (4.9.241-20210104-C4) ...
update-initramfs: Generating /boot/initrd.img-4.9.241-arm64
Image Name:   uInitrd
Created:      Wed Jan  6 02:31:33 2021
Image Type:   AArch64 Linux RAMDisk Image (uncompressed)
Data Size:    8004122 Bytes = 7816.53 KiB = 7.63 MiB
Load Address: 00000000
Entry Point:  00000000
Image Name:   uInitrd
Created:      Wed Jan  6 02:31:40 2021
Image Type:   AArch64 Linux RAMDisk Image (uncompressed)
Data Size:    8003937 Bytes = 7816.34 KiB = 7.63 MiB
Load Address: 00000000
Entry Point:  00000000

Still noticing a little find: ‘/media/boot’: No such file or directory in there.
sudo shutdown and put the SSD in the front Toaster-SATA port instead, and it seems stuck on blinky cursor post-petitboot pre-login (waited about 5min)

plugged it into another system and had a look:

$ ls /media/3086-D853/
boot.ini              dietpi-CHANGELOG.txt  dietpi-wifi.txt           initrd.img-4.9.241-arm64  System.map-4.9.236-arm64  uInitrd-4.9.241-arm64
config-4.9.236-arm64  dietpi-LICENSE.txt    Image                     meson64_odroidc4.dtb      System.map-4.9.241-arm64  vmlinuz-4.9.236-arm64
config-4.9.241-arm64  dietpi-README.md      Image.gz                  meson64_odroidhc4.dtb     uInitrd                   vmlinuz-4.9.241-arm64
dietpi                dietpi.txt            initrd.img-4.9.236-arm64  overlays                  uInitrd-4.9.236-arm64
$ tree /media/e139ce78-9841-40fe-8823-96a304a09859/lib/modules -L 2
/media/e139ce78-9841-40fe-8823-96a304a09859/lib/modules
├── 4.9.236-arm64
│   ├── kernel
│   ├── modules.alias
│   ├── modules.alias.bin
│   ├── modules.builtin
│   ├── modules.builtin.bin
│   ├── modules.dep
│   ├── modules.dep.bin
│   ├── modules.devname
│   ├── modules.order
│   ├── modules.softdep
│   ├── modules.symbols
│   └── modules.symbols.bin
└── 4.9.241-arm64
    ├── kernel
    ├── modules.alias
    ├── modules.alias.bin
    ├── modules.builtin
    ├── modules.builtin.bin
    ├── modules.dep
    ├── modules.dep.bin
    ├── modules.devname
    ├── modules.order
    ├── modules.softdep
    ├── modules.symbols
    └── modules.symbols.bin

4 directories, 22 files

So I put it back in the USB boot mode & # mv /boot/Image.gz /boot/Image.gz.bak; mv /boot/Image /boot/Image.gz then reboot in toaster-mode...

...and it works!
Thanks babes you guys are legends! <3

eyduh picture eyduh on 6 Jan 2021

but you can test with apt install --reinstall linux-image-4.9.241-arm64 if you want to see that the /media/boot is gone after this update.

Tested this while booting from USB3->SATA SSD, output below:

```

apt update && apt install --reinstall linux-image-4.9.241-arm64

Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 20.2 MB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 https://dietpi.com/meveric all/c4 arm64 linux-image-4.9.241-arm64 arm64 4.9.241-20210104-C4 [20.2 MB]
Fetched 20.2 MB in 2s (8127 kB/s)

That is not what I meant.
I said if you install the update which is: linux-image-4.9.241-arm64 arm64 4.9.241-20210105-C4.
It includes a fix for the /media/boot notice. That fix only is visible for the NEXT update, OR if you do a reinstall AFTER the linux-image-4.9.241-arm64 arm64 4.9.241-20210105-C4 update is installed.

You just re-installed the broken linux-image-4.9.241-arm64 arm64 4.9.241-20210104-C4 where you had to copy Image.gz by hand. That is what was fixed with linux-image-4.9.241-arm64 arm64 4.9.241-20210105-C4.

But at least the SATA issue seems to be solved with 4.9.241 it seems?

meveric picture meveric on 6 Jan 2021

I think our APT mirror was synced later in the night (daily sync), now the new version is available. I'll change it to hourly sync, so changes are available quickly.

MichaIng picture MichaIng on 6 Jan 2021

Right! I shoulda noticed the date.

This is trange tho

# apt upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  linux-firmware-image-4.9.241-arm64 linux-image-4.9.241-arm64
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 20.4 MB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 https://dietpi.com/meveric all/c4 arm64 linux-firmware-image-4.9.241-arm64 arm64 4.9.241-20210105-C4 [135 kB]
Get:2 https://dietpi.com/meveric all/c4 arm64 linux-image-4.9.241-arm64 arm64 4.9.241-20210105-C4 [20.2 MB]
Fetched 20.4 MB in 2s (9226 kB/s)                    
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 20822 files and directories currently installed.)
Preparing to unpack .../linux-firmware-image-4.9.241-arm64_4.9.241-20210105-C4_arm64.deb ...
Unpacking linux-firmware-image-4.9.241-arm64 (4.9.241-20210105-C4) over (4.9.241-20210104-C4) ...
Preparing to unpack .../linux-image-4.9.241-arm64_4.9.241-20210105-C4_arm64.deb ...
find: ‘/media/boot’: No such file or directory
Unpacking linux-image-4.9.241-arm64 (4.9.241-20210105-C4) over (4.9.241-20210104-C4) ...
Setting up linux-image-4.9.241-arm64 (4.9.241-20210105-C4) ...
update-initramfs: Generating /boot/initrd.img-4.9.241-arm64
Image Name:   uInitrd
Created:      Wed Jan  6 18:46:44 2021
Image Type:   AArch64 Linux RAMDisk Image (uncompressed)
Data Size:    8817249 Bytes = 8610.59 KiB = 8.41 MiB
Load Address: 00000000
Entry Point:  00000000
Setting up linux-firmware-image-4.9.241-arm64 (4.9.241-20210105-C4) ...

odd..

But at least the SATA issue seems to be solved with 4.9.241 it seems?

yup

eyduh picture eyduh on 6 Jan 2021

Does it make sense to look for /media/boot at all?
/boot is the regular FHS-conform location for this and the package could not even be installed if the actual boot partition was not mounted there, not only the package files but as well e.g. building/updating initramfs etc. /media is often used for auto-mounting removable drives, but I doubt that anyone would store the boot partition on a removable USB stick or such, plugging it for kernel upgrades only, and for doing reboots, relying on auto-mount 😄.

MichaIng picture MichaIng on 6 Jan 2021

Since the Kernel is not OS specific, and for the poor guys that stick with the default Ubuntu image, I offer an option to use my Kernel instead.
/media/boot is just for compatibility with HKs Ubuntu images.

meveric picture meveric on 6 Jan 2021
❤1 😄1

Ah okay, strange partitioning then on those images, as AFAIK on official Ubuntu the boot partition is regularly at /boot as well?

However, so finally the issue was probably only the missing Image.gz update. I'll update our images again so that SATA works on first boot already. I'll have a look into the packages postinst script, at least in /etc/kernel/* scripts I could not see any find /media/boot.

MichaIng picture MichaIng on 6 Jan 2021

Not partitioning, just a mountpoint.
They created /media/boot as an empty folder and mount the bootfs into that folder.

It makes somewhat sense in the aftermath as Kernel is normally installed to /boot and tries to create symlinks, but symlinks can't be created on FAT partitions, so having /boot as part of the ext4 partition makes that work, and you only copy the required files uInitrd, Image and dtb to the bootfs.
With that, the bootfs can be kept relatively small as it never has to deal with multiple versions, it never has to deal with the initramfs either that is created before the uInitrd is created and so on.

While it all sounds logical I doubt it was there original idea, as they did this even before they were using .deb packages to deploy Kernels.
At first they only had .tar.gz files which where huge as they had unstripped kernel modules which were over 300 MB in size (Kernel 3.0 back then).
They had no versioning and simply downloaded the latest .tar.gz over and over again even if you already had it installed, they had no Kernel Headers, so DKMS was not possible, and so on.

I showed them originally how to create linux-image and -header files, after I provided them for my images already for over half a year before they asked me how it works.
By now they use their own system which does no longer create image and header files, but one big .deb file that has both inside, but that of cause also fails on all guides that say you need to install headers for your Kernel with apt install linux-headers-$(uname -r) or things like that, as this does not exist on their repos.

Regarding the /media/boot issue. That one is also fixed in 4.9.241-20210105-C4.
/etc/kernel/preinst.d/remove-old-on-upgrade had a line:
find /media/boot -maxdepth 1 -name "*.dtb" -delete || true
which of cause fails if /media/boot does not exist. So I added a precondition to check if it exists before using the find command.
But as I said, this will only work starting from the next update, as it's a PRE-installation task, so BEFORE the NEXT installation.

meveric picture meveric on 7 Jan 2021
👍2 ❤1

This thread has been so informative <3
Thank you both for your patience with less technically literate ppl suc has myself and for your clear explanations c:
(It's nice not to get yelled at for not knowing something)

They had no versioning and simply downloaded the latest .tar.gz over and over again even if you already had it installed, they had no Kernel Headers, so DKMS was not possible, and so on

it's kinda cute when hardware peeps make softwares c;

starting from the next update, as it's a PRE-installation task, so BEFORE the NEXT installation.

Aah! now it makes sense c: thx

I now have my little hc4 up and running with dietpi & nextcloudpi and its SSD & HDD. <3 thx

eyduh picture eyduh on 7 Jan 2021

I updated our image, now the new kernel should be installed correctly + I enabled the login prompt on the serial console (4-pin connector => /dev/ttyS0), that was missing.

MichaIng picture MichaIng on 8 Jan 2021
Was this page helpful?
0 / 5 - 0 ratings

Related issues

oshank picture oshank  ·  3Comments
k-plan picture k-plan  ·  3Comments
Fourdee picture Fourdee  ·  3Comments
1021683053 picture 1021683053  ·  3Comments
MichaIng picture MichaIng  ·  3Comments