24.11.0-trunk armbian-install failure induced by old partition devices

[ozacas]

Hi,

 

A UEFI-ARM64 install of armbian opi5+ 24.11.0-trunk fails during armbian-install due to incorrect knowledge of partitions:

 

root@uefi-arm64:/usr/sbin# lsblk -l
NAME      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda         8:0    1  14.4G  0 disk 
sda1        8:1    1   256M  0 part /boot/efi
sda2        8:2    1  14.2G  0 part /var/log.hdd
                                    /
zram0     252:0    0   7.7G  0 disk [SWAP]
zram1     252:1    0    50M  0 disk /var/log
zram2     252:2    0     0B  0 disk 
nvme0n1   259:0    0 953.9G  0 disk 
nvme0n1p2 259:3    0 953.6G  0 part /mnt/armbian-install.NQULbp/rootfs
                                    /mnt/tmp

root@uefi-arm64:/usr/sbin# udevadm settle
root@uefi-arm64:/usr/sbin# lsblk -l
NAME      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda         8:0    1  14.4G  0 disk 
sda1        8:1    1   256M  0 part /boot/efi
sda2        8:2    1  14.2G  0 part /var/log.hdd
                                    /
zram0     252:0    0   7.7G  0 disk [SWAP]
zram1     252:1    0    50M  0 disk /var/log
zram2     252:2    0     0B  0 disk 
nvme0n1   259:0    0 953.9G  0 disk 
nvme0n1p2 259:3    0 953.6G  0 part /mnt/armbian-install.NQULbp/rootfs
                                    /mnt/tmp

root@uefi-arm64:/usr/sbin# ls -l /dev/nvme0n1*
brw-rw---- 1 root disk 259, 0 Oct  5 06:18 /dev/nvme0n1
brw-rw---- 1 root disk 259, 3 Oct  5 06:18 /dev/nvme0n1p2
root@uefi-arm64:/usr/sbin# fdisk /dev/nvme0n1

Welcome to fdisk (util-linux 2.39.3).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

This disk is currently in use - repartitioning is probably a bad idea.
It's recommended to umount all file systems, and swapoff all swap
partitions on this disk.


Command (m for help): p

Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
Disk model: Fanxiang S501Q 1TB                      
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: D98AAC78-13E2-42D7-948D-3BD864476713

Device          Start        End    Sectors   Size Type
/dev/nvme0n1p1   2048     526335     524288   256M EFI System
/dev/nvme0n1p2 526336 2000408575 1999882240 953.6G Linux filesystem

Command (m for help): q

 

although I can hack the install, just curious if there is a cleaner solution other than reboot...

 

 

[going]

9 часов назад, ozacas сказал:

although I can hack the install, just curious if there is a cleaner solution other than reboot

You can describe the wrong behavior and attach pictures with the selection dialog interface.

You can show the partition table status of all memory devices before and after the change.

 

You can post suggestions for improving the functionality of the script here.
I am changing his logic right now and your opinion may be useful.

 

9 часов назад, ozacas сказал:

armbian-install due to incorrect knowledge of partitions:

I see some kind of manual work here.
Or is it some kind of intermediate script state?

[ozacas]

Unfortunately, I hacked the system but i'll redo the test and capture more. I performed two armbian-install runs:
 

1. first time (after first boot) where I accepted all the defaults. The system failed to boot: no EFI FAT partition was setup despite nuking the entire drive. This led to the "intermediate state" above that I captured. I cant see how armbian-install is going to work with that device state: no way to setup the right partitions as they are not present in /dev. I noted that after completion of this run, a temporary mount was still present (presumably lsblk picked that up too from the mountpoint shown)
2. second time (after reporting the above) I created an EFI partition and a second partition only for the root filesystem using gdisk by hand and then forced it to use those partitions rather than nuking the entire drive. This sort-of worked: root was populated, but the EFI partition was not. No problem: just copied it from the USB stick I used to boot from. The result was a bootable system.

Happy to run bash -x /usr/sbin/armbian-install to capture state (as well as the install log) shortly, once a fresh image is built.

[going]

39 минут назад, ozacas сказал:

I cant see how armbian-install is going to work with that device state: no way to setup the right partitions as they are not present in /dev

Unfortunately, the script does not do some actions or does them incorrectly.

You describe it well. I will rely on this information.

 

 

[ozacas]

OK - fresh install!!

 

before armbian-install monitor results - https://paste.armbian.com/jifapohama (iostat was not installed so results from it are missing)

 

