Jump to content

[SOLVED] Helios64 won't boot after latest update

barnumbirr

By barnumbirr
in Rockchip

 Share

Recommended Posts

barnumbirr

barnumbirr

Posted
Posted

Just applied the latest update to my Helios64, here is what apt reported:
  

The following packages will be upgraded:
  armbian-config armbian-firmware base-files device-tree-compiler file iproute2 libcairo2 libgnutls30 libgnutls30:armhf
  libmagic-mgc libmagic1 libnss-myhostname libpam-systemd libsystemd0 libudev1 linux-buster-root-current-helios64
  linux-dtb-current-rockchip64 linux-image-current-rockchip64 linux-u-boot-helios64-current systemd systemd-sysv udev
  unzip

 

This went just fine until it tried to setup systemd, the Helios then lost all network connection:

  Reveal hidden contents

Tried rebooting, no luck. Can't get a serial console up and running as it won't go past 'Starting kernel...'

 

  Reveal hidden contents


The blue 'System' LED is on but doesn't blink. What can I do to help debug/fix this?

  • barnumbirr changed the title to Helios64 won't boot after latest update
  • barnumbirr changed the title to [SOLVED] Helios64 won't boot after latest update
slymanjojo

slymanjojo

Posted
Posted

I have the same issue after upgrading.......     stuAck in Starting Kernel;  all lights solid blue and no heart beat.

 

--snip--

Applying kernel provided DT fixup script (rockchip-fixup.scr)
## Executing script at 09000000
## Loading init Ramdisk from Legacy Image at 06000000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    13856663 Bytes = 13.2 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000
   Loading Ramdisk to f51af000, end f5ee5f97 ... OK
   Loading Device Tree to 00000000f5132000, end 00000000f51aefff ... OK

Starting kernel ...
--end snip-

 

Sorry if this is NOOB question; where can I find this armbianEnv.txt ?    when performing upgrades is this file backed up anywhere? 

 

How do I go about getting my system back online?

 

Any help would be much appreciated.  

SIGSEGV

SIGSEGV

Posted
Posted
  On 2/8/2021 at 3:51 AM, gprovost said:

@slymanjojo Is your install on microSD card or eMMC ?

Expand  

I'm having the same issue once Armbian gets installed to eMMC using the armbian-config tool [Armbian 21.02.1 Focal]

Boots fine with the image on the microSD card, but it won't finish booting when on the eMMC (all lights solid blue and no heart beat).

FloBaoti

FloBaoti

Posted
Posted

Here is mine (not yet upgraded) :

 

  Quote

verbosity=1
bootlogo=false
overlay_prefix=rockchip
rootdev=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

Expand  

 

Maybe problem could be on rootdev UUID ? For me it refers to /dev/mmcblk1p1

1
Gareth Halfacree

Gareth Halfacree

Posted
Posted

Thanks, @FloBaoti - my post-upgrade one looks like this:

  

verbosity=1
bootlogo=false
overlay_prefix=rockchip
rootdev=UUID=a213f2de-xxxxx-xxxxx-xxxxx-xxxxxxxxxx
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

 

The drive UUID, elided for privacy, refers to /dev/sda1 - which is the SATA SSD I've got the operating system installed on, with /dev/mmcblk1p1 being on a UUID starting b72a980c. In other words, everything looks fine - though I'm still hanging fire on a reboot to check that fact!

barnumbirr

barnumbirr

Posted
  • Author
Posted
  On 2/8/2021 at 3:51 AM, gprovost said:

@slymanjojo Is your install on microSD card or eMMC ?

Expand  

My system is on a microSD card as armbian-config never managed to configure the eMMC correctly (never took the time to debug the issue unfortunately).

My system did crash at some point while I was at work today but no logs have a trace of the crash. System just froze, solid blue 'System' LED.
I'll probably downgrade to an earlier kernel...

Eric Poscher-Mika

Eric Poscher-Mika

Posted
Posted

Same Trouble here: 

etckeeper reports:


    committing changes in /etc made by "apt dist-upgrade"
    
    Package changes:
    -armbian-firmware 20.11.3 all
    +armbian-firmware 21.02.1 all
    -cockpit 235-1~bpo10+1 all
    -cockpit-bridge 235-1~bpo10+1 arm64
    -cockpit-system 235-1~bpo10+1 all
    -cockpit-ws 235-1~bpo10+1 arm64
    +cockpit 237-1~bpo10+1 all
    +cockpit-bridge 237-1~bpo10+1 arm64
    +cockpit-system 237-1~bpo10+1 all
    +cockpit-ws 237-1~bpo10+1 arm64
    -linux-buster-root-current-helios64 20.11.6 arm64
    -linux-dtb-current-rockchip64 20.11.4 arm64
    +linux-buster-root-current-helios64 21.02.1 arm64
    +linux-dtb-current-rockchip64 21.02.1 arm64
    -linux-u-boot-helios64-current 20.11.6 arm64
    +linux-u-boot-helios64-current 21.02.1 arm64
    -syncthing 1.13.0~rc.1 arm64
    +syncthing 1.13.1 arm64

 

