Ulrich Posted March 2, 2023 Share Posted March 2, 2023 Armbian Armbian 22.11.4 Jammy on Odroid C4 boot from SD card system on an ext4 SSD. First of all - everything I need works correctly... However, I have a question about the SD card. During the first installation on the SSD disk, the system hung on the first reboot and you could see from the console that the SD card with UUID=61748c7e-b234-40e8-b6b6-592f845c3699 was being waited for. After the timeout, the only way to fix the "error" was to log into the system via terminal. Long story - only after commenting out the SD card in the fstab on the SSD: UUID=61748c7e-b234-40e8-b6b6-592f845c3699 /media/mmcboot ext4 defaults,noatime,commit=600,errors=remount-ro,x-gvfs-hide 0 0 /media/mmcboot/boot /boot none bind 0 0 the system booted from the SSD as requested. Since then, the SD card is not mounted and just shows up as: Disk /dev/mmcblk0: 30.61 MiB, 32096256 bytes, 62688 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes at fdisk -l. No UUID etc nothing... The SD-Card is 32G and is readable on other systems... Question now - is this normal? Can I live with that? Can it be fixed? A "curiosity" - after booting from the SSD and updating the kernel to 6.0.13, the update ended up on both the SSD and the unmounted SD card. How - is a mystery to me (;-) 0 Quote Link to comment Share on other sites More sharing options...
Ulrich Posted March 3, 2023 Author Share Posted March 3, 2023 (edited) Addendum... If I remove the SD card after the system has booted from the SSD and then reinsert it, it is recognized: blkid /dev/mmcblk0p1: LABEL="armbi_root" UUID="61748c7e-b234-40e8-b6b6-592f845c3699" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="4dfba17f-01" If I then remove the commented lines in the fstab, the SD card is mounted correctly with mount -a as intended. and a very last... screen /dev/tty.usbserial-1420 115200 ..... [ ***] A start job is running for /dev/disk/by-uuid/61748c7e-b234-40e8-b6b6-592f845c3699 (1min 30s / 1min 30s) [ TIME ] Timed out waiting for device /dev/disk/by-uuid/61748c7e-b234-40e8-b6b6-592f845c3699. [DEPEND] Dependency failed for /media/mmcboot. [DEPEND] Dependency failed for /boot. [DEPEND] Dependency failed for Unattended Upgrades Shutdown. [DEPEND] Dependency failed for Local File Systems. [DEPEND] Dependency failed for Mark the need to relabel after reboot. ... ... Give root password for maintenance (or press Control-D to continue): A Control-D does absolutely nothing. Bravely pulled the SD card and reinserted it and the next message was Armbian 23.02.2 Jammy ttyAML0 OdroidC4 login: With my system, unfortunately, it stays the same - without removing and reinserting the SD card, the system hangs on a cold start. Only removing the SD card in the fstab on the SSD card allows the system to boot without an SD card. For me -> freeze kernel updates and if there is really something urgently new, comment out again to get the update on the SD card AND on the boot folder on the SSD. It seems to me that this also has something to do with the bug restart... If I'm brave enough, I'll try to tinker with the Odroid hardware and set the SD card's power supply to fixed 3.3 volts... It's a shame - the way it is, the C4 is really only for "hobbyists"... Edited March 3, 2023 by Ulrich new informations 0 Quote Link to comment Share on other sites More sharing options...
Ulrich Posted March 4, 2023 Author Share Posted March 4, 2023 my last "findings" I have now permanently enabled the power supply for the SD card for testing. Now booting from the SSD works without the SD card being "lost"... My rhyme - at some point the SD card is deprived of the supply voltage and the system "forgets" to reinitialize the card. In my opinion, this is supported by the fact that after removing and reinserting the SD card, it was recognized normally. However, my hopes that the reboot would also work were disappointed. Even if the card is permanently supplied with power, it is not recognized after a reboot and removing and reinserting it does not work either. But I can do without the reboot, now I can at least carry out kernel updates and the kernel is loaded from the SD card as intended. 0 Quote Link to comment Share on other sites More sharing options...
LluviaFria Posted July 19, 2023 Share Posted July 19, 2023 Hello, I am trying to boot my odroid c4 from a USB 3.0 storage, the steps I am following are the ones that appear in armbian-config but, the steps seem to complete well but at the time of the first reboot my system does not boot, you seem to have found the solution, could you please make a small guide for beginners like me? my goal is to boot my odroid from USB3.0 storage with the image Armbian_23.02.2_Odroidc4_jammy_current_6.1.11, it is the version without a desktop, I connect via SSH, I do not use the latest image Armbian_23.5.1_Odroidc4_jammy_current_6.1.30 because the kernel does not seem to be stable. 0 Quote Link to comment Share on other sites More sharing options...
usual user Posted August 1, 2023 Share Posted August 1, 2023 On 7/19/2023 at 7:25 AM, LluviaFria said: I am trying to boot my odroid c4 from a USB 3.0 storage, the steps I am following are the ones that appear in armbian-config Out of curiosity, are you interested in a little experiment? If so, - prepare an entire cleared SD card (dd if=/dev/zero of=/dev/${entire-SD-card}) - dd the unpacked firmware (tar -xzf uboot-meson.tgz) that is uploaded here in place with: dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/${entire-SD-card} - dd the unmodified Armbian_23.02.2_Odroidc4_jammy_current_6.1.11 image onto your USB 3.0 storage - plug in the prepared SD card and your USB 3.0 storage into your odroid c4 - boot the odroid c4 and post the serial console log 1 Quote Link to comment Share on other sites More sharing options...
LluviaFria Posted August 3, 2023 Share Posted August 3, 2023 Hello, thanks for your answer, I did all the steps as you said and it seems to work, now the root is located on the usb 3.0 disk, but I didn't understand the last step " - boot the odroid c4 and post the serial console log" if you could explain how to do it, I would, sorry I don't have much knowledge in linux, I'm new to this. Now I am going to do a sudo apt update and sudo apt upgrade to update the system and see if it is solid or it breaks when updating. root@odroidc4:/# dd if=/dev/zero of=/dev/sda1 dd: writing to '/dev/sda1': No space left on device 5111809+0 records in 5111808+0 records out 2617245696 bytes (2.6 GB, 2.4 GiB) copied, 397.152 s, 6.6 MB/s root@odroidc4:/home/odroid# dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/sda1 2221+1 records in 2221+1 records out 1137520 bytes (1.1 MB, 1.1 MiB) copied, 0.222784 s, 5.1 MB/s root@odroidc4:/home/odroid# root@odroidc4:~# df -h Filesystem Size Used Avail Use% Mounted on tmpfs 379M 11M 369M 3% /run /dev/sda1 146G 2.0G 142G 2% / tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.9G 0 1.9G 0% /tmp /dev/zram1 47M 1020K 43M 3% /var/log tmpfs 379M 0 379M 0% /run/user/0 root@odroidc4:~# root@odroidc4:~# fdisk -l Disk /dev/mmcblk0: 57.95 GiB, 62226694144 bytes, 121536512 sectors 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: 0xc4d340a8 Device Boot Start End Sectors Size Id Type /dev/mmcblk0p1 8192 5119999 5111808 2.4G 83 Linux Disk /dev/sda: 149.05 GiB, 160041885696 bytes, 312581808 sectors Disk model: Generic Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0xc4d340a8 Device Boot Start End Sectors Size Id Type /dev/sda1 8192 309428224 309420033 147.5G 83 Linux Disk /dev/zram0: 1.85 GiB, 1984663552 bytes, 484537 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 root@odroidc4:~# df -h Filesystem Size Used Avail Use% Mounted on tmpfs 379M 11M 369M 3% /run /dev/sda1 146G 2.0G 142G 2% / tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.9G 0 1.9G 0% /tmp /dev/zram1 47M 1020K 43M 3% /var/log tmpfs 379M 0 379M 0% /run/user/0 root@odroidc4:~# 0 Quote Link to comment Share on other sites More sharing options...
LluviaFria Posted August 3, 2023 Share Posted August 3, 2023 On 8/1/2023 at 3:34 PM, usual user said: Out of curiosity, are you interested in a little experiment? If so, Hello, thanks for your answer, I did all the steps as you said and it seems to work, now the root is located on the usb 3.0 disk, but I didn't understand the last step " - boot the odroid c4 and post the serial console log" if you could explain how to do it, I would, sorry I don't have much knowledge in linux, I'm new to this. Now I am going to do a sudo apt update and sudo apt upgrade to update the system and see if it is solid or it breaks when updating. root@odroidc4:/# dd if=/dev/zero of=/dev/sda1 dd: writing to '/dev/sda1': No space left on device 5111809+0 records in 5111808+0 records out 2617245696 bytes (2.6 GB, 2.4 GiB) copied, 397.152 s, 6.6 MB/s root@odroidc4:/home/odroid# dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/sda1 2221+1 records in 2221+1 records out 1137520 bytes (1.1 MB, 1.1 MiB) copied, 0.222784 s, 5.1 MB/s root@odroidc4:/home/odroid# root@odroidc4:~# df -h Filesystem Size Used Avail Use% Mounted on tmpfs 379M 11M 369M 3% /run /dev/sda1 146G 2.0G 142G 2% / tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.9G 0 1.9G 0% /tmp /dev/zram1 47M 1020K 43M 3% /var/log tmpfs 379M 0 379M 0% /run/user/0 root@odroidc4:~# root@odroidc4:~# fdisk -l Disk /dev/mmcblk0: 57.95 GiB, 62226694144 bytes, 121536512 sectors 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: 0xc4d340a8 Device Boot Start End Sectors Size Id Type /dev/mmcblk0p1 8192 5119999 5111808 2.4G 83 Linux Disk /dev/sda: 149.05 GiB, 160041885696 bytes, 312581808 sectors Disk model: Generic Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: dos Disk identifier: 0xc4d340a8 Device Boot Start End Sectors Size Id Type /dev/sda1 8192 309428224 309420033 147.5G 83 Linux Disk /dev/zram0: 1.85 GiB, 1984663552 bytes, 484537 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 root@odroidc4:~# df -h Filesystem Size Used Avail Use% Mounted on tmpfs 379M 11M 369M 3% /run /dev/sda1 146G 2.0G 142G 2% / tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.9G 0 1.9G 0% /tmp /dev/zram1 47M 1020K 43M 3% /var/log tmpfs 379M 0 379M 0% /run/user/0 root@odroidc4:~# 0 Quote Link to comment Share on other sites More sharing options...
usual user Posted August 4, 2023 Share Posted August 4, 2023 (edited) On 8/3/2023 at 4:44 AM, LluviaFria said: I did all the steps as you said Judging by your following command excerpts, you did not do this. Since I don't know if your SD card to be prepared was really in a card reader listed as /dev/sda when you ran the command "root@odroidc4:/# dd if=/dev/zero of=/dev/sda1", I can't really tell if you chose the right device. In any case, you didn't target the entire device for the dd commands as instructed, but only the first partition (dev/sda1). The correct one here would have been "/dev/sda". On 8/3/2023 at 4:44 AM, LluviaFria said: I didn't understand the last step " - boot the odroid c4 and post the serial console log" Serial console logs are taken via the 4pin UART Connector for system console and are essential for proper debugging. Because you wrote my firmware in the first partition, and not at the location where it is expected by the MASKROM code, I can't tell what exactly is going on without appropriate console logs. But you have apparently corrupted the contents of the first partition enough, so that the existing firmware also uses the bootflow in the USB storage. However, the original goal is to have an SD card that contains only the firmware and no other system artifacts. Edited August 4, 2023 by usual user 0 Quote Link to comment Share on other sites More sharing options...
LluviaFria Posted August 7, 2023 Share Posted August 7, 2023 On 8/4/2023 at 3:14 AM, usual user said: Judging by your following command excerpts, you did not do this. Since I don't know if your SD card to be prepared was really in a card reader listed as /dev/sda when you ran the command "root@odroidc4:/# dd if=/dev/zero of=/dev/sda1", I can't really tell if you chose the right device. In any case, you didn't target the entire device for the dd commands as instructed, but only the first partition (dev/sda1). The correct one here would have been "/dev/sda". Well I did the steps again, I have 2 micro SD cards, in one I did a clean and updated installation of Armbian_23.02.2_Odroidc4_jammy_current_6.1.11 image, the other one is an old and slow micro SD of 4gb I put it in a micro reader SD and plugged it into the odroidc4 in a usb port, then run the two commands making sure to get it right this time "/dev/sda". When finished, I take out the micro sd with the armbian system and connect the other micro SD with the u-boot in the odroidc4, and a usb 3.0 HDD disk with the armbian system, the system boots fine, I update the system with sudo apt update and sudo apt upgrade, i power cycle the system (for some reason when i use sudo reboot, the system doesn't boot, i have to force a shutdown to make it work again.) i can't do the last step, i don't have the 4pin UART cable. I also don't have an HDMI monitor to connect to. I hope you understand me because I'm using google translate. root@odroidc4:/home/odroid# fdisk -l Disk /dev/mmcblk0: 29.72 GiB, 31914983424 bytes, 62333952 sectors 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: 0xc4d340a8 Device Boot Start End Sectors Size Id Type /dev/mmcblk0p1 8192 61702144 61693953 29.4G 83 Linux Disk /dev/zram0: 1.85 GiB, 1984663552 bytes, 484537 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 Disk /dev/sda: 3.69 GiB, 3965190144 bytes, 7744512 sectors Disk model: R3PRO U-DISK Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes root@odroidc4:/home/odroid# dd if=/dev/zero of=/dev/sda dd: writing to '/dev/sda': No space left on device 7744513+0 records in 7744512+0 records out 3965190144 bytes (4.0 GB, 3.7 GiB) copied, 1212.41 s, 3.3 MB/s root@odroidc4:/home/odroid# dd bs=512 seek=1 conv=notrunc,fsync if=u-boot-meson.bin of=/dev/sda 2221+1 records in 2221+1 records out 1137520 bytes (1.1 MB, 1.1 MiB) copied, 0.454422 s, 2.5 MB/s root@odroidc4:/home/odroid# now the system booted from usb3.0 disk shows like this. root@odroidc4:~# df -h Filesystem Size Used Avail Use% Mounted on tmpfs 379M 15M 364M 4% /run /dev/sda1 146G 2.0G 142G 2% / tmpfs 1.9G 0 1.9G 0% /dev/shm tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 1.9G 0 1.9G 0% /tmp /dev/zram1 47M 1020K 43M 3% /var/log tmpfs 379M 0 379M 0% /run/user/0 root@odroidc4:~# 0 Quote Link to comment Share on other sites More sharing options...
c0rnelius Posted August 7, 2023 Share Posted August 7, 2023 I use a similar approach but also include a boot script. boot.cmd: setenv bootlabel "USB Boot" usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi Flash img to SDCARD, flash Armbian to USB drive, insert into unit and power on. https://github.com/pyavitz/binary/releases/download/images/meson64_odroidc4-usb-boot.img 0 Quote Link to comment Share on other sites More sharing options...
LluviaFria Posted August 7, 2023 Share Posted August 7, 2023 54 minutes ago, c0rnelius said: I use a similar approach but also include a boot script. I have been trying to start armbian from usb for 1 month, and I was unsuccessful, I couldn't find any tutorial that would help me, the Armbian-config itself has an option to transfer the boot to the micro SD but that option does not work for me, the system never starts, It's a shame, I ended up buying a raspberry pi 4 just because I needed to boot from a usb, it's a shame because I like the temperatures of the odroidc4 compared to the temperatures of the raspberry pi4, where were you and your methods ? It would have been very useful to find tutorials for beginners with these methods. 0 Quote Link to comment Share on other sites More sharing options...
usual user Posted August 7, 2023 Share Posted August 7, 2023 10 hours ago, LluviaFria said: the system boots fine Judging by your following command excerpts, this time you did everything as required. You should now have my provided firmware build in use and it is working as expected. I.e. it is using distro-boot and should be able to boot various operating systems from USB, SD-card or eMMC as long as either a suitable legacy- (boot.scr), extlinux- (extlinux.conf) or EFI-bootflow is in place. And since it doesn't carry any OS artefacts on the firmware device and uses unmodified OS images for a single drive, OS updates should work much more reliably. 10 hours ago, LluviaFria said: for some reason when i use sudo reboot, the system doesn't boot In order to determine the cause and possibly find a solution, the serial console logs are mandatory. 10 hours ago, LluviaFria said: i don't have the 4pin UART cable. If you can't provide serial console logs, you're pretty much on your own. If it breaks for you, you have to keep the parts. 0 Quote Link to comment Share on other sites More sharing options...
c0rnelius Posted August 8, 2023 Share Posted August 8, 2023 Quote where were you and your methods I've been around. This method generally works well in my testing on both Amlogic and Allwinner boards. The only catch is, some USB ports don't work as well as others "or at all?", so it requires a little trial and error. I've been told by some users that adding a sleep and USB reset to the script also helps when having issues. But I've personally never needed to do so. As long as the drive is properly powered, it should just work. 0 Quote Link to comment Share on other sites More sharing options...
LluviaFria Posted August 10, 2023 Share Posted August 10, 2023 On 8/7/2023 at 2:08 PM, usual user said: You should now have my provided firmware build in use and it is working as expected. When there is a new version of your firmware, where will you publish it for download? On 8/7/2023 at 2:08 PM, usual user said: In order to determine the cause and possibly find a solution, the serial console logs are mandatory. since i couldn't get armbian to work from usb, i had given up and bought a raspberry pi 4 with 8gb ram, right now my odroidc4 is saved, this happened before you arrived with your firmware. On 8/7/2023 at 2:08 PM, usual user said: If you can't provide serial console logs, you're pretty much on your own. If it breaks for you, you have to keep the parts. When I get the cable, I'll let you know. 0 Quote Link to comment Share on other sites More sharing options...
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.