Dietpi: HC1/2 | Won't boot if serial console is disabled

[Meateor553]

Required Information:

• DietPi version | 6.13 -> 6.14
• SBC device | Odroid HC2
• Power supply used | 12V 2A
• SDcard used | Samsung Evo 32GB microSD

Steps to reproduce:

1. Install dietpi 6.13 for the HC2 at the dietpi download page
2. Go through the first time installation steps (or if you're on a server running 6.13 already, just update to 6.14)
3. Update completes successfully, reboots the system
4. HC2 turns on, drives spin, never connects to the network again (unable to ssh. HC2 is permanently headless)

Expected behaviour:

• Update should complete, reboot, and dietpi should function normally

Actual behaviour:

• Unable to ssh, no services (like emby) run on boot, doesn't connect to the network.

Extra details:

• Originally I thought this was due to me having moved my rootfs to be on an HDD instead of the sd card. When I first just ran the upgrade I was able to ssh in after setting the boot.ini to point back to the sd card partition for rootfs. However, after editing the fstab file to mount my HDD again and setting it as the rootfs, I was then refused ssh connection every time I tried.

• Now I've tried a fresh install, but the hc2 installer on the dietpi website is still 6.13. During the install it notices the 6.14 update and applies it automatically. But upon rebooting I can't ssh back into the server to complete the installation because it won't re-connect to the network. This has to be some issue being caused by the update, but I can't seem to keep the installer from applying it.

• I have a backup of 6.13 before the update, but I have no way of applying it now.

[Fourdee]

@Kdcarrero

Thanks for the report 👍

The only thing I can suspect is a kernel upgrade (via APT) is completed during the initial DietPi update, which is possibly unstable.
Failing that, hardware issue due to unstable PSU/SD card etc.

I'll try to replicate on my HC1 (I lack the HC2, but should be the same).

[Fourdee]

@Kdcarrero

Power supply used | 5V 2A

~I suspect this is the issue, especially if any HDD is attached. Ideally this needs to be 5V/4A at least.~
Requires 12V/2A, please confirm this is what you are using.

[Meateor553]

It is using 12V 2A. Idk why I put 5V before

[Fourdee]

@Kdcarrero

Confirmed on HC1, looking into it now.

[Fourdee]

Serial:

ks=0x0eef:0x0005:0x0004"; fi
cfgload: setenv bootargs "${bootrootfs} ${videoconfig} smsc95xx.macaddr=${macaddr} governor=${governor} ${hdmi_phy_control} ${hid_quirks}"
cfgload: bootz 0x40008000 0x42000000 0x44000000
Kernel image @ 0x40008000 [ 0x000000 - 0x569a08 ]
## Loading init Ramdisk from Legacy Image at 42000000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (uncompressed)
   Data Size:    5302078 Bytes = 5.1 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 44000000
   Booting using the fdt blob at 0x44000000
   Using Device Tree in place at 44000000, end 4401291f

Starting kernel ...

#HANG

root=UUID=af314fbe-6db6-4970-84b4-19fd22bd6bf7
/dev/loop2p2: LABEL="rootfs" UUID="af314fbe-6db6-4970-84b4-19fd22bd6bf7" TYPE="ext4" PARTUUID="000f1766-02"

• No kernel upgrades via APT
• Assume possible faulty image?

[Fourdee]

Tests:

• 🈴 Redone image from pre-image of meveric
• 🈴 Recreate partition tables on image, after running PREP
• 🈴 Disable removal of fake-hwclock during 1st run (we need to disable this, or improve the scrape regardless)
• 🈯️ Prevent disable of serial TTY's
• Limit CPU max freq to 1GHz (Stability?) during 1st run.

[Fourdee]

@Kdcarrero

New image uploaded which resolves the failed boot issue:
https://dietpi.com/downloads/images/DietPi_OdroidXU4-ARMv7-Stretch.7z

I've tested here fine, however, please confirm its working for you.

[Meateor553]

Okay, I will test it later this afternoon.

Thank you

[MichaIng]

Strange, would be interesting what needs/uses the serial console and breaks boot, if not available.

hwclock: Hmm, I remember there is a socket on the port to plug a hardware clock battery. Maybe in those cases hwclock command dues not result in error code, but has some special output? If it's no difference to x86_64 available and powered hwclock, then indeed we cannot remove it, to be sure not even on x86_64!

@Kdcarrero @Fourdee
Any change one can install rsyslog, let the HC1/2 run into the boot error and then investigate logs on external machine? Maybe there is some service that needs serial console but the we don't need an can disable.
And what is the actual output of hwclock on this machine, with and without fake-hwclock installed?

[Fourdee]

@MichaIng

And what is the actual output of hwclock on this machine, with and without fake-hwclock installed?

Same results as the sparky one: https://github.com/Fourdee/DietPi/issues/2014#issuecomment-413518658

[Meateor553]

@Fourdee
It installed and can successfully reboot (tested a few times for posterity).

Very strange that that was the issue though. Thank you for the help!

[Fourdee]

@MichaIng

Any change one can install rsyslog, let the HC1/2 run into the boot error and then investigate logs on external machine? Maybe there is some service that needs serial console but the we don't need an can disable.

Good idea 👍, but I lack the time currently.

As the original issue is now resolved, I'll mark this as closed.

[MichaIng]

Could be retested with current Stretch image and console=ttySAC2,115200n8 removed from boot.ini.