armbian install log data (I screwed up the shell capture the first time, had to run it twice):

• ran install using bash -x /usr/sbin/armbian-install 2>&1 | tee -a /tmp/install-bash-out.log  to capture output (terminal characters and all). Recommend you cleanup the bash capture with col -b to reduce the pesky terminal emulation characters
• captured /var/log/armbian-install.log after run. Both files are attached below.

 

post-condition (no EFI partition on nvme drive, but no leftover mount point this time):

root@uefi-arm64:/etc/grub.d# df
Filesystem     1K-blocks    Used Available Use% Mounted on
tmpfs            1605692   12844   1592848   1% /run
/dev/sda2       59094688 5723500  52681388  10% /
tmpfs            8028460       0   8028460   0% /dev/shm
tmpfs               5120       0      5120   0% /run/lock
efivarfs              64      41        24  64% /sys/firmware/efi/efivars
tmpfs            8028460      20   8028440   1% /tmp
/dev/sda1         258094     150    257945   1% /boot/efi
/dev/zram1         47960    1532     42844   4% /var/log
tmpfs            1605692      60   1605632   1% /run/user/1000
root@uefi-arm64:/etc/grub.d# fdisk /dev/nvme0n1

Welcome to fdisk (util-linux 2.39.3).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

This disk is currently in use - repartitioning is probably a bad idea.
It's recommended to umount all file systems, and swapoff all swap
partitions on this disk.


Command (m for help): p

Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors
Disk model: Fanxiang S501Q 1TB                      
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A3C2AE18-4086-48D2-B1F9-90B315BAB1FA

Device         Start        End    Sectors   Size Type
/dev/nvme0n1p1  2048 2000408575 2000406528 953.9G Linux filesystem

Command (m for help): 

after a reboot, EDK2 0.11.2 is unable to boot from the drive when chosen from the boot manager in the UEFI bios.

 

I'll leave the system alone for now should further debug be required.

armbian-install.log install-bash-out.log

[going]

5 часов назад, ozacas сказал:

before armbian-install monitor results - https://paste.armbian.com/jifapohama

The first thing I noticed is that the build system does not handle GPT correctly:

[    5.300511] GPT:Primary header thinks Alt. header is not at the end of the disk.
[    5.300513] GPT:14942207 != 120831999
[    5.300515] GPT:Alternate GPT header not at the end of the disk.
[    5.300516] GPT:14942207 != 120831999
[    5.300517] GPT: Use GNU Parted to correct GPT errors.

 

@ozacas

Did I understand correctly that your device booted from SATA?

Was the image of the Armbians recorded on a SATA drive?

Was the boot code not written into the soldered chip? Just to understand.

 

7 часов назад, ozacas сказал:

I'll leave the system alone for now should further debug be required.

Good. I will make changes and provide you with a new version of the script for testing.
It will take a few days.
And thanks for the information provided.

[ozacas]

the image was written to USB stick using balenaEtcher and then booted via USB2 port on the opi5+ - which appears as sda as the source/boot/root drive. No EMMC on the opi5+ nor SD card was installed or used at all.

Edited yesterday at 08:23 PM by ozacas
improved clarity

[going]

14 часов назад, ozacas сказал:

the image was written to USB stick using balenaEtcher and then booted via USB2 port on the opi5+ - which appears as sda as the source/boot/root drive. No EMMC on the opi5+ nor SD card was installed or used at all.

Good. I have always believed that devices can only boot from a SD card, eMMC or nand\nor flash (here I mean the initial boot code).

But I read the RK3588\S Datasheets and realized that its BootRom can also load USB OTG.
This changes the logic for choosing quite seriously.

 

Download Stages:

1) the power is turned on and the hardware BootROM tries to read the initial boot code from the media in the manner prescribed by the hardware manufacturer.

For RK3588 it is:

Цитата

 BootRom
 * Support system boot from the following device:
           - SPI interface
           - eMMC interface
           - SD/MMC interface
 * Support system code download by the following interface:
           - USB OTG interface

 

2)The initial boot code configures the RAM and loads the main part of UBOOT into it.

3) UBOOT configures the peripheral, loads the kernel directly or loads another loader and transfers control to it.

 

In your case, I would probably want to place the initial boot code on the SD card and the entire file system on NVME.
That is, insert a clean CD and a clean NVME into the connectors, boot from USB and run armbian-install,

which will partition (clean) the media and record everything correctly. (This does not work in the current version.)

 

What configuration do you want to get in the end?