vzoltan

/var/log is zram and it randomly throws errors, I really had more pressing issues to fix than that one... But thanks for the reminder! And I really thought that HK did fix the USB issues. Honestly, purchasing this N2 and investing so much time to make it work was one of the worst decisions in my life, if not the THE worst.

Hello @Igor thank you for your comment, however I'm afraid I don't follow you: do you say this should work (i.e. all CPU cores handling interrupts) and for some reason buggy with Armbian's N2 distro?

I'm not sure what is the cause and effect here, but what I saw today is weird. OS: Welcome to Armbian buster with Linux 4.9.219-meson64 Linux odroidn2 4.9.219-meson64 #1 SMP PREEMPT Wed Jun 3 12:42:50 CEST 2020 aarch64 GNU/Linux Symptom: I recently purchased a Seagate external HDD and wanted to use it with the N2. Started to replicate files from my other server over SFTP, and at the same time I also started Midnight Commander to check on the HDD content. As soon as I wanted to change directory to /mnt/seagate, my console became unresponsive, the SFTP connection failed and there wasn't really any way to unstuck this situation. Due to other reasons previously I applied quirks on the drive, therefore it is NOT in UAS mode: Bus 002 Device 006: ID 0bc2:331a Seagate RSS LLC root@odroidn2:/home/vz# lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M ... |__ Port 3: Dev 6, If 0, Class=Mass Storage, Driver=usb-storage, 5000M (* Other times I managed to "repro" this stuck behavior just by changing directory and executing a fairly simple ls -l from command prompt. I really don't know what's up with the USB storage handling...) Then I started a new SSH session and executed armbianmonitor -u. There I saw only CPU0 working, the other cores were idling: http://ix.io/2pVH Alright, somehow I managed to unmount the drive (needed to use the -f switch), then mount again, SFTP reconnected, file transfer started. There is an active transfer even right now, approx. 8MB/s, but still only CPU0 is working: root@odroidn2:/home/vz# armbianmonitor -n runtime network statistics: odroidn2 network interface: eth0 [tap 'd' to display column headings] [tap 'z' to reset counters] [use <ctrl-c> to exit] [bps: bits/s, Mbps: megabits/s, pps: packets/s, MB: megabytes] eth0 rx.stats____________________________________________________________ tx.stats____________________________________________________________ count bps Mbps ư.Mbps pps ư.pps Ʃ.MB bps Mbps ư.Mbps pps ư.pps Ʃ.MB 1 69363392 69.36 69.36 5853 5853 8.26 991072 .99 .99 1827 1827 .11 2 68955424 68.95 69.15 5827 5840 16.48 964480 .96 .97 1776 1801 .23 root@odroidn2:/home/vz# cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 10: 0 0 0 0 0 0 GIC-0 29 Level arch_timer 11: 6819558 33868946 983894 427047 2782528 266967 GIC-0 30 Level arch_timer 14: 0 0 0 0 0 0 GIC-0 92 Edge Meson TimerF 15: 3 0 0 0 0 0 GIC-0 192 Level ffe40000.bifrost 16: 0 0 0 0 0 0 GIC-0 193 Level ffe40000.bifrost 17: 0 0 0 0 0 0 GIC-0 194 Level ffe40000.bifrost 20: 3 0 0 0 0 0 GIC-0 241 Edge 21: 1 0 0 0 0 0 GIC-0 242 Edge 22: 62991952 0 0 0 0 0 GIC-0 40 Edge eth0 23: 1336993 0 0 0 0 0 GIC-0 62 Level xhci-hcd:usb1 24: 1 0 0 0 0 0 GIC-0 48 Level amlogic_botg_detect 25: 0 0 0 0 0 0 GIC-0 63 Level dwc_otg, dwc_otg_pcd 26: 0 0 0 0 0 0 GIC-0 232 Edge meson-g12a-saradc 27: 0 0 0 0 0 0 GIC-0 67 Edge ff634800.p_tsensor 28: 0 0 0 0 0 0 GIC-0 68 Edge ff634c00.d_tsensor 29: 0 0 0 0 0 0 GIC-0 247 Edge ffd1d000.i2c 31: 10078 0 0 0 0 0 GIC-0 71 Edge ffd1c000.i2c 33: 0 0 0 0 0 0 GIC-0 225 Edge meson_uart 41: 0 0 0 0 0 0 GIC-0 89 Edge hdmitx 43: 0 0 0 0 0 0 GIC-0 235 Edge hdmi_aocecb 45: 0 0 0 0 0 0 GIC-0 178 Edge ge2d 46: 17579444 0 0 0 0 0 GIC-0 35 Edge vsync, osd-vsync 47: 0 0 0 0 0 0 GIC-0 176 Edge gdc 54: 17579444 0 0 0 0 0 GIC-0 121 Edge rdma 55: 0 0 0 0 0 0 GIC-0 88 Edge osd-vsync-viu2 56: 5 0 0 0 0 0 GIC-0 223 Edge meson-aml-mmc 57: 4121 0 0 0 0 0 GIC-0 222 Edge meson-aml-mmc 59: 0 0 0 0 0 0 GIC-0 83 Edge dmc_monitor 69: 0 0 0 0 0 0 GIC-0 33 Edge audiolocker 70: 0 0 0 0 0 0 GIC-0 78 Edge pre_di 71: 0 0 0 0 0 0 GIC-0 72 Edge post_di 72: 255 0 0 0 0 0 GIC-0 228 Edge ir-meson IPI0: 84717127 63361081 17705172 10069318 6700169 4492021 Rescheduling interrupts IPI1: 27291 52009 49225 28653 26197 24202 Function call interrupts IPI2: 0 0 0 0 0 0 CPU stop interrupts IPI3: 0 0 0 0 0 0 Timer broadcast interrupts IPI4: 1238898 56645 442118 106174 1830596 58141 IRQ work interrupts IPI5: 0 0 0 0 0 0 CPU wake-up interrupts Err: 0 How is that possible? eth0 is definitely under load (alright, far away from the gigabit limit, but still), USB is also under load to write the received bytes to the disk... But it really seems like only CPU0 does care. Basically I'm a Windows guy for a looong time, but this is like unimaginable there, all the CPU cores do work and distribute the load... Maybe I just don't understand how this should work, but I thought it's better to report. Worst case I'll get educated on Linux.

