Search the Community

Hi everyone! I didn't expect this post to be active again after almost a year without replies, so thanks for the revival! After writing this "article," I stopped investigating the problem. However, the post being active again piqued my curiosity to see if the issue was resolved. Unfortunately, the problem persists on Armbian 23.11.1 (bookworm). I tried the same steps as before, but encountered a major issue. After recompiling and compiling the dts and rebooting, my device wouldn't boot anymore. It kept showing "UUID does not exist" (and I don't know why, so if anybody knows, please tell me). I really appreciate your efforts @usual user for providing the .dts, but I think the problem lies in the overlay file of Armbian, which seems to be out of date. It seems they forgot to update the overlay, as @robertoj mentioned that this isn't a problem in the boot process; the original dts that boots on the OPi 3 LTS is correct. I followed the same steps as before: sudo armbian-config -> System -> Dtc, and in the spi@5011000 section, they updated the phandle of the pins. spi1-pins { pins = "PH4\0PH5\0PH6"; function = "spi1"; phandle = <0x32>; }; spi1-cs-pin { pins = "PH3"; function = "spi1"; phandle = <0x33>; }; But when we checked the sun50i-h6-spi-spidev1.dtbo, it remained the same. fragment@1 { target = <0xffffffff>; __overlay__ { pinctrl-names = "default"; pinctrl-0 = <0xffffffff>; status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; spidev@0 { compatible = "armbian,spi-dev"; reg = <0x00>; spi-max-frequency = <0xf4240>; }; }; }; Notice that the "pinctrl-0" is <0xffffffff>, which seems more like a placeholder than a real id of a node. The problem here is that we have a working device tree in the system, but when I activate the overlay using overlays=spi-spidev1 in /boot/armbianEnv.txt, it overwrites the correct dts and puts the wrong node id. Before adding the overlay in your boot config, you can check this by going to /sys/firmware/devicetree/base/soc/spi@5011000 and using cat on pinctrl-0: $> /sys/firmware/devicetree/base/soc/spi@5011000# cat pinctrl-0 23 What are these 2 and 3? If we look at the original device tree source, it's pinctrl-0 = <0x32 0x33>;, where 32 refers to the node spi1-pins and 33 to spi1-cs-pin. By using an ASCII to hex converter, we find that 2 corresponds to 0x32 and 3 to 0x33. You can also confirm which pins are assigned to these IDs by: $> /sys/firmware/devicetree/base/soc/pinctrl@300b000/spi1-pins# cat phandle 2 $> /sys/firmware/devicetree/base/soc/pinctrl@300b000/spi1-cs-pin# cat phandle 3 So, what happens when we add the overlay? /sys/firmware/devicetree/base/soc/spi@5011000# cat pinctrl-0 2 We see that we have 2 (MOSI.1, MISO.1, and SCLK.1) but not 3 (CE.1). In other words, we don't have CE.1 activated as WiringOP showed us. But how can I simply fix that, given that (at least to me) recompiling and compiling aren't working more? It's simple: Copy the spidev@0 part from the overlay. Access sudo armbian-config -> System -> Dtc and find spi@5011000. Put the spidev@0 inside it and set the status of this node to "okay" instead of "disabled". The final result will be: spi@5011000 { compatible = "allwinner,sun50i-h6-spi\0allwinner,sun8i-h3-spi"; reg = <0x5011000 0x1000>; interrupts = <0x00 0x0b 0x04>; clocks = <0x06 0x53 0x06 0x51>; clock-names = "ahb\0mod"; dmas = <0x2f 0x17 0x2f 0x17>; dma-names = "rx\0tx"; pinctrl-names = "default"; pinctrl-0 = <0x32 0x33>; resets = <0x06 0x20>; status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; phandle = <0x7a>; spidev@0 { compatible = "armbian,spi-dev"; reg = <0x00>; spi-max-frequency = <0xf4240>; }; }; Save the modifications and now use this command to remove the wrong overlay: $> cd /boot/dtb/allwinner/overlay/ $> mv sun50i-h6-spi-spidev1.dtbo .sun50i-h6-spi-spidev1.dtbo After the reboot, you'll see: $> ls /dev/ | grep spi spidev0.0 Using gpio readall: $> sudo gpio readall +------+-----+----------+--------+---+ OPi 3 +---+--------+----------+-----+------+ | GPIO | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | GPIO | +------+-----+----------+--------+---+----++----+---+--------+----------+-----+------+ | | | 3.3V | | | 1 || 2 | | | 5V | | | | 122 | 0 | SDA.0 | OFF | 0 | 3 || 4 | | | 5V | | | | 121 | 1 | SCL.0 | OFF | 0 | 5 || 6 | | | GND | | | | 118 | 2 | PWM.0 | OFF | 0 | 7 || 8 | 0 | OFF | PL02 | 3 | 354 | | | | GND | | | 9 || 10 | 0 | OFF | PL03 | 4 | 355 | | 120 | 5 | RXD.3 | OFF | 0 | 11 || 12 | 0 | OFF | PD18 | 6 | 114 | | 119 | 7 | TXD.3 | OFF | 0 | 13 || 14 | | | GND | | | | 362 | 8 | PL10 | OFF | 0 | 15 || 16 | 0 | OFF | PD15 | 9 | 111 | | | | 3.3V | | | 17 || 18 | 0 | OFF | PD16 | 10 | 112 | | 229 | 11 | MOSI.1 | ALT2 | 0 | 19 || 20 | | | GND | | | | 230 | 12 | MISO.1 | ALT2 | 0 | 21 || 22 | 0 | OFF | PD21 | 13 | 117 | | 228 | 14 | SCLK.1 | ALT2 | 0 | 23 || 24 | 0 | ALT2 | CE.1 | 15 | 227 | | | | GND | | | 25 || 26 | 0 | OFF | PL08 | 16 | 360 | +------+-----+----------+--------+---+----++----+---+--------+----------+-----+------+ | GPIO | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | GPIO | +------+-----+----------+--------+---+ OPi 3 +---+--------+----------+-----+------+ You should see CE.1 working. Now, use spidev-test to see if SPI is working: $> ./spidev_test -v -D /dev/spidev0.0 spi mode: 0x0 bits per word: 8 max speed: 500000 Hz (500 KHz) TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D | ......@.... .................. . RX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D | ......@.... .................. . It's working! In the end, it seems that the overlay is incorrect (perhaps someone forgot to remove or update the "pinctrl-0 = <0xffffffff>") and needs to be updated. I don't know if the solution I created is the best way, but it's working in the recent images. If anyone has a hint to improve this solution or knows why I'm getting "UUID does not exist" when I recompile my .dtbo file, please let me know to improve my knowledge PS: You don't need to remove the overlay if you didn't add it to your armbianEnv.txt.

Hey, I'm trying to boot Armbian 27 Feb bullseye for Odroid C4 from microSD card and I get dropped to initramfs console because root UUID is not found. I fsck'd the card and it seems okay. Read that I should say to the kernel to wait for root to be found with rootdelay, added a line to armbianEnv.txt to no avail (didn't run any update command, though). What are your thoughts? Any other ideas? Thanks!

Hello. I have tried to boot from both sd and nvme with the latest version for rock5. The first problem I had is that it doesn't recognize the screen resolution. I am writing from sd card with original armbian image. This version recognizes the size of the screen without problems, but the version of Balbes I get only part of the screen. I see everything magnified. Excuse my technological language, it lacks words to determine things correctly. But you know what I'm talking about. Even so, with the huge screen, I managed to log in with the minimal image of armbian balbes. From there, I managed to update spi to the latest version with armbian-config and run armbian-install to install to nvme. And here it gets more complicated, because from sd I can log in, but from nvme (it boots without sd), I don't get to the login screen. The last screen I get is one where it tells me that the UUID does not exist. And that's where it all ends.

I replied to an older thread from last year regarding this same problem after I stumbled across this problem with the 23.02.2 Jammy XFCE image. I did some experimentation with various parameters and responded to that old post. In any case, I got it working using a different SD card. If you are interested in what I did, check out the post titled [Odroid-C4] Alert! Root UUID does not exist. Dropping to a shell!

Sorry if it takes a while to reply. I just made an account, so the number of posts I can make per day appears to be limited to 1. I did some additional testing and tried flashing several different images including some older versions: Couldn't boot at all (same error UUID does not exist): Armbian_22.05.3_Nanopi-r4s_focal_current_5.15.48.img.xz Armbian_22.02.1_Nanopi-r4s_focal_current_5.15.25.img.xz Armbian_22.05.3_Nanopi-r4s_jammy_current_5.15.48.img.xz Armbian_22.05.3_Nanopi-r4s_bullseye_current_5.15.48.img.xz Armbian_22.02.1_Nanopi-r4s_bullseye_current_5.15.25.img.xz Armbian_21.08.1_Nanopi-r4s_hirsute_edge_5.13.12.img.xz Armbian_22.02.1_Nanopi-r4s_jammy_edge_5.16.11.img Booted but would no longer boot after apt update/upgrade: Armbian_21.08.1_Nanopi-r4s_focal_current_5.10.60.img.xz Armbian_21.08.1_Nanopi-r4s_buster_current_5.10.60.img.xz Armbian_21.08.1_Nanopi-r4s_bullseye_current_5.10.60.img.xz I also have tried 3 different SD cards. So I doubt that is the cause, unless all 3 are somehow bad. All the ones that don't work appear to be 5.10.* I'm not sure if the newer ones come bundled with the newer version of the package that breaks it? Woops, sorry about that. When I read the title I didn't realize it was referring to the same problem I wish I had found it easier because it would have saved me a lot of time installing packages a couple at a time until I found the one that broke it... I also came to the same conclusion that updating linux-image-current-rockchip64 to version 22.*.* or newer breaks it. I tried three different 32GB SanDisk Ultra SD cards and none of the newer images will boot (including Armbian_22.05.3_Nanopi-r4s_jammy_current_5.15.48.img.xz and Armbian_22.05.3_Nanopi-r4s_bullseye_current_5.15.48.img.xz) I was using Rufus, but I also downloaded and tried the same version of USBimager 1.0.8 to eliminate that variable and still had the same problem I don't know if there might be some problem with my board? That seems unlikely since the older images still work... But given that the images work on the board you tested and aren't working on mine I'm not sure what would cause that.

I'm trying to load Armbian onto a NanoPi R4S, but an running into problems where it won't start with certain versions, and running apt update breaks it on other versions. I've hooked up the serial interface so I can see what's going on during boot, so there are pastebin links to the logs. Fresh Image (Jammy/Focal): Trying to use Jammy or Focal I cannot the the board to boot at all with a completely fresh image. The error message complains that the UUID for the main partition does not exist Log: https://pastebin.com/gQeyhVf5 Fresh image (Bullseye/Buster), post account creation: Bullseye and Buster will initially boot, but sometimes will not boot properly if doing a soft-reboot (ie. sudo reboot now), requiring a hard power-cycle to boot (which is a bit annoying since the board won't be in the easiest place to get to). At this stage I haven't done anything except the initial prompt to change the root password It has the same error message that UUID does not exist Log: https://pastebin.com/cnNbZVFT Post apt update/upgrade (Bullseye/Buster): With both Bullseye and Buster, I run apt update and apt upgrade since it's generally a good idea to keep packages up-to-date for security. I didn't change any other files or do anything else except run the update However in both, after running apt upgrade it is no longer able to boot no mater how many times I power cycle it. Also complains UUID does not exist Log: https://pastebin.com/pqyxBrvS After apt update was complete, but before power cycling/rebooting it I did check the UUIDs of the partitions using blkid and also checked /boot/armbianEnv.txt to check if either had changed. But the UUID's still matched what they were previously so it doesn't seem that anything got changed or corrupted In all the cases where it won't boot it seems to be complaining that the UUID for the rootfs doesn't exist. And I'm not sure how to fix it

Hello, is this issue fixed now ? I'm using OrangePi One Plus server, and three days ago I did apt -y upgrade. After that, it wont boot -- drops to initramfs ( UUID does not exist ). I did a peek here, and tried to qemu chroot to sdcard from a Focal running VM, and issued " update-initramfs -u ", but that did not solve my problem -- still wont boot. 12 hours ago I restored to a month old backup, and it booted fine ofc, but then I tried to upgrade again, as there is no more warning about broken Focal images, but sure enough, dropped to initramfs Is there something else I can try ?