barnumbirr Posted February 6, 2021 Posted February 6, 2021 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? 0 Quote
barnumbirr Posted February 6, 2021 Author Posted February 6, 2021 SOLVED!!! Of course this was due to armbianEnv.txt being corrupt. Restoring the file from backups allows the device to boot cleanly again. 1 Quote
slymanjojo Posted February 7, 2021 Posted February 7, 2021 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. 0 Quote
gprovost Posted February 8, 2021 Posted February 8, 2021 @slymanjojo Is your install on microSD card or eMMC ? 0 Quote
SIGSEGV Posted February 8, 2021 Posted February 8, 2021 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). 0 Quote
FloBaoti Posted February 8, 2021 Posted February 8, 2021 Is upgrade OK if we backup armbianEnv.txt & restore it after upgrade (before reboot) ? 0 Quote
Gareth Halfacree Posted February 8, 2021 Posted February 8, 2021 Could someone share a before/after of /boot/armbianEnv.txt? I've upgraded but not yet rebooted, and while my armbianEnv.txt *looks* normal I'm loath to reboot until I'm sure it *is* normal! 0 Quote
FloBaoti Posted February 8, 2021 Posted February 8, 2021 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 1 Quote
Gareth Halfacree Posted February 8, 2021 Posted February 8, 2021 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! 0 Quote
barnumbirr Posted February 8, 2021 Author Posted February 8, 2021 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... 0 Quote
Eric Poscher-Mika Posted February 10, 2021 Posted February 10, 2021 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 0 Quote
Eric Poscher-Mika Posted February 10, 2021 Posted February 10, 2021 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! 0 Quote
FloBaoti Posted February 10, 2021 Posted February 10, 2021 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 ? 0 Quote
Eric Poscher-Mika Posted February 10, 2021 Posted February 10, 2021 Maybe I shouldnt have run apt dist-upgrade only apt-update ?? Would apt-update also update the kernel, firmware etc.? 0 Quote
FloBaoti Posted February 10, 2021 Posted February 10, 2021 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). 0 Quote
Gareth Halfacree Posted February 10, 2021 Posted February 10, 2021 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? 0 Quote
TRS-80 Posted February 10, 2021 Posted February 10, 2021 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.)? 0 Quote
slymanjojo Posted February 10, 2021 Posted February 10, 2021 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. 0 Quote
slymanjojo Posted February 10, 2021 Posted February 10, 2021 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. 0 Quote
slymanjojo Posted February 10, 2021 Posted February 10, 2021 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 0 Quote
edraket Posted February 12, 2021 Posted February 12, 2021 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. 0 Quote
FloBaoti Posted February 13, 2021 Posted February 13, 2021 Maybe using a live system on USB ? 0 Quote
aprayoga Posted February 15, 2021 Posted February 15, 2021 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 0 Quote
clostro Posted February 16, 2021 Posted February 16, 2021 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. 0 Quote
slymanjojo Posted February 21, 2021 Posted February 21, 2021 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. 0 Quote
gprovost Posted February 22, 2021 Posted February 22, 2021 14 hours ago, 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. Yes there is enough space to install OMV on eMMC. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.