Welcome to the club!

I'm afraid not. Just tried, my observations below: Welcome to Armbian Focal with Linux 5.6.18-meson64 Linux odroidn2 5.6.18-meson64 #20.05.4 SMP PREEMPT Mon Jun 15 01:50:20 CEST 2020 aarch64 aarch64 aarch64 GNU/Linux I had high hopes with kernel 5.6, but no luck, this is still not working, therefore need to revert to 4.9.x... Right now I have 3 USB devices connected to my N2: 1. Sandisk UFD: idVendor=0781, idProduct=5583 2. Seagate USB to SATA enclosure (ASM1053): idVendor=0bc2, idProduct=2322 3. JMS578 USB to SATA enclosure: idVendor=152d, idProduct=0578 What do I see after a "reboot" command in dmesg? 1. Sandisk is just fine, recognized: [ 3.487194] usb 2-1.4: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd [ 3.506316] usb 2-1.4: New USB device found, idVendor=0781, idProduct=5583, bcdDevice= 1.00 [ 3.506320] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 3.506323] usb 2-1.4: Product: Ultra Fit [ 3.506326] usb 2-1.4: Manufacturer: SanDisk and attached as sda: [ 4.514269] scsi 0:0:0:0: Direct-Access SanDisk Ultra Fit 1.00 PQ: 0 ANSI: 6 [ 4.514879] sd 0:0:0:0: [sda] 120176640 512-byte logical blocks: (61.5 GB/57.3 GiB) [ 4.515917] sd 0:0:0:0: [sda] Write Protect is off [ 4.515921] sd 0:0:0:0: [sda] Mode Sense: 43 00 00 00 [ 4.516227] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [ 4.547637] sda: sda1 [ 4.549671] sd 0:0:0:0: [sda] Attached SCSI removable disk 2. Seagate was recognized: [ 3.729400] usb 2-1.1: new SuperSpeed Gen 1 USB device number 4 using xhci-hcd [ 3.750186] usb 2-1.1: New USB device found, idVendor=0bc2, idProduct=2322, bcdDevice= 0.00 [ 3.750191] usb 2-1.1: New USB device strings: Mfr=2, Product=3, SerialNumber=1 [ 3.750194] usb 2-1.1: Product: Expansion [ 3.750197] usb 2-1.1: Manufacturer: Seagate but attached as sdb much later: [ 33.758648] USB_PWR_EN: disabling [ 35.818446] sd 1:0:0:0: tag#17 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN [ 35.818466] sd 1:0:0:0: tag#17 CDB: opcode=0x9e, sa=0x10 9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00 [ 35.834439] scsi host1: uas_eh_device_reset_handler start [ 35.914806] usb 2-1.1: reset SuperSpeed Gen 1 USB device number 4 using xhci-hcd [ 35.936879] scsi host1: uas_eh_device_reset_handler success [ 35.942879] sd 1:0:0:0: [sdb] 976773167 512-byte logical blocks: (500 GB/466 GiB) [ 36.283252] sd 1:0:0:0: [sdb] Write Protect is off [ 36.283256] sd 1:0:0:0: [sdb] Mode Sense: 4f 00 00 00 [ 36.283478] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 36.283748] sd 1:0:0:0: [sdb] Optimal transfer size 33553920 bytes [ 36.328292] Alternate GPT is invalid, using primary GPT. [ 36.328306] sdb: sdb1 [ 36.329552] sd 1:0:0:0: [sdb] Attached SCSI disk BTW what is USB_PWR_EN, are we looking at something interesting here? 3. Oh, yeah, and the JMS enclosure. That did not even power up after reboot, that's clearly obvious as the enclosure's LED wasn't up at all. After reconnecting manually to the USB port: [ 1202.061262] usb 2-1.2: new SuperSpeed Gen 1 USB device number 5 using xhci-hcd [ 1202.082455] usb 2-1.2: New USB device found, idVendor=152d, idProduct=0578, bcdDevice=31.02 [ 1202.082467] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1202.082475] usb 2-1.2: Product: USB to ATA/ATAPI Bridge [ 1202.082483] usb 2-1.2: Manufacturer: JMicron [ 1202.082491] usb 2-1.2: SerialNumber: 0123456789ABCDEF [ 1202.094431] scsi host2: uas [ 1202.095965] scsi 2:0:0:0: Direct-Access JMicron Generic 3102 PQ: 0 ANSI: 6 [ 1202.097561] sd 2:0:0:0: Attached scsi generic sg2 type 0 But actually being mounted as sdc needed another 30 seconds: [ 1233.991198] sdc: sdc1 [ 1233.995322] sd 2:0:0:0: [sdc] Attached SCSI disk -- What I see here: all the above just works with the 4.9.x kernels. My gut feeling is that this has to do something with USB power cycling (or the lack of it) during startup. Some other forums suggested to check on UAS and disable it via quirks, but this is clearly not an UAS problem, and both kernels (4.x and 5.x) have the UAS module loaded (checked with modprobe uas). @Igor do you have any idea how to proceed from here? EDIT: this is how the boot process looks like with 4.9, the JMS and my SSD is immediately recognized, no 30 seconds delays, etc. Actually I'm booting off the SD and then the system is already on the SSD (have moved there with nand-sata-install): [ 5.397633] usb 2-1.1: New USB device found, idVendor=152d, idProduct=0578 [ 5.397636] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 5.397639] usb 2-1.1: Product: USB to ATA/ATAPI Bridge [ 5.397641] usb 2-1.1: Manufacturer: JMicron [ 5.397643] usb 2-1.1: SerialNumber: 0123456789ABCDEF [ 5.407569] scsi host0: uas [ 5.410712] scsi 0:0:0:0: Direct-Access JMicron Generic 3102 PQ: 0 ANSI: 6 [ 5.454904] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 5.952266] sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/233 GiB) [ 5.952270] sd 0:0:0:0: [sda] 4096-byte physical blocks [ 5.953160] sd 0:0:0:0: [sda] Write Protect is off [ 5.953165] sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08 [ 5.953512] sd 0:0:0:0: [sda] Disabling FUA [ 5.953516] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5.953659] xhci-hcd xhci-hcd.0.auto: ERROR Transfer event for disabled endpoint or incorrect stream ring [ 5.953663] xhci-hcd xhci-hcd.0.auto: @00000000cf612c60 00000000 00000000 1b000000 04078001 [ 5.953848] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes) [ 5.956601] sda: sda1 [ 5.961031] sd 0:0:0:0: [sda] Attached SCSI disk [ 6.739699] EXT4-fs (sda1): mounted filesystem with writeback data mode. Opts: data=writeback