Alright, so the system boots, I can use the usbserial console. All filesystems mount properly.

But wait? /lib/modules is missing

Eric Poscher-Mika

Eric Poscher-Mika

Posted
Posted
  On 2/8/2021 at 1:50 PM, Gareth Halfacree said:

Thanks, @FloBaoti - my post-upgrade one looks like this:

  

verbosity=1
bootlogo=false
overlay_prefix=rockchip
rootdev=UUID=a213f2de-xxxxx-xxxxx-xxxxx-xxxxxxxxxx
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u

 

The drive UUID, elided for privacy, refers to /dev/sda1 - which is the SATA SSD I've got the operating system installed on, with /dev/mmcblk1p1 being on a UUID starting b72a980c. In other words, everything looks fine - though I'm still hanging fire on a reboot to check that fact!

Expand  

BTW

What kind of private data could a drive UUID disclose? Afaik it's random-generated when the partition table is created.

I don't think there is any need for that, but if you can explain why this makes sense, I'm interested!

FloBaoti

FloBaoti

Posted
Posted

UUID disk or partition is not private data for me, but everyone does what he want. We don't have to know Gareth's UUID do help.

 

Does anybody else have a problem after this upgrade ?

FloBaoti

FloBaoti

Posted
Posted

apt update only updates repository's package list (local cache). No package upgraded.

apt upgrade upgrades packages, there's no difference with "dist-upgrade" unless distribution new version (switch from Ubuntu 20.04 to Ubuntu 20.10 for example).

Gareth Halfacree

Gareth Halfacree

Posted
Posted
  On 2/10/2021 at 7:40 AM, Eric Poscher-Mika said:

What kind of private data could a drive UUID disclose?

Expand  

The UUID itself is a universally unique identifier - that's what UUID means, after all. There are a wide range of scenarios where public knowledge of the UUID could be a problem, all absolutely vanishingly unlikely - think things like "state-level actors falsifying evidence about what data they found on a system and using their knowledge of the drive's UUID as 'proof' that the evidence was legitimately collected instead of just made up from whole cloth."

 

Given it takes a whopping four seconds to elide the UUID, and absence of the UUID has zero impact on diagnosing the problem, why wouldn't I keep it private?

 

Back on topic: I still haven't rebooted since the update. Would I be safe to do so, or shall I keep on truckin' until we're closer to figuring out the root cause of the issue?

TRS-80

TRS-80

Posted
Posted
  On 2/10/2021 at 7:54 AM, FloBaoti said:

apt upgrade upgrades packages, there's no difference with "dist-upgrade" unless distribution new version (switch from Ubuntu 20.04 to Ubuntu 20.10 for example).

Expand  

 

Did not read the whole thread, but isn't dist-upgrade unsupported on Armbian (due to all the variations of boot loaders, hardware, etc.)?

slymanjojo

slymanjojo

Posted
Posted
  On 2/8/2021 at 3:51 AM, gprovost said:

@slymanjojo Is your install on microSD card or eMMC ?

Expand  

Yes,  Boot Device eMMC ,  System/Rootfs  using SATA drive.

 

For some reason I was not able to recover using my previous SDcard;  Downloaded latest build and rebooted without issue: from SDcard.

I ended up resolving my issue by running armbian-config and moved boot and system onto the eMMC.  I did not want to go through the reformatting of my SATA drive.

(no option using tool to install without reformatting)

This permitted me to mount and access the older rootfs and copy over my fstab, smb.conf etc... over to the new location eMMC.

 

There was probably an easier solution? possibly just re-create this armbianEnv.txt and  point my rootfs back to my SATA drive.

Not knowing the integrity of what failed during the upgrade...  I did notice a wack of missing files. during the upgrade.

 

I had to act fast; I was not anticipating to have any issues with this upgrade.   

 

Thanks for all your replies....     I will admit I was caught with my pants down.   

 

Curious; What would be the suggested method to move my rootfs back to my SATA drive without reformatting

(currently ext4)??  basically go back to my initial config with boot on eMMC and rootfs on SATA.  

 

Thanks in advance.

slymanjojo

slymanjojo

Posted
Posted
  On 2/8/2021 at 6:08 AM, SIGSEGV said:

I'm having the same issue once Armbian gets installed to eMMC using the armbian-config tool [Armbian 21.02.1 Focal]

Boots fine with the image on the microSD card, but it won't finish booting when on the eMMC (all lights solid blue and no heart beat).

Expand  

 

Note: I used the armbian-config tool on Buster.   with the  same outcome.

