[OS] Debian Buster for ODROID C4/HC4

nas27 · Post by **nas27** » Fri Jan 15, 2021 9:18 pm

torx wrote: ↑
Tue Jan 05, 2021 5:46 am
I do not know if this is SATA related but after a recent update through OMV I lost use of all four of the USB ports on a C4. I downloaded an UBUNTU image and the USBs seems to be working.

I had the same problem, USB ports disappearing, with an apt update/apt upgrade of meveric's system on a C4. It looked like it was booting with an HC4 configuration. I fixed it by editing boot.ini, commenting out the variant code:

Code: Select all

#if test "x${variant}" != "x"; then
#	fatload mmc ${devno}:1 ${dtb_loadaddr} meson64_odroid${variant}.dtb
# acts as fallback
#else
	fatload mmc ${devno}:1 ${dtb_loadaddr} meson64_odroidc4.dtb
#fi

Regards,
Nick

Educampi · Post by **Educampi** » Mon Jan 18, 2021 7:51 am

Hi,
I've tried the image a couple of times but it keeps failing, any idea why?

I used Etcher.
The official ubuntu image works though.

I'm attaching the serial output.

Thanks!

meveric · Post by **meveric** » Mon Jan 18, 2021 8:19 am

ALERT! /dev/mmcblk1p2 does not exist. Dropping to a shell!

It says it doesn't find the SD/eMMC module.
I also saw it find /dev/mmcblk0 but not mmcblk1

The bootcmd:

Code: Select all

[    0.000000@0] Kernel command line: root=/dev/mmcblk1p2 rootwait ro console=ttyS0,115200n8  no_console_suspend fsck.repair=yes net.ifnames=0 elevator=noop hdmimode=1080p60hz cvbsmode=576cvbs max_freq_a55= maxcpus=4 voutmode=hdmi  disablehpd=false cvbscable=0  overscan=100  monitor_onoff=false logo=osd0,loaded  sdrmode=auto enable_wol=0

doesn't seem correct mine also says /dev/mmcblk0p2 as rootfs, while it actually should use a UUID instead, so I wonder if the boot.ini is loaded correctly or not. I have to check that in more detail.

Educampi · Post by **Educampi** » Mon Jan 18, 2021 9:06 am

Thanks for the quick reply.

Since my post I found the instructions on how to do a netboot and installed Debian 11, so I no longer need help to make this image work.

Thanks!

gom · Post by **gom** » Fri Jan 22, 2021 12:29 am

i used your image for my new hc4
works great
i did apt update, apt upgrade
got a new kernel but when i reboot it uses the older version