I'm getting out of ideas how to make more visibility for this. I reported here and other armbian forums, reddit, etc. but honestly not much has happened. While I'm fine for now with the legacy kernel, that won't last forever. How do you guys cope with this issue, until the linux devs (?) take care of it? If they will ever...

Team, do we expect to have any improvements here, besides dumping the JMicron USB-SATA enclosures? I don't believe it is JMS issue at all, given my ASM1153 based USB-SATA adapter is also failing with any of the 5.4 kernels to boot from SATA. It just works with 4.9.x, therefore my guess is we are dealing with a Linux issue here, but that's where my skills end - how to proceed from here? Anybody aware of a bug tracking this one? @qstaqI've seen you put quite some efforts into this troubleshooting, any comments maybe?

Yes, it works perfectly with a UFD with the 5.4.x kernel, therefore this is in fact some weird USB hub handling issue. I do follow a few forums / reddit on similar issues, not sure where I read, but somebody mentioned they was facing the same USB-SATA issue, but the same USB-SATA adapter worked with an active (!) USB3 hub in-between the odroid and the disk. As I don't have any at home, I wasn't able to test that part. BTW, can you point me please to any guide how to completely move the boot files too to the SATA disk? Actually I don't need the SD at all, but I'm also quite novice with Linux / SBCs to make this work. Thanks.

