Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HC1/2 | Won't boot if serial console is disabled #2038

Closed
Kdcarrero opened this Issue Aug 26, 2018 · 12 comments

Comments

Projects
None yet
3 participants
@Kdcarrero
Copy link

Kdcarrero commented Aug 26, 2018

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 Fourdee self-assigned this Aug 26, 2018

@Fourdee Fourdee added this to the v6.15 milestone Aug 26, 2018

@Fourdee

This comment has been minimized.

Copy link
Collaborator

Fourdee commented Aug 26, 2018

@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

This comment has been minimized.

Copy link
Collaborator

Fourdee commented Aug 26, 2018

@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.

@Kdcarrero

This comment has been minimized.

Copy link
Author

Kdcarrero commented Aug 26, 2018

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

@Fourdee

This comment has been minimized.

Copy link
Collaborator

Fourdee commented Aug 26, 2018

@Kdcarrero

Confirmed on HC1, looking into it now.

@Fourdee

This comment has been minimized.

Copy link
Collaborator

Fourdee commented Aug 26, 2018

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

This comment has been minimized.

Copy link
Collaborator

Fourdee commented Aug 27, 2018

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 pushed a commit that referenced this issue Aug 27, 2018

Daniel (Fourdee)
v6.15
+ Fix for HC1/2 serial required: #2038 (comment)

+ Disable fake-hwclock removal for now, need a better scrape/detection.
@Fourdee

This comment has been minimized.

Copy link
Collaborator

Fourdee commented Aug 27, 2018

@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.

@Fourdee Fourdee changed the title HC2 won't reconnect to network after 6.14 update HC1/2 | Won't boot if serial console is disabled Aug 27, 2018

@Kdcarrero

This comment has been minimized.

Copy link
Author

Kdcarrero commented Aug 27, 2018

Okay, I will test it later this afternoon.

Thank you

@MichaIng

This comment has been minimized.

Copy link
Owner

MichaIng commented Aug 27, 2018

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

This comment has been minimized.

Copy link
Collaborator

Fourdee commented Aug 27, 2018

@MichaIng

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

Same results as the sparky one: #2014 (comment)

@Kdcarrero

This comment has been minimized.

Copy link
Author

Kdcarrero commented Aug 27, 2018

@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

This comment has been minimized.

Copy link
Collaborator

Fourdee commented Aug 27, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.