also i wanted get the kernel source
i added deb-src lines in /etc/apt/source.list and /etc/apt/source.list.d/*
and ran apt update
but i only get

~# apt source linux-image-4.9.241-arm64
Reading package lists... Done
Picking 'linux-4.9.241-arm64' as source package instead of 'linux-image-4.9.241-arm64'
E: Unable to find a source package for linux-4.9.241-arm64

meveric · Post by **meveric** » Fri Jan 22, 2021 3:35 am

There is no source package. I use the git repository from HardKernel as a source for the kernel. You can download the sources from there.

Also make sure you don't forget apt dist-upgrade.
You can check /boot to see if the correct kernel is active. Check the size of the files that lay there.

uInitrd and Image.gz are the files that are loaded. vzlinuz is the Image file, you can just copy it if it has the wrong size.
That's a manual fix, but if cause the update should have gone through without errors.
Also check the output of the apt command. Maybe you missed an error?

gom · Post by **gom** » Fri Jan 22, 2021 4:07 am

there is an error somewhere between update-initramfs and /etc/initramfs-tools/hooks/uInitrd
i ran update-initramfs -k 4.9.241-arm64 -u
at line 509 in the attachment is where update-initramfs calls /etc/initramfs-tools/hooks/uInitrd
the version changes from 4.9.241 to 4.9.236

meveric · Post by **meveric** » Fri Jan 22, 2021 4:37 am

yep.. the hook for uInitrd (for initramfs-tools) uses uname -r to get the Kernel version.
I'm not sure why I opted for that (it's been quite some years) my guess is that the Kernel version is probably not always passed to the hooks and therefore it would run without a version.
Therefore useing uname -r at least will create something for the currently running kernel.
Not sure if that's still required.
There are two scripts actually. One when you install a NEW kernel, that one will use the version of the new Kernel, and the hook for initramfs, which currently takes uname -r instead.
I could probably change this, by testing first if a version was passed and only then use uname -r but hey, as I said, the script is serveral years old.

You can however trigger:

Code: Select all

/etc/kernel/postinst.d/uInitrd 4.9.241-arm64

which does the same just with the correct version.
Or copy the already existing uInitrd-4.9.241-arm64 to uInitrd manually.

gom · Post by **gom** » Fri Jan 22, 2021 4:55 am

meveric wrote: ↑
Fri Jan 22, 2021 4:37 am
yep.. the hook for uInitrd (for initramfs-tools) uses uname -r to get the Kernel version.
I'm not sure why I opted for that (it's been quite some years) my guess is that the Kernel version is probably not always passed to the hooks and therefore it would run without a version.
Therefore useing uname -r at least will create something for the currently running kernel.
Not sure if that's still required.
There are two scripts actually. One when you install a NEW kernel, that one will use the version of the new Kernel, and the hook for initramfs, which currently takes uname -r instead.
I could probably change this, by testing first if a version was passed and only then use uname -r but hey, as I said, the script is serveral years old.

You can however trigger:
Code: Select all
/etc/kernel/postinst.d/uInitrd 4.9.241-arm64
which does the same just with the correct version.
Or copy the already existing uInitrd-4.9.241-arm64 to uInitrd manually.

i tried /etc/kernel/postinst.d/uInitrd 4.9.241-arm64 and cp /boot/uInitrd-4.9.241-arm64 /boot/uInitrd
and when i reboot i get
~$ uname -a
Linux hc4 4.9.236-arm64 #1 SMP PREEMPT Sun Dec 20 21:57:12 CET 2020 aarch64 GNU/Linux

meveric · Post by **meveric** » Fri Jan 22, 2021 5:32 am

well uInitrd is "just" the initramfs not the Kernel itself, that is the Image file that I explained earlier.
I'd say easiest is to reinstall the Kernel and see what happens:

Code: Select all

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

or copy the vmlinuz file as I said earlier.

gom · Post by **gom** » Fri Jan 22, 2021 7:22 am

doing "apt install --reinstall linux-image-4.9.241-arm64" worked
/boot/Image.gz got updated
we just have to remember to "cp /boot/uInitrd<NEW_VERSION> /boot/uInitrd" whenever the kernel is updated

Arm420 · Post by **Arm420** » Fri Jan 22, 2021 6:08 pm

Just want to say a big Thank You for all the work you’ve done for the buster on C4.
I’ll post up some amazing stats after I get 2-3 days of running with these latest dialed-in settings.

Peace, Love and Crypto!

meveric · Post by **meveric** » Fri Jan 22, 2021 6:16 pm

gom wrote: ↑
Fri Jan 22, 2021 7:22 am
we just have to remember to "cp /boot/uInitrd<NEW_VERSION> /boot/uInitrd" whenever the kernel is updated

nope you don't that should be done automatically as well

gom · Post by **gom** » Sat Jan 23, 2021 10:36 am

i am using your debian image on my hc4
i read up on getting the oled working
i'm always a bit put off with all the python bs
there is a c library at https://github.com/stealthylabs/libssd1306 that works quite well
lots of examples
i am using it to display the date and time
i hope this helps a little

meveric · Post by **meveric** » Sat Jan 23, 2021 5:57 pm

gom wrote: ↑
Sat Jan 23, 2021 10:36 am
i am using your debian image on my hc4
i read up on getting the oled working
i'm always a bit put off with all the python bs
there is a c library at https://github.com/stealthylabs/libssd1306 that works quite well
lots of examples
i am using it to display the date and time
i hope this helps a little

Thanks a lot.
I'll look into it, if that's true, I'd also prefer this over the python solution, as that one is very messy.

Edit:
Getting the driver working was easy, but the display seems upside down, so it seems to require a rotation.
I've seen there's ssd1306_framebuffer_put_pixel_rotation which should allow for rotation of the display, but I wonder if it's possible to change the driver itself to do the rotation by default.

Would you mind sharing your code for the clock? I know the example code already has a clock but I'd like to see what you did.

Also not sure how much you worked with it yet.
Have you tried creating a binary that displays everything you pipe into it to the display?

gom · Post by **gom** » Sat Jan 23, 2021 9:53 pm

this is all i've done so far

meveric · Post by **meveric** » Sat Jan 23, 2021 11:41 pm

looks pretty simular to the default clock just with added date.

I currently ended up with this one:

output.c: (2.17 KiB) Downloaded 16 times

Which can output a text that you add as an argument.
I don't like how the fonts are displayed though.
Only capital letters look ok.
Small letters "float" up which looks terrible.

gom · Post by **gom** » Sun Jan 24, 2021 12:37 am

i seems that the display in the hc4 is "upside down"
it makes it more difficult
if you want to display text from stdin take a look at "man 3 ev"
there's an example program that does that
i have not tried it
right now got other fish to fry and it stopped raining for a bit
got a 1986 diesel truck with injection pump problems

hungphutho · Post by **hungphutho** » Sun Jan 24, 2021 3:35 pm

Hc4 I installed this rom on the sdcard and waited for about 45 minutes, still not finished, not yet rebooted.
Has anyone suffered this problem ?

meveric · Post by **meveric** » Sun Jan 24, 2021 4:12 pm

The first boot shouldn't take longer than a minute, most likely less.

hungphutho · Post by **hungphutho** » Sun Jan 24, 2021 4:28 pm

meveric wrote: ↑
Sun Jan 24, 2021 4:12 pm
The first boot shouldn't take longer than a minute, most likely less.

Strange, I waited 1 hour still failed, I tried 3 sandisk class 10 sdcard cards with the same results.
finally I tried kernel 4.9.241 on rom dietpi to / boot on your rom, then it booted up successfully.

will you release images with 4.9.241 kernel?

: Screenshot from 2021-01-24 14-28-17.png (93.19 KiB) Viewed 1087 times

meveric · Post by **meveric** » Sun Jan 24, 2021 4:36 pm

I can update the Kernel on the base image, but generally I don't update the base image that often, as you can update the image via apt after the boot.
Doesn't make much sense to update the entire image only cause a Kernel was updated.
But if it has issues with the older Kernel I'll consider it.

hungphutho · Post by **hungphutho** » Sun Jan 24, 2021 5:37 pm

meveric wrote: ↑
Sun Jan 24, 2021 4:36 pm
I can update the Kernel on the base image, but generally I don't update the base image that often, as you can update the image via apt after the boot.
Doesn't make much sense to update the entire image only cause a Kernel was updated.
But if it has issues with the older Kernel I'll consider it.

after i decompiled your hc4 dtb i found the cause that my hc4 failed to boot successfully.
That is the commitment below. https://github.com/hardkernel/linux/com ... 128d352763
i have compiled new dtb and it works on your base image.
You can update your base image.
I will use your image. Thank you very much

: Screenshot from 2021-01-24 15-34-55.png (96.5 KiB) Viewed 1075 times

Jhonny14 · Post by **Jhonny14** » Sun Jan 24, 2021 10:39 pm

Is it possible to usa it for the c4? as once i tried but it did not work

meveric · Post by **meveric** » Mon Jan 25, 2021 1:43 am

The image is for both the C4 and the HC4.
The above change was only for the HC4 as they removed the eMMC from the device, as it doesn't have an eMMC.

klippe · Post by **klippe** » Thu Jan 28, 2021 4:37 am

Hi guys,

I'm setting up my newly bought HC4. So far I've net-installed Debian with no issues at all (awesome!) but can't make the OLED work. It's off all the time. I'm not sure if it's broken (hardware issue) or if I need to do something specific to make it work. I've followed instructions above and successfully installed the odroid-homecloud-display package but it changed nothing - OLED is still off.

So my questions basically is if the OLED should show anything in petitboot or with the fresh Debian install? I'm wondering if I should request replacement of the device.

klippe · Post by **klippe** » Thu Jan 28, 2021 8:04 am

klippe wrote: ↑
Thu Jan 28, 2021 4:37 am
So my questions basically is if the OLED should show anything in petitboot or with the fresh Debian install? I'm wondering if I should request replacement of the device.

Replying to myself. I've tried with Ubuntu and there the odroid-homecloud-display worked as expected - so at least I know the hardware is ok.

meveric · Post by **meveric** » Thu Jan 28, 2021 8:22 am

if you used the net-install Debian from @tobetter you should post that question in his forum section.
This is a different version of Debian not installed by net-installer.
I will provide a package with just the driver: libssd1306 which allows you to write your own software for the device, and maybe with one or two example tools.
But that one is C based and not python like the odroid-homecloud-display package.

klippe · Post by **klippe** » Thu Jan 28, 2021 8:45 am

meveric wrote: ↑
Thu Jan 28, 2021 8:22 am
if you used the net-install Debian from @tobetter you should post that question in his forum section.
This is a different version of Debian not installed by net-installer.

Ouch. I indeed haven't noticed those are two different versions of Debian. Will ask in an other place. Thanks!

tukan · Post by **tukan** » Mon Feb 01, 2021 9:54 pm

meveric wrote: ↑
Fri Jan 22, 2021 6:16 pm

gom wrote: ↑
Fri Jan 22, 2021 7:22 am
we just have to remember to "cp /boot/uInitrd<NEW_VERSION> /boot/uInitrd" whenever the kernel is updated
nope you don't that should be done automatically as well

Hi Meveric,

Thank you for your Debian Buster image for O-C4.

I have encountered the upgrade issue too. I think the core of the issue is that the /boot partition is vfat, which lead me here. Why are you using vfat partition? Due to windows compatibility? The U-boot should support the ext4 /boot partition for some time already.

Maybe it would be a good time to change the /boot to ext4?

The issue I encountered was connected to the vfat:

ln: failed to create hard link '/boot/initrd.img-4.9.241-arm64.dpkg-bak' => '/boot/initrd.img-4.9.241-arm64': Operation not permitted.
This is well known issue that update-initramfs fails with /boot on FAT filesystem.

Due the fact that the dpkg requirenments are:

Q: What are the filesystem requirements by dpkg?
A: The filesystems are expected to have POSIX semantics.

dpkg expects to operate on filesystems that support at least:

hardlinks (163988, 825945),

symlinks,
returning the symlink length in stat(2) st_size,

file-region locking (fcntl(2) with F_SETLK; 134591, 149491),

replacing files currently open (and being executed) (with rename(2)).

renaming directories atomically inside the same parent directory (with rename(2))

As such, filesystems like FAT32 or AFS are not supported for dpkg managed content.

If you are installing on a NFS root, and locking does not work, make sure rpc.lockd (or its equivalent) is running.

If you need a FAT32 partition to boot with EFI for example, then you should use something like /boot/efi/ to mount the FAT32 partition there, which will not be managed by dpkg, and use kernel postinst hooks to copy any required files, in a similar way as would be done to create an initramfs.

meveric · Post by **meveric** » Mon Feb 01, 2021 10:05 pm

tukan wrote: ↑
Mon Feb 01, 2021 9:54 pm
I have encountered the upgrade issue too. I think the core of the issue is that the /boot partition is vfat, which lead me here. Why are you using vfat partition? Due to windows compatibility? The U-boot should support the ext4 /boot partition for some time already.

Yes mainly for legacy and windows compatibility reasons.

tukan wrote: ↑
Mon Feb 01, 2021 9:54 pm
Maybe it would be a good time to change the /boot to ext4?

Maybe on the next major image with Bullseye.

tukan wrote: ↑
Mon Feb 01, 2021 9:54 pm
The issue I encountered was connected to the vfat:

ln: failed to create hard link '/boot/initrd.img-4.9.241-arm64.dpkg-bak' => '/boot/initrd.img-4.9.241-arm64': Operation not permitted.
This is well known issue that update-initramfs fails with /boot on FAT filesystem.

This is not really an issue.
The creation of initrd.img works fine, only the creation of a backup doesn't work.
But since initrd.img is not even used, but instead uInitrd which once again exists twice as uInitrd and as uInitrd-<version>, having this extra layer of backups, has no real extra value.
The setup continues, this is not a critical error, I use it since 2012 without issues on ODROIDs.

Moving to ext4 would work, you basically just tell everyone using Windows to suck it up as they can't configure boot.ini anymore or couldn't repair boot by coping backups from older kernel version, which currently would work, but not when you use ext4 (unless your Windows allows you to mount and work on ext4 partitions).

tukan · Post by **tukan** » Mon Feb 01, 2021 11:00 pm

meveric wrote: ↑
Mon Feb 01, 2021 10:05 pm

tukan wrote: ↑
Mon Feb 01, 2021 9:54 pm
I have encountered the upgrade issue too. I think the core of the issue is that the /boot partition is vfat, which lead me here. Why are you using vfat partition? Due to windows compatibility? The U-boot should support the ext4 /boot partition for some time already.
Yes mainly for legacy and windows compatibility reasons.

I see. For that it works, only you have to fsck the vfat (I see you have done that in boot.ini).

tukan wrote: ↑
Mon Feb 01, 2021 9:54 pm
Maybe it would be a good time to change the /boot to ext4?
Maybe on the next major image with Bullseye.

It is just food for thought. It is always a question benefits/what you lose.

tukan wrote: ↑
Mon Feb 01, 2021 9:54 pm
The issue I encountered was connected to the vfat:

ln: failed to create hard link '/boot/initrd.img-4.9.241-arm64.dpkg-bak' => '/boot/initrd.img-4.9.241-arm64': Operation not permitted.
This is well known issue that update-initramfs fails with /boot on FAT filesystem.
This is not really an issue.
The creation of initrd.img works fine, only the creation of a backup doesn't work.
But since initrd.img is not even used, but instead uInitrd which once again exists twice as uInitrd and as uInitrd-<version>, having this extra layer of backups, has no real extra value.
The setup continues, this is not a critical error, I use it since 2012 without issues on ODROIDs.

Moving to ext4 would work, you basically just tell everyone using Windows to suck it up as they can't configure boot.ini anymore or couldn't repair boot by coping backups from older kernel version, which currently would work, but not when you use ext4 (unless your Windows allows you to mount and work on ext4 partitions).

The creation of initrd.img works fine that is without issues. I had to manually copy the cp uInitrd-4.9.241-arm64 uInitrd and cp vmlinuz-4.9.241-arm64 Image.gz. The new image was created as Image.gz.bak and was at /boot. For experienced user that is no big deal, but for beginner that could be an issue.

vfat is more compatible that goes without saying. The issue there is that you have to be able to deal with the issues having /boot on unsupported filesystem. In the end, it is up to you to decide which way you like it more; I just wanted to warn about the issues I have encountered and perhaps how to deal with them (which you probably knew).

There is no native way to read ext4 on Windows. The things are improving. You could do it via WSL or WSL2 or using a dedicated driver for that. I'm using linux-reader from Sysinternals for the ext4 on Windows (I had some issues with ext2fsd)

Thank you again for your work on this!

meveric · Post by **meveric** » Tue Feb 02, 2021 12:26 am

tukan wrote: ↑
Mon Feb 01, 2021 11:00 pm
The creation of initrd.img works fine that is without issues. I had to manually copy the cp uInitrd-4.9.241-arm64 uInitrd and cp vmlinuz-4.9.241-arm64 Image.gz. The new image was created as Image.gz.bak and was at /boot. For experienced user that is no big deal, but for beginner that could be an issue.

That part has absolutely nothing to do with vfat or the initrd.img error. It is totally unrelated.

It is an issue, that is true and I'll investigate what is causing this, but once again, unrelated to the issue with vfat.

tukan · Post by **tukan** » Tue Feb 02, 2021 5:20 pm

meveric wrote: ↑
Tue Feb 02, 2021 12:26 am

tukan wrote: ↑
Mon Feb 01, 2021 11:00 pm
The creation of initrd.img works fine that is without issues. I had to manually copy the cp uInitrd-4.9.241-arm64 uInitrd and cp vmlinuz-4.9.241-arm64 Image.gz. The new image was created as Image.gz.bak and was at /boot. For experienced user that is no big deal, but for beginner that could be an issue.
That part has absolutely nothing to do with vfat or the initrd.img error. It is totally unrelated.

It is an issue, that is true and I'll investigate what is causing this, but once again, unrelated to the issue with vfat.

Yes, this issue is unrelated to vfat.

The related error to vfat I got when updating kernel (written above with the links):
ln: failed to create hard link '/boot/initrd.img-4.9.241-arm64.dpkg-bak' => '/boot/initrd.img-4.9.241-arm64': Operation not permitted.

You can't create hard link on vfat.

meveric · Post by **meveric** » Tue Feb 02, 2021 5:28 pm

I know. Still not an issue as it does not affect the system.

tukan · Post by **tukan** » Tue Feb 02, 2021 6:23 pm

meveric wrote: ↑
Tue Feb 02, 2021 5:28 pm
I know. Still not an issue as it does not affect the system.

I think we are running in circles. There are two separate issues.

1) It currently does not affect the system as have the vfat, but it would if you would adapt it to ext4.

2) The current system with vfat sufferers from similar issue which causes the newest kernel/initrd not to be copied over.

meveric · Post by **meveric** » Tue Feb 02, 2021 9:03 pm

tukan wrote: ↑
Tue Feb 02, 2021 6:23 pm
1) It currently does not affect the system as have the vfat, but it would if you would adapt it to ext4.

Even with ext4 it would not affect the system. The symlink that is created is a safety net, due to the fact that on x86 systems initrd.img is loaded through grub you want to make sure it's always available.
And if during the update of initrd.img the file is damaged you're happy to have a backup.
On ARM systems this doesn't matter. We don't have grub, we don't load initrd.img.. If it's damaged, or even deleted, it will still work fine, as it's loading the uInitrd instead and not the initrd.img file.
Therefore a backup of it doesn't matter and doesn't affect the system if it's there or not, no matter the filesystem you're using.

tukan wrote: ↑
Tue Feb 02, 2021 6:23 pm
2) The current system with vfat sufferers from similar issue which causes the newest kernel/initrd not to be copied over.

That's not a similar issue, but as I said unrelated. Copying files on vfat is not a problem we're using this method for many years already.
Something else caused this issue and that needs to be investigated.

tobetter wrote: ↑
Tue Feb 02, 2021 6:27 pm
I am wondering if you have the package flash-kernel? This must be creating the copy of 'initrd.gz' in the /boot directory.

I'm using flash-kernel on the N1 where it works perfectly fine, and I prepared it for the C4 and other devices by renaming the Kernel to have to correct naming syntax.
Still I'm not using it yet, as it requires ext4 to work and I need to find a good way to update the required files where needed.

gerdroesser · Post by **gerdroesser** » Wed Feb 10, 2021 12:53 am

Hello there! Thank you for the image.
I wanted to use it for OMV an a HC4 without a desktop, of course.
I've downloaded the image and flashed it to a 120GB sata SSD. I can make it boot from petitboot and work on the shell via ssh.
But when I try to apt update and upgrade the system, it tells me, that the filesystem ist too small.
So I tried to expand the filesystem but then it tells me that the fs already is expanded to the max size.

Can anybody tell me what to do now...? But be patient with me, since I'm a noob...
I come from the raspi, where many things are easier and therefore I'm anything but a pro...

Edit: I did it!!!

I just changed a partition table manually for the very first time!!! And the system is still alive...

meveric · Post by **meveric** » Wed Feb 10, 2021 2:51 am

The image was designed with eMMC/SD Card in mind.
On first boot it deletes the secondary partition (which was kept minimum to keep the image small) and recreates it with the the same starting sector but with the full size of the device.
Then it does a resize2fs to increase the partition to the full size.

I recon the automation fails on the SSD as it checks for eMMC/SD card instead.
Still you could technically do the same.

start fsdisk with your SSD (e.g. fdisk /dev/sda)
then check the output of "p" -> print partition table.
Note down the start of the second partition.
press d to delete a partition, and delete the second partition.
then press "n" to create a new partition.
We want a primary partition which will be partition 2 again.
Make sure the STARTING sector is the same as it was previously, even if it suggests otherwise.
Then the ending sector is the rest of the available sectors.
press "w" for writing the new partition table and reboot the system... after a reboot run resize2fs /dev/sda2 and it should resize the partition to the fill size of the SSD.

gerdroesser · Post by **gerdroesser** » Wed Feb 10, 2021 3:21 am

Thank you very much for your help!
I found this: https://unix.stackexchange.com/question ... mmand-line
It is quite the same as your reply. And I made it. I was so exited, but the system is still alive and I learned something new...

meveric · Post by **meveric** » Wed Feb 10, 2021 4:45 am

glad it was working

astraluma · Post by **astraluma** » Mon Mar 01, 2021 3:40 am

Hm. It looks like a package update broke something important?

One day I noticed my HC4 wasn't responding to anything, I ended up not investigating and just leaned harder on the synology I had inherited since buying the HC4.

Decided today to dig into it.

Flashed a fresh image to the SD card. SSH'd in, ran the apt upgrade & reboot process. Now it's not answering the network.

This is headless, didn't bother to install a DE. (Will try with a DE after posting, just to see.) (Suggestion: Have it do the normal Linux thing and do a VT on HDMI by default?)

Still don't own a serial adapter (I should really get one of those.)

meveric · Post by **meveric** » Mon Mar 08, 2021 4:47 am

Update:
I've updated the base image, since some user encountered issues updating the Kernel and apparently there were some issues in Kernel 4.9.236.
The image now comes with Kernel 4.9.241 out of the box.