ozacas Posted October 4 Posted October 4 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... 0 Quote
going Posted October 5 Posted October 5 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? 0 Quote
ozacas Posted October 5 Author Posted October 5 Unfortunately, I hacked the system but i'll redo the test and capture more. I performed two armbian-install runs: 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) 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. 0 Quote
going Posted October 5 Posted October 5 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. 0 Quote
ozacas Posted October 5 Author Posted October 5 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 0 Quote
going Posted October 5 Posted October 5 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. 0 Quote
ozacas Posted October 5 Author Posted October 5 (edited) 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 October 5 by ozacas improved clarity 0 Quote
going Posted October 6 Posted October 6 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? 0 Quote
ozacas Posted October 6 Author Posted October 6 are we talking about different things here? I didnt think I was using U-BOOT but rather EDK2 (SPI flash) -> grub -> linux (ACPI) for the boot process. But i'm no expert here, so could be wrong. The way I see things working as far as armbian-install is concerned for a UEFI system - eg. when using an image compiled with UEFI_EDK2_BOARD_ID=orangepi-5plus BOARD=uefi-arm64 locate EFI partition on source volume (running system) locate root partition on source volume fail if (1) and (2) cannot be found ensure target volume (eg. NVME drive) has appropriate partitions and filesystems for (1) and (2) ensure partitions on target volume are visible to user-land via /dev entries - fail if not populate each filesystem in (4) with corresponding data from source volume notify the user if something goes wrong. This is probably hard to do given the number of programs involved and the complexity of operations, but failed steps cause gaps downstream which can be hard to spot adjust /etc/fstab to reference the new partitions on the target volume eg. nvme drive only. Maybe some other adjustments too? 0 Quote
going Posted October 7 Posted October 7 7 часов назад, ozacas сказал: are we talking about different things here? I didnt think I was using U-BOOT but rather EDK2 (SPI flash) -> grub -> linux (ACPI) for the boot process. But i'm no expert here, so could be wrong. I'm sorry, I used the wrong terminology. In your case, the initial boot code (uefi-arm64), which was downloaded from here with this code. It was recorded in the image and is located on the USB flash drive (boot device) from which you started the OS. By the way, it contains the UBOOT code plus some additional code, but that's not important right now. As far as I understand from the build system code, we should have a separate partition on the boot block device that is mounted in the "/boot/efi" folder and it is associated with the initial boot code that reads it. In turn, the OS boot code writes information there when updating the kernel, adding a variant of another OS to boot. The first problem is that NVME cannot be a bootable block device. Another one is described here. That is, your USB flash drive will serve as a boot device and NVME will have OS partitions. This is one scenario. Another scenario is.... however, the script does not provide for analyzing and doing any different steps depending on which image was built with UEFI support and which memory devices will serve as future boot devices. I think I found a few problematic parts in the code. Correction work is in progress. 0 Quote
ozacas Posted October 8 Author Posted October 8 Quote I'm sorry, I used the wrong terminology. No problem - i'm starting the get the picture that there is a lot of corner cases here... Quote The first problem is that NVME cannot be a bootable block device. Can you expand on this? I have it working on another opi5+ running armbian right now: acas@opi2:~$ df Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 784040 12828 771212 2% /run /dev/nvme0n1p2 983175932 901075092 32084516 97% / tmpfs 3920192 0 3920192 0% /dev/shm tmpfs 5120 0 5120 0% /run/lock efivarfs 64 9 56 14% /sys/firmware/efi/efivars /dev/nvme0n1p1 204580 308 204272 1% /boot/efi tmpfs 3920192 15492 3904700 1% /tmp /dev/sda3 1896953852 1309223496 491296588 73% /data /dev/zram1 47960 31804 12572 72% /var/log tmpfs 784036 8264 775772 2% /run/user/1000 acas@opi2:~$ uname -a Linux opi2.local 6.10.11-edge-arm64 #1 SMP Wed Sep 18 17:25:18 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux also EDK2 installed to SPI flash and then /boot/efi and root from NVME, just slightly older kernel. 0 Quote
going Posted October 8 Posted October 8 10 часов назад, ozacas сказал: also EDK2 installed to SPI flash and then /boot/efi and root from NVME SPI flash can be a bootable block device 0 Quote
going Posted October 11 Posted October 11 08.10.2024 в 12:15, ozacas сказал: Цитата The first problem is that NVME cannot be a bootable block device. Can you expand on this? I have it working on another opi5+ running armbian right now: @ozacas If it doesn't bother you, could you post the output of the "fdisk -l" command under the spoiler for your device? I have a suspicion that the script does not analyze correctly if EDK2 is used. 0 Quote
ozacas Posted October 11 Author Posted October 11 the box i was referring to has the following - acas@opi2:~/build$ fdisk -l Disk /dev/nvme0n1: 953.87 GiB, 1024209543168 bytes, 2000409264 sectors Disk model: Fanxiang S500Pro 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: dos Disk identifier: 0x4f11c8df Device Boot Start End Sectors Size Id Type /dev/nvme0n1p1 2048 411647 409600 200M ef EFI (FAT-12/16/32) /dev/nvme0n1p2 411648 2000409263 1999997616 953.7G 83 Linux Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: ASM1153USB3.0TOS Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 33553920 bytes Disklabel type: dos Disk identifier: 0x2eeae39f Device Boot Start End Sectors Size Id Type /dev/sda1 2048 8390655 8388608 4G b W95 FAT32 /dev/sda2 8390656 50333695 41943040 20G 83 Linux /dev/sda3 50333696 3907029167 3856695472 1.8T 83 Linux Disk /dev/zram0: 3.74 GiB, 4014276608 bytes, 980048 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/zram1: 50 MiB, 52428800 bytes, 12800 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes ah... i have a USB connected sata adapter ssd as /dev/sda - forgot about that. Maybe that is accidentally providing boot (used to be connected to an rpi4) 1 Quote
ozacas Posted October 11 Author Posted October 11 system boots successfully without the sata ssd adapter plugged in - so it boots successfully off SPI (EDK2) -> nvme -> linux via ACPI alone. 0 Quote
going Posted October 11 Posted October 11 27 минут назад, ozacas сказал: ah... i have a USB connected sata adapter ssd as /dev/sda - forgot about that. Maybe that is accidentally providing boot (used to be connected to an rpi4) Don't rush to a conclusion. If you check your first configuration before installation, you should see for the echo "$(fdisk -l | grep 'EFI')" command: /dev/sda1 8192 532479 524288 256M EFI System And after installation: (Or just insert the USB flash drive from which the installation was done) /dev/sda1 8192 532479 524288 256M EFI System /dev/nvme0n1p1 2048 411647 409600 200M ef EFI (FAT-12/16/32) 0 Quote
ozacas Posted October 11 Author Posted October 11 wait - you wanted me to do it to the original system in the thread? I think I did it to the wrong one... 0 Quote
going Posted October 11 Posted October 11 10 минут назад, ozacas сказал: wait - you wanted me to do it to the original system in the thread? I think I did it to the wrong one... Simply insert the USB drive from which the installation was performed into the connector on the running device and output the command: echo "$(fdisk -l | grep 'EFI')" That's all for now. 0 Quote
ozacas Posted October 11 Author Posted October 11 the original system that started the thread, after (failed) armbian-install run, looks like this with the USB stick used to boot the system: acas@uefi-arm64:~$ df Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 1605708 12816 1592892 1% /run /dev/sda2 59094688 5773640 52631248 10% / tmpfs 8028524 0 8028524 0% /dev/shm tmpfs 5120 0 5120 0% /run/lock efivarfs 64 42 23 65% /sys/firmware/efi/efivars tmpfs 8028524 0 8028524 0% /tmp /dev/sda1 258094 150 257945 1% /boot/efi /dev/zram1 47960 2152 42224 5% /var/log tmpfs 1605704 60 1605644 1% /run/user/1000 acas@uefi-arm64:~$ fdisk -l 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 Disk /dev/sda: 57.62 GiB, 61865984000 bytes, 120832000 sectors Disk model: USB Flash Drive 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: 611F458A-F35E-B04A-9F22-8E04707F1E17 Device Start End Sectors Size Type /dev/sda1 8192 532479 524288 256M EFI System /dev/sda2 532480 120831966 120299487 57.4G Linux root (ARM-64) Disk /dev/zram0: 7.66 GiB, 8221212672 bytes, 2007132 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/zram1: 50 MiB, 52428800 bytes, 12800 sectors Units: sectors of 1 * 4096 = 4096 bytes Sector size (logical/physical): 4096 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes note how there is no EFI partition on the NVME drive. But the image from the armbian build framework has an EFI system partition and is what i'm using to boot the system right now via the USB stick. 1 Quote
going Posted October 11 Posted October 11 3 минуты назад, ozacas сказал: note how there is no EFI partition on the NVME drive. But the image from the armbian build framework has an EFI system partition and is what i'm using to boot the system right now via the USB stick. Everything is right. It is this partition (from a USB drive) that the script is trying to mount into the future root file system. There's something wrong here. 0 Quote
going Posted October 12 Posted October 12 08.10.2024 в 12:15, ozacas сказал: also EDK2 installed to SPI flash and then /boot/efi and root from NVME, If you do on this device: fdisk -l Will the kernel see a block device for SPI flash? Do I understand correctly that the OS is running a common core from the OS vendor? 0 Quote
ozacas Posted October 12 Author Posted October 12 the OS is produced with a custom build directive (note the BOARD chosen and how EDK2 is selected as the opi5+ variant for the SBC) and installed to the USB stick per - ./compile.sh EXPERT=yes KERNEL_GIT=shallow BRANCH=edge UEFI_EDK2_BOARD_ID=orangepi-5plus BOARD=uefi-arm64 BOOT_FDT_FILE="rockchip/rk3588-orangepi-5-plus.dtb" CLEAN_LEVEL=debs,cache,make-kernel ENABLE_EXTENSIONS=grub-with-dtb as per this thread 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.