slymanjojo

slymanjojo

Posted
Posted
  On 2/8/2021 at 9:17 AM, FloBaoti said:

Here is mine (not yet upgraded) :

 

 

Maybe problem could be on rootdev UUID ? For me it refers to /dev/mmcblk1p1

Expand  

Interesting my differs with the added usb quirks:

verbosity=1
bootlogo=false
overlay_prefix=rockchip
rootdev=UUID=e31a658f-424d-4411-9c4d-e96f42117d3f
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x0bc2:0x331a:u,0x0bc2:0x3322:u,0x0bc2:0xab38:u,0x0bc2:0xab44:u,0x0bc2:0xab45:u
 

edraket

edraket

Posted
Posted

Also having the same issue.

Is there a way to discover the UUID of the rootdev without the system being able to boot?

Running from SD card.

aprayoga

aprayoga

Posted
Posted
  On 2/10/2021 at 9:34 AM, Gareth Halfacree said:

The UUID itself is a universally unique identifier - that's what UUID means, after all. There are a wide range of scenarios where public knowledge of the UUID could be a problem, all absolutely vanishingly unlikely - think things like "state-level actors falsifying evidence about what data they found on a system and using their knowledge of the drive's UUID as 'proof' that the evidence was legitimately collected instead of just made up from whole cloth."

 

Given it takes a whopping four seconds to elide the UUID, and absence of the UUID has zero impact on diagnosing the problem, why wouldn't I keep it private?

 

Back on topic: I still haven't rebooted since the update. Would I be safe to do so, or shall I keep on truckin' until we're closer to figuring out the root cause of the issue?

Expand  

Did you see any error during upgrade? If there is no error, then it should be safe to reboot.

 

  On 2/10/2021 at 8:29 PM, slymanjojo said:

Curious; What would be the suggested method to move my rootfs back to my SATA drive without reformatting

(currently ext4)??  basically go back to my initial config with boot on eMMC and rootfs on SATA.  

 

Thanks in advance.

Expand  

There is no automated method that i'm aware of.

You could modify the rootdev=UUID= to point to UUID of the SATA partition.

Modify /etc/fstab on the SATA drive, find line with /media/mmcboot , change the existing UUID to UUID of the eMMC

 

 

  On 2/12/2021 at 8:43 PM, edraket said:

Also having the same issue.

Is there a way to discover the UUID of the rootdev without the system being able to boot?

Running from SD card.

Expand  

sudo blkid

use the value of UUID not PARTUUID

 

 

clostro

clostro

Posted
Posted

Just did an in place upgrade with armbian-config (was running the previous build with static cpu freq for 23 days stably), it all works fine after a reboot. Wanted to report results.

Few things -

-After armbian-config upgrade and reboot, there still were packages not up to date, had to run apt again.

-The firewalld zone didn't come up on its own, but the firewall was working as configured. I'm confused about that one. It came back up after I restarted the firewalld service I think.

-And the weirdest thing is that the zram1 log was full 100%. armbian-ramlog service was failing and wouldn't work properly until I manually deleted /var/log/pcp* since it was the one hogging all the space.

 

Did test the 2.5G adapter with crystaldisk on Windows client a few times, which would previously crash eth1 (sometimes near instant death), and so far it works fine.

Did some iperf3 tests, and I am getting +1.9gbps on one side and +2.2gbps on the other with 'ethtool -K eth1 rx off tx on'

 

edit: forgot about the eth0, it wouldn't show up in ifconfig after the update. Not sure what happened about that one since the cockpit interface shows it just fine, just not configured. It may have been me toying around with it before the update. I might have cloned its MAC address so it would get the same IP as the eth1 from pihole dhcp, really can't remember.

slymanjojo

slymanjojo

Posted
Posted
  On 2/15/2021 at 2:33 AM, aprayoga said:

Did you see any error during upgrade? If there is no error, then it should be safe to reboot.

 

There is no automated method that i'm aware of.

You could modify the rootdev=UUID= to point to UUID of the SATA partition.

Modify /etc/fstab on the SATA drive, find line with /media/mmcboot , change the existing UUID to UUID of the eMMC

 

 

sudo blkid

use the value of UUID not PARTUUID

 

 

Expand  

@aprayoga Thanks for the feedback.   I've left everything (rootdev) on the eMMC for now.   

I  was contemplating installing omv; Is there enough space on eMMC ??  I assume omv is installed as a service and I could move it and use a symbolic link.

 

gprovost

gprovost

Posted
Posted
  On 2/21/2021 at 5:01 PM, slymanjojo said:

I  was contemplating installing omv; Is there enough space on eMMC ??  I assume omv is installed as a service and I could move it and use a symbolic link.

Expand  

 

Yes there is enough space to install OMV on eMMC.

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept