[SOLVED] Helios64 won't boot after latest update


Recommended Posts

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:

Spoiler






Fetched 57.9 MB in 1min 51s (523 kB/s)
Preconfiguring packages ...
(Reading database ... 62471 files and directories currently installed.)
Preparing to unpack .../base-files_10.3+deb10u8_arm64.deb ...
Unpacking base-files (10.3+deb10u8) over (10.3+deb10u7) ...
Setting up base-files (10.3+deb10u8) ...
Installing new version of config file /etc/debian_version ...
(Reading database ... 62471 files and directories currently installed.)
Preparing to unpack .../systemd-sysv_241-7~deb10u6_arm64.deb ...
Unpacking systemd-sysv (241-7~deb10u6) over (241-7~deb10u5) ...
Preparing to unpack .../libpam-systemd_241-7~deb10u6_arm64.deb ...
Unpacking libpam-systemd:arm64 (241-7~deb10u6) over (241-7~deb10u5) ...
Preparing to unpack .../libsystemd0_241-7~deb10u6_arm64.deb ...
Unpacking libsystemd0:arm64 (241-7~deb10u6) over (241-7~deb10u5) ...
Setting up libsystemd0:arm64 (241-7~deb10u6) ...
(Reading database ... 62471 files and directories currently installed.)
Preparing to unpack .../libnss-myhostname_241-7~deb10u6_arm64.deb ...
Unpacking libnss-myhostname:arm64 (241-7~deb10u6) over (241-7~deb10u5) ...
Preparing to unpack .../systemd_241-7~deb10u6_arm64.deb ...
Unpacking systemd (241-7~deb10u6) over (241-7~deb10u5) ...
Preparing to unpack .../udev_241-7~deb10u6_arm64.deb ...
Unpacking udev (241-7~deb10u6) over (241-7~deb10u5) ...
Preparing to unpack .../libudev1_241-7~deb10u6_arm64.deb ...
Unpacking libudev1:arm64 (241-7~deb10u6) over (241-7~deb10u5) ...
Setting up libudev1:arm64 (241-7~deb10u6) ...
(Reading database ... 62471 files and directories currently installed.)
Preparing to unpack .../00-libgnutls30_3.6.7-4+deb10u6_arm64.deb ...
De-configuring libgnutls30:armhf (3.6.7-4+deb10u5) ...
Unpacking libgnutls30:arm64 (3.6.7-4+deb10u6) over (3.6.7-4+deb10u5) ...
Preparing to unpack .../01-libgnutls30_3.6.7-4+deb10u6_armhf.deb ...
Unpacking libgnutls30:armhf (3.6.7-4+deb10u6) over (3.6.7-4+deb10u5) ...
Preparing to unpack .../02-iproute2_4.20.0-2+deb10u1_arm64.deb ...
Unpacking iproute2 (4.20.0-2+deb10u1) over (4.20.0-2) ...
Preparing to unpack .../03-file_1%3a5.35-4+deb10u2_arm64.deb ...
Unpacking file (1:5.35-4+deb10u2) over (1:5.35-4+deb10u1) ...
Preparing to unpack .../04-libmagic1_1%3a5.35-4+deb10u2_arm64.deb ...
Unpacking libmagic1:arm64 (1:5.35-4+deb10u2) over (1:5.35-4+deb10u1) ...
Preparing to unpack .../05-libmagic-mgc_1%3a5.35-4+deb10u2_arm64.deb ...
Unpacking libmagic-mgc (1:5.35-4+deb10u2) over (1:5.35-4+deb10u1) ...
Preparing to unpack .../06-unzip_6.0-23+deb10u2_arm64.deb ...
Unpacking unzip (6.0-23+deb10u2) over (6.0-23+deb10u1) ...
Preparing to unpack .../07-armbian-config_21.02.1_all.deb ...
Unpacking armbian-config (21.02.1) over (20.11.6) ...
Preparing to unpack .../08-armbian-firmware_21.02.1_all.deb ...
Unpacking armbian-firmware (21.02.1) over (20.11.3) ...
Preparing to unpack .../09-device-tree-compiler_1.4.7-4_arm64.deb ...
Unpacking device-tree-compiler (1.4.7-4) over (1.4.7-3) ...
Preparing to unpack .../10-libcairo2_1.16.0-4+deb10u1_arm64.deb ...
Unpacking libcairo2:arm64 (1.16.0-4+deb10u1) over (1.16.0-4) ...
Preparing to unpack .../11-linux-buster-root-current-helios64_21.02.1_arm64.deb ...
Unpacking linux-buster-root-current-helios64 (21.02.1) over (20.11.6) ...
Preparing to unpack .../12-linux-dtb-current-rockchip64_21.02.1_arm64.deb ...
Unpacking linux-dtb-current-rockchip64 (21.02.1) over (20.11.4) ...
Preparing to unpack .../13-linux-image-current-rockchip64_21.02.1_arm64.deb ...
update-initramfs: Deleting /boot/initrd.img-5.9.14-rockchip64
Removing obsolete file uInitrd-5.9.14-rockchip64
Unpacking linux-image-current-rockchip64 (21.02.1) over (20.11.4) ...
Preparing to unpack .../14-linux-u-boot-helios64-current_21.02.1_arm64.deb ...
Unpacking linux-u-boot-helios64-current (21.02.1) over (20.11.6) ...
Setting up linux-u-boot-helios64-current (21.02.1) ...
Setting up libmagic-mgc (1:5.35-4+deb10u2) ...
Setting up iproute2 (4.20.0-2+deb10u1) ...
Setting up unzip (6.0-23+deb10u2) ...
Setting up linux-image-current-rockchip64 (21.02.1) ...
update-initramfs: Generating /boot/initrd.img-5.10.12-rockchip64
update-initramfs: Converting to u-boot format
Setting up libmagic1:arm64 (1:5.35-4+deb10u2) ...
Setting up linux-buster-root-current-helios64 (21.02.1) ...
Setting up file (1:5.35-4+deb10u2) ...
Setting up libcairo2:arm64 (1.16.0-4+deb10u1) ...
Setting up armbian-config (21.02.1) ...
Setting up libgnutls30:arm64 (3.6.7-4+deb10u6) ...
Setting up libgnutls30:armhf (3.6.7-4+deb10u6) ...
Setting up linux-dtb-current-rockchip64 (21.02.1) ...
Setting up udev (241-7~deb10u6) ...
update-initramfs: deferring update (trigger activated)
Setting up libnss-myhostname:arm64 (241-7~deb10u6) ...
Setting up device-tree-compiler (1.4.7-4) ...
Setting up armbian-firmware (21.02.1) ...
Setting up systemd (241-7~deb10u6) ...
Timeout, server 10.0.1.100 not responding.

 

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

 

Spoiler





DDR Version 1.24 20191016
In
channel 0
CS = 0
MR0=0x18
MR4=0x1
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0x18
MR4=0x1
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
change freq to 416MHz 0,1
Channel 0: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
Channel 1: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
256B stride
channel 0
CS = 0
MR0=0x18
MR4=0x1
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0x18
MR4=0x1
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
channel 0, cs 0, advanced training done
channel 1, cs 0, advanced training done
change freq to 856MHz 1,0
ch 0 ddrconfig = 0x101, ddrsize = 0x40
ch 1 ddrconfig = 0x101, ddrsize = 0x40
pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD
ddr_set_rate to 328MHZ
ddr_set_rate to 666MHZ
ddr_set_rate to 928MHZ
channel 0, cs 0, advanced training done
channel 1, cs 0, advanced training done
ddr_set_rate to 416MHZ, ctl_index 0
ddr_set_rate to 856MHZ, ctl_index 1
support 416 856 328 666 928 MHz, current 856MHz
OUT
Boot1: 2019-03-14, version: 1.19
CPUId = 0x0
ChipType = 0x10, 253
SdmmcInit=2 0
BootCapSize=100000
UserCapSize=14910MB
FwPartOffset=2000 , 100000
mmc0:cmd5,20
SdmmcInit=0 0
BootCapSize=0
UserCapSize=30436MB
FwPartOffset=2000 , 0
StorageInit ok = 79880
SecureMode = 0
SecureInit read PBA: 0x4
SecureInit read PBA: 0x404
SecureInit read PBA: 0x804
SecureInit read PBA: 0xc04
SecureInit read PBA: 0x1004
SecureInit read PBA: 0x1404
SecureInit read PBA: 0x1804
SecureInit read PBA: 0x1c04
SecureInit ret = 0, SecureMode = 0
atags_set_bootdev: ret:(0)
GPT 0x3380ec0 signature is wrong
recovery gpt...
GPT 0x3380ec0 signature is wrong
recovery gpt fail!
LoadTrust Addr:0x4000
No find bl30.bin
No find bl32.bin
Load uboot, ReadLba = 2000
Load OK, addr=0x200000, size=0xe5674
RunBL31 0x40000
NOTICE:  BL31: v1.3(debug):42583b6
NOTICE:  BL31: Built : 07:55:13, Oct 15 2019
NOTICE:  BL31: Rockchip release version: v1.1
INFO:    GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
INFO:    Using opteed sec cpu_context!
INFO:    boot cpu mask: 0
INFO:    plat_rockchip_pmu_init(1190): pd status 3e
INFO:    BL31: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
ERROR:   Error initializing runtime service opteed_fast
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x200000
INFO:    SPSR = 0x3c9