Update here, as I don't want you guys overthink this issue. Later this morning I totally gave up on the latest 5.4 kernel images, and tried with a 4.9.x as in other forums I've been told. That works PERFECTLY. Therefore I tend to say this is a Linux kernel issue, and there shall be some kind of regressions regarding USB handling in the 5.x branch. I do, but as stated above, it might not be that relevant anymore, we are looking for a Linux issue here.

Finally I made this work with Armbian_20.02.5_Odroidn2_buster_legacy_4.9.216, basically can confirm your experience. What is still strange, how come the 5.x kernel works like a charm with a UFD stick, and fails to recognize the USB-SATA disk... Are you aware of any bug being tracking for this one?

Alright, I received the serial cable, but I'm not wiser at all. - odroid N2 flashed and boots from SD: root@odroidn2:/boot# uname -a Linux odroidn2 5.4.21-meson64 #20.02.3 SMP PREEMPT Fri Feb 21 17:46:54 CET 2020 aarch64 aarch64 aarch64 GNU/Linux - nand-sata-install script executed, SD to USB (Ext4) successful - boot.ini is changed in fact to the USB enclosure's GUID - after reboot, NOTHING, just the black screen. Honestly I don't know what should I look for in the serial log. It is also stuck there: bestmode is custombuilt, IEEEOUI 0x000c03 HDMI Mode 21543488 bytes read in 1206 ms (17 MiB/s) 69790 bytes read in 33 ms (2 MiB/s) 9586682 bytes read in 554 ms (16.5 MiB/s) ee_gate_off ... ## Booting kernel from Legacy Image at 01080000 ... Image Name: Linux Image Type: AArch64 Linux Kernel Image (uncompressed) Data Size: 21543424 Bytes = 20.5 MiB Load Address: 01080000 Entry Point: 01080000 Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at 03700000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 9586618 Bytes = 9.1 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK load dtb from 0x1000000 ...... ## Flattened Device Tree blob at 01000000 Booting using the fdt blob at 0x1000000 libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND Loading Kernel Image(COMP_NONE) ... OK kernel loaded at 0x01080000, end = 0x0250ba00 libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND [rsvmem] fdt get prop fail. Loading Ramdisk to 3cedb000, end 3d7ff7ba ... OK Loading Device Tree to 000000001ffeb000, end 000000001ffff09d ... OK Starting kernel ... uboot time: 11402365 us Compared to the working scenario (only from SD, before the move to USB-SSD): Starting kernel ... uboot time: 10797279 us [ 4.742576] debugfs: Directory 'ff800280.cec' with parent 'regmap' already present! [ 4.746987] pwm-regulator regulator-vddcpu-a: Failed to get PWM: -517 [ 4.753785] cpu cpu2: Failed to set regulator for cpu2: -517 [ 4.759331] cpu cpu3: Failed to set regulator for cpu3: -517 [ 4.762478] cpu cpu4: Failed to set regulator for cpu4: -517 [ 4.767950] cpu cpu5: Failed to set regulator for cpu5: -517 Armbian 20.02.3 Bionic ttyAML0 odroidn2 login: How to continue from here...?

Three updates here till I'm waiting for that UART cable to be delivered... 1. Tried with another SATA-USB enclosure, and I see a similar pattern here, check the timestamps: [ 375.366411] usb 2-1.1: new SuperSpeed Gen 1 USB device number 4 using xhci-hcd [ 375.387499] usb 2-1.1: New USB device found, idVendor=152d, idProduct=0578, bcdDevice= 2.03 [ 375.387511] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 375.387520] usb 2-1.1: Product: External Disk 3.0 [ 375.387529] usb 2-1.1: Manufacturer: JMicron [ 375.387538] usb 2-1.1: SerialNumber: DB12345681BC [ 375.391386] scsi host0: uas [ 375.392410] scsi 0:0:0:0: Direct-Access JMicron Tech 0203 PQ: 0 ANSI: 6 [ 406.488988] sd 0:0:0:0: tag#5 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN [ 406.488998] sd 0:0:0:0: tag#5 CDB: opcode=0x12 12 01 00 00 40 00 [ 406.509006] scsi host0: uas_eh_device_reset_handler start [ 406.589332] usb 2-1.1: reset SuperSpeed Gen 1 USB device number 4 using xhci-hcd [ 406.611661] scsi host0: uas_eh_device_reset_handler success [ 406.617474] sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/233 GiB) [ 406.617481] sd 0:0:0:0: [sda] 4096-byte physical blocks [ 406.617655] sd 0:0:0:0: [sda] Write Protect is off [ 406.617665] sd 0:0:0:0: [sda] Mode Sense: 53 00 00 08 [ 406.617959] sd 0:0:0:0: [sda] Disabling FUA [ 406.617966] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 406.618258] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes) [ 406.644251] sda: sda1 [ 406.645838] sd 0:0:0:0: [sda] Attached SCSI disk It takes ~30 seconds to get the drive as SDA1 recognized! The same happened with that Seagate enclosure... I suppose that's a no-GO during boot time. Is there any way to add a delay to the boot process, let's give the N2 some time to recognize the USB drive? 2. Tried the SD to USB move with a plain simple USB flash drive. Works without a glitch, but at the same time, the UFD is recognized as a USB storage device like in no time compared to the above examples. 3. The most disappointing thing was that the enclosure was totally not recognized after a reboot, only after I disconnected and reconnected to the USB port. That excludes then any remote or unattended functionality, a total deal breaker, but I suppose this is Odroid's fault, and not something Armbian could do anything...

I might face the same troubles like you, described here FYI: I'm using Armbian_20.02.3_Odroidn2_bionic_current_5.4.21_minimal.img Two updates on top of that thread: - I'm waiting for the serial cable, found a merchant with quicker delivery -> that shall help better understand what is going on under the hood - I tested with a USB flash drive and managed to move my system from SD to there. That worked without any glitch. Therefore I suppose there is a real problem with the USB/SATA handling itself...

But those are already there: ,0x0bc2:0x2322:u, u = IGNORE_UAS (don't bind to the uas driver);

I understand that without the serial connection we won't know what is happening on my very box. Maybe I should ask different questions in regards to how this move from SD to USB (SATA) works. 1. Is there any further actions needed after the nand-sata-install script completes? Is that working "out-of-the-box" for others? 2. Is that right that the PARTUUID shall be changed after the SD is replicated to the external drive? 3. Is there any experience with moving SD to an external SATA SSD in a USB enclosure? 4. What is usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x0bc2:0x2322:u,0x1058:0x25ee:u in armbianEnv.txt? BTW, this is my USB SATA being recognized, if you guys see anything relevant here... Seems like that 0x0bc2:0x2322 is related (Vendor and Product IDs), but what about the other values? [ 672.200956] usb 2-1.3: new SuperSpeed Gen 1 USB device number 3 using xhci-hcd [ 672.221830] usb 2-1.3: New USB device found, idVendor=0bc2, idProduct=2322, bcdDevice= 0.00 [ 672.221842] usb 2-1.3: New USB device strings: Mfr=2, Product=3, SerialNumber=1 [ 672.221851] usb 2-1.3: Product: Expansion [ 672.221860] usb 2-1.3: Manufacturer: Seagate [ 672.221869] usb 2-1.3: SerialNumber: NZ0... [ 672.251170] scsi host0: uas [ 672.254784] scsi 0:0:0:0: Direct-Access Seagate Expansion 9300 PQ: 0 ANSI: 6 [ 672.254849] usbcore: registered new interface driver uas [ 703.435448] sd 0:0:0:0: tag#21 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD IN [ 703.435454] sd 0:0:0:0: tag#21 CDB: opcode=0x9e, sa=0x10 9e 10 00 00 00 00 00 00 00 00 00 00 00 20 00 00 [ 703.455446] scsi host0: uas_eh_device_reset_handler start [ 703.535597] usb 2-1.3: reset SuperSpeed Gen 1 USB device number 3 using xhci-hcd [ 703.556830] scsi host0: uas_eh_device_reset_handler success [ 703.567820] sd 0:0:0:0: [sda] 488397167 512-byte logical blocks: (250 GB/233 GiB) [ 703.569088] sd 0:0:0:0: [sda] Write Protect is off [ 703.569091] sd 0:0:0:0: [sda] Mode Sense: 4f 00 00 00 [ 703.569289] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 703.569511] sd 0:0:0:0: [sda] Optimal transfer size 33553920 bytes [ 703.593112] sda: sda1 [ 703.594248] sd 0:0:0:0: [sda] Attached SCSI disk

Hello there, is there any "secret" how to make nand-sata-install work with a Odroid N2? I wanted to move the system to a proper SSD (USB) instead of killing the SD card with wear in the long run. There is actually a tool to accomplish this task easily: https://docs.armbian.com/User-Guide_Getting-Started/#how-to-install-to-emmc-nand-sata-usb However after power cycling the N2, it didn't boot anymore. The boot.ini has been changed in fact to the UUID of my SSD: setenv rootdev "UUID=5d0f77d8-xxx-xxx" setenv rootfstype "ext4" It does match: root@odroidn2:/home/n2# blkid /dev/mmcblk1p1: UUID="2b2fb355-yyy-yyy" TYPE="ext4" PARTUUID="70bd7af3-01" /dev/sda1: UUID="5d0f77d8-xxx-xxx" TYPE="ext4" PARTUUID="70bd7af3-01" At Reddit ( https://www.reddit.com/r/ODroid/comments/fp2f0k/armbian_bionic_54_tried_to_move_to_usb_ssd_doesnt/ ) I've been told to change the PARTUUID, I did so and changed the PARTUUID of the SSD - still doesn't boot, or honestly I don't know what is happening, because all I see is a black screen over HDMI. I decided to roll back the boot.ini and armbian.env files to the UUID of the SD -> then it ended up in an "emergency mode". Wish I had a serial cable to check the debug output, but I don't have any and shipping dates (maybe due to Covid?) are due to 3-4 weeks. Do you have any suggestion how to proceed from here?