U-Boot 2020.10-armbian (Jan 05 2021 - 00:07:57 +0100)

SoC: Rockchip rk3399
Reset cause: POR
DRAM:  3.9 GiB
PMIC:  RK808
SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
MMC:   mmc@fe320000: 1, sdhci@fe330000: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Model: Helios64
Revision: 1.2 - 4GB non ECC
Net:   eth0: ethernet@fe300000
scanning bus for devices...
starting USB...
Bus usb@fe380000: USB EHCI 1.00
Bus dwc3: usb maximum-speed not found
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fe380000 for devices... 1 USB Device(s) found
scanning bus dwc3 for devices... cannot reset port 4!?
4 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
3185 bytes read in 6 ms (517.6 KiB/s)
## Executing script at 00500000
Boot script loaded from mmc 1
259 bytes read in 5 ms (49.8 KiB/s)
15760887 bytes read in 672 ms (22.4 MiB/s)
28582400 bytes read in 1212 ms (22.5 MiB/s)
81843 bytes read in 12 ms (6.5 MiB/s)
Failed to load '/boot/dtb/rockchip/overlay/-fixup.scr'
Moving Image from 0x2080000 to 0x2200000, end=3de0000
## Loading init Ramdisk from Legacy Image at 06000000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    15760823 Bytes = 15 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 f4fe7000, end f5eeedb7 ... OK
   Loading Device Tree to 00000000f4f6a000, end 00000000f4fe6fff ... OK

Starting kernel ...

 


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

Link to post
Share on other sites
  • barnumbirr changed the title to Helios64 won't boot after latest update
Donate and support the project!

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

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.  

Link to post
Share on other sites
2 hours ago, gprovost said:

@slymanjojo Is your install on microSD card or eMMC ?

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

Link to post
Share on other sites

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

 

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

Link to post
Share on other sites

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!

Link to post
Share on other sites
12 hours ago, gprovost said:

@slymanjojo Is your install on microSD card or eMMC ?

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

Link to post
Share on other sites

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

Link to post
Share on other sites
Am 8.2.2021 um 14:50 schrieb Gareth Halfacree:

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!

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!

Link to post
Share on other sites

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

Link to post
Share on other sites
1 hour ago, Eric Poscher-Mika said:

What kind of private data could a drive UUID disclose?

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?

Link to post
Share on other sites
10 hours ago, 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).

 

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

Link to post
Share on other sites
On 2/7/2021 at 10:51 PM, gprovost said:

@slymanjojo Is your install on microSD card or eMMC ?

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.

Link to post
Share on other sites
On 2/8/2021 at 1: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).

 

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

Link to post
Share on other sites
On 2/8/2021 at 4:17 AM, FloBaoti said:

Here is mine (not yet upgraded) :

 

 

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

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
 

Link to post
Share on other sites
On 2/10/2021 at 4:34 PM, 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?

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

 

On 2/11/2021 at 3:29 AM, 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.

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/13/2021 at 3:43 AM, 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.

sudo blkid

use the value of UUID not PARTUUID

 

 

Link to post
Share on other sites

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.

Link to post
Share on other sites
On 2/14/2021 at 9:33 PM, 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

 

 

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

 

Link to post
Share on other sites