Legendary ODROID M1 Ubuntu 22.04.1 Images

Published: October 2, 2022 / Last Modified: August 2, 2023 / Hardware, Linux, ODROID / 45 Comments

Recently I reviewed the ODROID M1 and it’s a fantastic board. One problem with it though is that the image available for it is still only Ubuntu 20.04.

It’s possible to upgrade the server version to 22.04 and then install Ubuntu Desktop which I covered in my review. It’s painful though and takes a very long time especially if you want to install a desktop environment afterward.

I figured by now the updated image would be out and it still isn’t so today I’m releasing my Legendary ODROID M1 Ubuntu 22.04.1 images as well as the system I used to build the images!

Hardware Used

This is the 4 GB version of the ODROID M1. Includes a full size (2280) M.2 slot (PCIe 3.0 2 lanes), a Neural Processing Unit (NPU) and contains a RK3568B2 SOC. There is a slot for eMMC cards on the board as well and these perform very well.

Links: Amazon.com*, AliExpress.com*

This is the 8 GB version of the ODROID M1. Includes a full size (2280) M.2 slot (PCIe 3.0 2 lanes), a Neural Processing Unit (NPU) and contains a RK3568B2 SOC. There is a slot for eMMC cards on the board as well and these perform very well.

Links: Amazon.com*, AliExpress.com*

Overview

These images are upgraded to 22.04.1 and use the latest kernel from the ODROID repositories (6.0.x at time of writing). I have included convenience scripts in the home folder to enable and disable the NPU. This will work in all flavors (including server).

This is not using a mainline kernel. It is using the official ODROID 6.0.x kernel packages from their PPA repository. It looks like to me they’re getting really close to finishing support so they aren’t quite finished but if you aren’t using the NPU it’s finished enough.

Since it’s using official packages these will update with apt over time so there’s a good chance the NPU may fix itself when they add a compatible rknpu overlay to the kernel package.

The GitHub repository is available here

Images ready to be downloaded are available here

Flavors Available

The script is currently building 6 different flavors:

Ubuntu 22.04.1 Server
Ubuntu 22.04.1 MATE Desktop (ubuntu-mate-desktop)
Ubuntu 22.04.1 Desktop (ubuntu-desktop)
Xubuntu 22.04.1 Desktop (xubuntu-desktop)
Kubuntu 22.04.1 Desktop (kubuntu-desktop)
Lubuntu 22.04.1 Desktop (lubuntu-desktop)

Known Issues

The NPU overlay (rknpu) is not present in the 6.0.x branch yet

Image Instructions

The images are in .tar.xz format and should not be written to disk until you decompressed them with:

tar -xf *.tar.xz.

That will give you a .img file that will boot successfully. If you are using Windows you can decompress these files with 7zip or WinRAR.

First Startup Instructions

Note that the first startup is slow. This is due to resizing your root filesystem to fit your drive. After the first startup it will boot much faster but it may take several minutes on a black screen with only a few lines of text on it during the first startup. Be patient. If you see a few lines of text then it is resizing your root filesystem.

You may also see CRC checksum errors during your first startup. These are safe to ignore as it will run fsck on the drive the first startup. When you reboot the device these will be gone.

Set correct timezone:

sudo dpkg-reconfigure tzdata

Set correct locale:

sudo apt install locales -y && sudo dpkg-reconfigure locales

Get web browser (desktop only)

sudo snap install firefox
sudo snap install chromium

Build Instructions

If you would like to build the image yourself it is pretty straightforward with the included script. You will need a few dependencies such as:

sudo apt install build-essential guestfs-tools kpartx

Now run the build script with sudo ./BuildImage.sh. It will retrieve the base image from ODROID’s servers and update it.

It definitely takes a long time to build the images even with a very powerful computer but if you just let it run in the background and do it’s thing it should complete and spit out the images for you.

Getting Support

If you need help with something specific to my image then this is the best place for support right here in the comment section.

Let me know if there are packages missing that need to be present or any other issues going on and I will get them added in updated versions!

Other Resources

This image was created due to investigating comments on my ODRO ID M1 Review

I’ve also covered SSD booting with the ODROID N2+ here

If you like retro gaming you’ll really like the ODROID Go Super handheld gaming console

I have also created a fixed image for the Orange Pi i96 which is an older board that can be found for around $7-$15 (for now)

45 thoughts on “Legendary ODROID M1 Ubuntu 22.04.1 Images”

Carlos
February 6, 2023 at 3:15 pm

Hi james,

could you comment on how to get non-standard resolutions to work? I have a samsung 3440×1440 but I’ confused on where to set that? boot.ini seems to be absent. I tried a couple of things but no luck. Thanks!
1. James A. Chambers
  February 6, 2023 at 4:13 pm
  
  Hey Carlos,
  
  It should be config.ini in newer ODROID kernels I believe. The boot.ini file is deprecated for the ODROID M1. Check out this article here.
  
  Theoretically if it’s deprecated you could still recreate boot.ini and do it that way. It looks like there’s a new way to do it with config.ini but it’s not exactly the same.
  
  I would check this article out here. This tells you how to do it using config.ini with the ODROID N2. It should be exactly the same for the ODROID M1 as that one definitely also uses config.ini.
  
  Hopefully that helps
mrvazil
December 2, 2022 at 11:44 am

Hi james,

Is there a way to install this image to the SSD from a USB stick?
1. James A. Chambers
  December 2, 2022 at 11:05 pm
  
  Hey mrvazil,
  
  Great question! So if you follow my ODROID M1 Review I actually do give instructions / a walkthrough on how to image the SSD from a USB drive.
  
  You could basically follow those instructions and just swap out the image I used in that guide for the one from this one if that makes sense. Hopefully that helps!
  1. mrvazil
    December 4, 2022 at 3:08 pm
    
    That worked great, thanks!
    For anyone having issues: if you use windows to prep the USB drive, make sure it is formatted in FAT32 and not exFAT, as the odroid can’t mount that
    1. James A. Chambers
      December 4, 2022 at 4:14 pm
      
      Hey mrvazil,
      
      Glad to hear it and thanks for the tip about the Windows USB drive prep. That will help people out for sure. Enjoy and take care!
Richard
November 17, 2022 at 8:31 am

Hey Mr. Chambers,

i use the legendary 1.3 Image and am pleased with the easy setup. Sadly no IR seems to work rn, the GPIO device is not listed. There is discussion here with a dtb provided to make it work in 5.19 but i guess it won’t fix it in 6.0?
1. James A. Chambers
  November 17, 2022 at 9:29 am
  
  Hey Richard,
  
  Welcome and great question! So version 1.2 of this image still uses kernel 5.19. If I was in your shoes what I would do is try using the 5.19 dtb with the 6.0 kernel and see if it is close enough that it will take it.
  
  If it won’t you could download the version of my image that has 5.19.x in it to test and see if putting the dtb in there will work. If this does work there’s nothing really wrong with using the version that has the 5.19.x branch if that lets you use the hardware you need to use.
  
  Basically you can switch between the different kernels actually within the OS by installing the different versions from apt. That’s why I think you may be able to work around this. The 5.19.x kernel branch is still super, super new compared to the official images and a much better choice. I think that if the 6.0 or 5.19.x version will take that dtb you should be able to get this going potentially!
Frederic
November 9, 2022 at 12:10 pm

Hi James A. Chambers,

I am using the 22.04.01 Server image on a nvme 970 evo plus SSD (500 GB):

Thanks to your images I’ve moved to 22.04.01, unfortunately I am facing to some downgrade:

1) No way to use the dhcp services embedded into the box of my internet provider to get a static @IP thru DHCP as the odroid mac address is changing each time the link is switching up.
So I had to install network-manager and configure netplan to get a static address.

2) USB 3 is not working and as my odroidm1 is supposed to be a router using Startechusb32000spt (dual GE) that is supported by kernel AND working perfectly on 20.04, the only way to use my Odroid is to accept to downgrade bandwidth to 480Mbit/s rather than 2 x 1 Gbit/s (lacp bond) and plug Startech on one of the 2 USB2 ports.

If you can find a way to fix this USB issue as well as volatile MAC address it will be a great Christmas present.

I had also add:

sudo apt install lsusb ethtool ufw macchanger man locales
and reconfigure kbd, locales according to my conf.

and add rclone using: sudo -v ; curl https://rclone.org/install.sh | sudo bash
rather than standard package as v1.60 vs v1.53 ==> 2-3 years of improvement.
1. James A. Chambers
  November 9, 2022 at 1:16 pm
  
  Hey Frederic,
  
  Thanks for leaving your experience! I can see several things I can improve like all of the packages you listed should be included (I’ll get these added for sure).
  
  I have some questions about your USB 3.0. So USB 3.0 not working on this image should not be a thing. I went and tested my USB 3.0 and it has always worked for me. My test rig is admittedly running a desktop image though.
  
  Can you confirm that no devices work in USB 3.0 or is this only specifically the StarTech usb32000spt that isn’t working with USB 3.0? If you can confirm that no devices are working with USB 3.0 on the server image I’d definitely be willing to reimage my M1 with the server image just to test this and see what is going on.
  
  This should be using the 5.19.x kernel branch if you do a:
  
  uname -a
  
  Can you share your lsusb output? Do you have any output in dmesg when you plug it in such as errors? Is it just not detected at all?
  
  And for the ODROID MAC address yes that issue came up not too long ago and I’d imagine it has something to do with this:
  
  rk_gmac-dwmac fe2a0000.ethernet: IRQ eth_lpi not found [ 2.983521] rk_gmac-dwmac fe2a0000.ethernet: no regulator found [ 2.984007] rockchip-vop2 fe040000.vop: Adding to iommu group 0 [ 2.984058] rk_gmac-dwmac fe2a0000.ethernet: clock input or output? (output). [ 2.984074] rk_gmac-dwmac fe2a0000.ethernet: TX delay(0x4f). [ 2.984079] rk_gmac-dwmac fe2a0000.ethernet: RX delay(0x2d). [ 2.984088] rk_gmac-dwmac fe2a0000.ethernet: integrated PHY? (no). [ 2.987631] rockchip-drm display-subsystem: bound fe040000.vop (ops vop2_component_ops [rockchipdrm]) [ 2.989135] rk_gmac-dwmac fe2a0000.ethernet: init for RGMII [ 2.989362] rk_gmac-dwmac fe2a0000.ethernet: User ID: 0x30, Synopsys ID: 0x51 [ 2.989382] rk_gmac-dwmac fe2a0000.ethernet: DWMAC4/5 [ 2.989389] rk_gmac-dwmac fe2a0000.ethernet: DMA HW capability register supported [ 2.989394] rk_gmac-dwmac fe2a0000.ethernet: RX Checksum Offload Engine supported [ 2.989397] rk_gmac-dwmac fe2a0000.ethernet: TX Checksum insertion supported [ 2.989401] rk_gmac-dwmac fe2a0000.ethernet: Wake-Up On Lan supported [ 2.989476] rk_gmac-dwmac fe2a0000.ethernet: TSO supported [ 2.989482] rk_gmac-dwmac fe2a0000.ethernet: Enable RX Mitigation via HW Watchdog Timer [ 2.989495] rk_gmac-dwmac fe2a0000.ethernet: device MAC address d6:81:89:a6:f5:6a [ 2.989501] rk_gmac-dwmac fe2a0000.ethernet: Enabled RFS Flow TC (entries=10) [ 2.989507] rk_gmac-dwmac fe2a0000.ethernet: TSO feature enabled [ 2.989511] rk_gmac-dwmac fe2a0000.ethernet: Using 32 bits DMA width
  
  It seems like the 5.19.x kernel branch is missing something to do with storing the MAC address (or it is having some kind of error retrieving it). The netplan fix you did was the best one I know of for now but I will definitely investigate (and am open to) better solutions to this problem for sure.
  
  It’s honestly easier to do the netplan fix on the desktop images because netplan is already there. One option would be to install netplan on the server image as well and perhaps even generate a random MAC at first startup so that not everyone using the image has literally the exact same MAC address (which is definitely a bad idea and would be a problem even if you only had 2 of them on the same network) if I can’t come up with a better way to just fix it outright.
  
  I’d love to give a fix for the MAC address as a Christmas present if possible! I honestly think that even as a worst case scenario I could simply generate a random netplan address and apply the netplan configuration for them on first startup. I will definitely investigate!
  1. Frederic
    November 9, 2022 at 4:20 pm
    
    Hi,
    
    Yes everything was working perfectly, Just before to use it on my odroid I was running this Startech.com dual Ethernet with a NUC 10i7 running Linux 22.04.1 (I use them as nodes for my private lab of Openstack): USB3 was working perfectly.
    this Odroid is supposed to become a router/fw between different vlans and my internet provider box.
    when I switch from USB2 to USB3 it is like a Thanos’ snap “decimation”: led are switching off immediately, even a power off / power on is not able to reset the situation, but when I failback USB3 to USB2, dongle leds are coming back to life and my router is up and running again.
    
    root@cerbere:~# uname -a Linux cerbere 5.19.0-odroid-arm64 #1 SMP PREEMPT Ubuntu 5.19.17-202211021456~jammy (2022-11-02) aarch64 aarch64 aarch64 GNU/Linux
    
    root@cerbere:~# lsusb Bus 004 Device 002: ID 413c:2113 Dell Computer Corp. KB216 Wired Keyboard Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 004: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet Bus 001 Device 003: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet Bus 001 Device 002: ID 2109:2811 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 008 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    
    root@cerbere:~# lsusb -v Bus 001 Device 004: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.10 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0b95 ASIX Electronics Corp. idProduct 0x1790 AX88179 Gigabit Ethernet bcdDevice 1.00 iManufacturer 1 ASIX Elec. Corp. iProduct 2 AX88179 iSerial 3 00000000000001 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0027 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 248mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 4 Network_Interface Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0008 1x 8 bytes bInterval 11 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Binary Object Store Descriptor: bLength 5 bDescriptorType 15 wTotalLength 0x0016 bNumDeviceCaps 2 USB 2.0 Extension Device Capability: bLength 7 bDescriptorType 16 bDevCapabilityType 2 bmAttributes 0x00000002 HIRD Link Power Management (LPM) Supported SuperSpeed USB Device Capability: bLength 10 bDescriptorType 16 bDevCapabilityType 3 bmAttributes 0x00 wSpeedsSupported 0x000e Device can operate at Full Speed (12Mbps) Device can operate at High Speed (480Mbps) Device can operate at SuperSpeed (5Gbps) bFunctionalitySupport 1 Lowest fully-functional device speed is Full Speed (12Mbps) bU1DevExitLat 1 micro seconds bU2DevExitLat 101 micro seconds Device Status: 0x0000 (Bus Powered)
    
    Bus 001 Device 003: ID 0b95:1790 ASIX Electronics Corp. AX88179 Gigabit Ethernet
    Device Descriptor:
    bLength 18
    bDescriptorType 1
    bcdUSB 2.10
    bDeviceClass 255 Vendor Specific Class
    bDeviceSubClass 255 Vendor Specific Subclass
    bDeviceProtocol 0
    bMaxPacketSize0 64
    idVendor 0x0b95 ASIX Electronics Corp.
    idProduct 0x1790 AX88179 Gigabit Ethernet
    bcdDevice 1.00
    iManufacturer 1 ASIX Elec. Corp.
    iProduct 2 AX88179
    iSerial 3 00000000000001
    bNumConfigurations 1
    Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 0x0027
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xa0
    (Bus Powered)
    Remote Wakeup
    MaxPower 248mA
    Interface Descriptor:
    bLength 9
    bDescriptorType 4
    bInterfaceNumber 0
    bAlternateSetting 0
    bNumEndpoints 3
    bInterfaceClass 255 Vendor Specific Class
    bInterfaceSubClass 255 Vendor Specific Subclass
    bInterfaceProtocol 0
    iInterface 4 Network_Interface
    Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x81 EP 1 IN
    bmAttributes 3
    Transfer Type Interrupt
    Synch Type None
    Usage Type Data
    wMaxPacketSize 0x0008 1x 8 bytes
    bInterval 11
    Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x82 EP 2 IN
    bmAttributes 2
    Transfer Type Bulk
    Synch Type None
    Usage Type Data
    wMaxPacketSize 0x0200 1x 512 bytes
    bInterval 0
    Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x03 EP 3 OUT
    bmAttributes 2
    Transfer Type Bulk
    Synch Type None
    Usage Type Data
    wMaxPacketSize 0x0200 1x 512 bytes
    bInterval 0
    Binary Object Store Descriptor:
    bLength 5
    bDescriptorType 15
    wTotalLength 0x0016
    bNumDeviceCaps 2
    USB 2.0 Extension Device Capability:
    bLength 7
    bDescriptorType 16
    bDevCapabilityType 2
    bmAttributes 0x00000002
    HIRD Link Power Management (LPM) Supported
    SuperSpeed USB Device Capability:
    bLength 10
    bDescriptorType 16
    bDevCapabilityType 3
    bmAttributes 0x00
    wSpeedsSupported 0x000e
    Device can operate at Full Speed (12Mbps)
    Device can operate at High Speed (480Mbps)
    Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport 1
    Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat 1 micro seconds
    bU2DevExitLat 101 micro seconds
    Device Status: 0x0000
    (Bus Powered)
    
    Bus 001 Device 002: ID 2109:2811 VIA Labs, Inc. Hub
    Device Descriptor:
    bLength 18
    bDescriptorType 1
    bcdUSB 2.10
    bDeviceClass 9 Hub
    bDeviceSubClass 0
    bDeviceProtocol 1 Single TT
    bMaxPacketSize0 64
    idVendor 0x2109 VIA Labs, Inc.
    idProduct 0x2811 Hub
    bcdDevice 91.00
    iManufacturer 1 VIA Labs, Inc.
    iProduct 2 USB2.0 Hub
    iSerial 0
    bNumConfigurations 1
    Configuration Descriptor:
    bLength 9
    bDescriptorType 2
    wTotalLength 0x0019
    bNumInterfaces 1
    bConfigurationValue 1
    iConfiguration 0
    bmAttributes 0xe0
    Self Powered
    Remote Wakeup
    MaxPower 0mA
    Interface Descriptor:
    bLength 9
    bDescriptorType 4
    bInterfaceNumber 0
    bAlternateSetting 0
    bNumEndpoints 1
    bInterfaceClass 9 Hub
    bInterfaceSubClass 0
    bInterfaceProtocol 0 Full speed (or root) hub
    iInterface 0
    Endpoint Descriptor:
    bLength 7
    bDescriptorType 5
    bEndpointAddress 0x81 EP 1 IN
    bmAttributes 3
    Transfer Type Interrupt
    Synch Type None
    Usage Type Data
    wMaxPacketSize 0x0001 1x 1 bytes
    bInterval 12
    Hub Descriptor:
    bLength 9
    bDescriptorType 41
    nNbrPorts 4
    wHubCharacteristic 0x00e9
    Per-port power switching
    Per-port overcurrent protection
    TT think time 32 FS bits
    Port indicators
    bPwrOn2PwrGood 50 * 2 milli seconds
    bHubContrCurrent 100 milli Ampere
    DeviceRemovable 0x00
    PortPwrCtrlMask 0xff
    Hub Port Status:
    Port 1: 0000.0503 highspeed power enable connect
    Port 2: 0000.0503 highspeed power enable connect
    Port 3: 0000.0100 power
    Port 4: 0000.0100 power
    Binary Object Store Descriptor:
    bLength 5
    bDescriptorType 15
    wTotalLength 0x002a
    bNumDeviceCaps 3
    USB 2.0 Extension Device Capability:
    bLength 7
    bDescriptorType 16
    bDevCapabilityType 2
    bmAttributes 0x00000002
    HIRD Link Power Management (LPM) Supported
    SuperSpeed USB Device Capability:
    bLength 10
    bDescriptorType 16
    bDevCapabilityType 3
    bmAttributes 0x00
    wSpeedsSupported 0x000e
    Device can operate at Full Speed (12Mbps)
    Device can operate at High Speed (480Mbps)
    Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport 1
    Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat 4 micro seconds
    bU2DevExitLat 231 micro seconds
    Container ID Device Capability:
    bLength 20
    bDescriptorType 16
    bDevCapabilityType 4
    bReserved 0
    ContainerID {24d91e54-bb15-424d-9abe-47dd3d6da65b}
    Device Status: 0x0001
    Self Powered
    
    root@cerbere:~# lsmod Module Size Used by nf_tables 225280 0 nfnetlink 20480 1 nf_tables bonding 192512 0 rfkill 36864 1 cpufreq_powersave 20480 0 cpufreq_conservative 16384 0 snd_soc_hdmi_codec 24576 1 snd_soc_simple_card 24576 0 snd_soc_simple_card_utils 28672 1 snd_soc_simple_card snd_soc_rockchip_i2s_tdm 32768 2 display_connector 20480 0 snd_soc_core 233472 4 snd_soc_rockchip_i2s_tdm,snd_soc_hdmi_codec,snd_soc_simple_card_utils,snd_soc_simple_card rockchip_saradc 24576 0 rockchip_thermal 28672 0 snd_pcm_dmaengine 20480 1 snd_soc_core snd_pcm 139264 4 snd_soc_hdmi_codec,snd_soc_simple_card_utils,snd_soc_core,snd_pcm_dmaengine snd_timer 40960 1 snd_pcm snd 102400 4 snd_soc_hdmi_codec,snd_timer,snd_soc_core,snd_pcm soundcore 16384 1 snd dw_hdmi_i2s_audio 16384 0 panfrost 69632 0 gpu_sched 40960 1 panfrost drm_shmem_helper 28672 1 panfrost sch_fq_codel 24576 4 fuse 131072 1 ip_tables 32768 0 x_tables 49152 1 ip_tables ax88179_178a 36864 0 realtek 32768 1 dwmac_rk 28672 0 stmmac_platform 24576 1 dwmac_rk rockchipdrm 139264 0 stmmac 237568 2 stmmac_platform,dwmac_rk drm_cma_helper 24576 1 rockchipdrm dw_hdmi 53248 2 dw_hdmi_i2s_audio,rockchipdrm nvme 49152 2 spidev 24576 0 sdhci_of_dwcmshc 20480 0 phylink 49152 1 stmmac drm_display_helper 147456 1 dw_hdmi cec 77824 2 drm_display_helper,dw_hdmi rtc_rk808 20480 1 dw_mipi_dsi 20480 1 rockchipdrm drm_kms_helper 176128 8 drm_cma_helper,dw_mipi_dsi,display_connector,drm_display_helper,rockchipdrm,dw_hdmi cfbfillrect 16384 1 drm_kms_helper nvme_core 114688 3 nvme cfbimgblt 16384 1 drm_kms_helper cfbcopyarea 16384 1 drm_kms_helper drm 557056 11 drm_cma_helper,gpu_sched,drm_kms_helper,dw_mipi_dsi,display_connector,drm_shmem_helper,drm_display_helper,rockchipdrm,dw_hdmi,panfrost ahci_platform 16384 0 libahci_platform 24576 1 ahci_platform libahci 49152 2 libahci_platform,ahci_platform libata 241664 3 libahci,libahci_platform,ahci_platform drm_panel_orientation_quirks 16384 1 drm root@cerbere:~#
    
    Question: Do you have any output in dmesg when you plug it in such as errors? Is it just not detected at all?
    Answer: there is no detection at all: the ethernet leds of the usb dongle are off.
    
    something strange:
    a USB3 Storage key is working fine on USB3 port:
    root@cerbere:~# lsblk -a -O > /tmp/lsblk-a-O.StorageUSB3.txt root@cerbere:~# lsblk -a NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 1 28,7G 0 disk |-sda1 8:1 1 256M 0 part-sda2 8:2 1 28,4G 0 part / nvme0n1 259:0 0 465,8G 0 disk |-nvme0n1p1 259:1 0 256M 0 part /boot-nvme0n1p2 259:2 0 465,5G 0 part /
    root@cerbere:~# lsblk
    NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
    sda 8:0 1 28,7G 0 disk
    |-sda1 8:1 1 256M 0 part
    -sda2 8:2 1 28,4G 0 part / nvme0n1 259:0 0 465,8G 0 disk |-nvme0n1p1 259:1 0 256M 0 part /boot-nvme0n1p2 259:2 0 465,5G 0 part /
    root@cerbere:~#
    
    Now I eject the USB CARD from USB3 slot.
    
    root@cerbere:~# lsblk -a -O > /tmp/lsblk-a-O.WithOut-USB3-Storage.txt root@cerbere:~# lsblk -a NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS nvme0n1 259:0 0 465,8G 0 disk |-nvme0n1p1 259:1 0 256M 0 part /boot-nvme0n1p2 259:2 0 465,5G 0 part / root@cerbere:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS nvme0n1 259:0 0 465,8G 0 disk |-nvme0n1p1 259:1 0 256M 0 part /boot-nvme0n1p2 259:2 0 465,5G 0 part /
    
    If you want I can forward to you lsblk -a -O output.
    
    Thanks a lot for your help.
    
    Sincerely,
    
    Fred.
    1. James A. Chambers
      November 9, 2022 at 5:16 pm
      
      Hey Frederic,
      
      USB appears to be working fine (from the logs) but I’m guessing that’s with USB 2.0. It’s definitely some sort of driver / kernel driver issue it looks like to me. We can see the adapter just fine (and both Ethernet controllers) in your lsusb output as ASIX Electronics Corp. AX88179 Gigabit Ethernet
      
      What driver is this supposed to be using? Does it exist in this kernel? If you look in lsmod in the old kernel where it’s working what modules is it using? Can you modprobe those modules and load the Ethernet controller? It’s weird you are seeing absolutely nothing in dmesg for sure.
      
      I’m actually using kernel 6.0.x in my upcoming build that is building in the background right now. If this is some weird kernel bug that might fix it. I feel like we need to figure out which modules it’s using and whether those exist in this kernel though as a first step!
      
      EDIT: I re-read your post and I think it may be worth trying with my upcoming build here when it finishes. V1.3 has the following changes:
      
      Assign permanent randomly generated MAC address at first startup via netplan to prevent MAC changing every reboot
      
      Upgrade to ODROID Linux kernel 6.0 branch
      
      Add packages: usbutils ethtool ufw macchanger man-db locales
      
      Update build dependencies
      
      Because of the way you are describing the Thanos decimation that definitely does sound like some kind of kernel bug. It’s perplexing we aren’t getting any output from it though in anywhere like dmesg. The new build is building right now and should be ready within the next hour or two!
      
      EDIT #2: V1.3 is out! It fixes all the issues I talked about earlier and I’m very curious if the 6.0.x kernel branch will have any impact on this USB bug. Hopefully you’ll get a chance to give 1.3 a try here!
      1. Frederic
        November 10, 2022 at 3:51 am
        
        Hi James,
        
        1) As I have 2 other Odroid M1 into my lab (but only one StarTech in spare) i gonna prepare one with your new image and Startech dual GE. like that we will be able to switch between conf easily.
        2) When Startech was connected to USB3 it was not detected at all, all the capture (lsmod, lsusb, etc. were done when StarTech was plugged into USB2).
        3) The module is included into the kernel: ax88179_178a and it is included and stable for years into ubuntu I am using them since 18.04 with NUC and x86 refurbished PC.
        
        My next comment will include tests from your newest image.
        
        Fred.
        
        Frederic
        November 10, 2022 at 5:31 am
        
        Hi James,
        
        Before to run it with the new image, I’ve prefered to run it first on the Official Odroid image (20.04):
        my interface are eth0, enx000acd418881, enx000acd418882
        
        as you WON’T see it: because ethtool -P change MAC Addresse to Physical (the first time you run the command, and the capture was done the second time) only eth0 got a MAC that was different from its Physical address.
        As you WILL see it : USB3 is WORKING PERFECTLY USB Card and Startech.com dual port are connected to USB3 ports @ 5000M
        
        root@server:~# lsusb -t /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 06.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 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=ax88179_178a, 5000M |__ Port 2: Dev 4, If 0, Class=Vendor Specific Class, Driver=ax88179_178a, 5000M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 1: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
        
        Newt some commands and their outputs:
        uname -a ifconfig -a ethtool -P eth0 ethtool -P enx000acd418881 ethtool -P enx000acd418882 lsblk -a lsusb lsusb -v lsusb -t lsmod
        
        ---------- uname -a -----------------
        Linux server 4.19.219-odroid-arm64 #1 SMP Tue, 18 Oct 2022 04:13:09 +0000 aarch64 aarch64 aarch64 GNU/Linux
        
        ---------- ifconfig -a -----------------
        enx000acd418881: flags=4163 mtu 1500 inet6 fe80::20a:cdff:fe41:8881 prefixlen 64 scopeid 0x20 ether 00:0a:cd:41:88:81 txqueuelen 1000 (Ethernet) RX packets 153 bytes 44523 (44.5 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 91 bytes 26769 (26.7 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
        
        enx000acd418882: flags=4163 mtu 1500
        inet6 fe80::20a:cdff:fe41:8882 prefixlen 64 scopeid 0x20
        ether 00:0a:cd:41:88:82 txqueuelen 1000 (Ethernet)
        RX packets 153 bytes 44523 (44.5 KB)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 91 bytes 26769 (26.7 KB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
        
        eth0: flags=4163 mtu 1500
        inet 192.168.0.51 netmask 255.255.255.0 broadcast 192.168.0.255
        inet6 2a01:e0a:ec:aa20:21e:6ff:fe51:165f prefixlen 64 scopeid 0x0
        inet6 fe80::21e:6ff:fe51:165f prefixlen 64 scopeid 0x20
        ether 00:1e:06:51:16:5f txqueuelen 1000 (Ethernet)
        RX packets 15239 bytes 8543652 (8.5 MB)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 10140 bytes 1902790 (1.9 MB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
        device interrupt 44
        
        lo: flags=73 mtu 65536
        inet 127.0.0.1 netmask 255.0.0.0
        inet6 ::1 prefixlen 128 scopeid 0x10
        loop txqueuelen 1000 (Local Loopback)
        RX packets 80 bytes 5920 (5.9 KB)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 80 bytes 5920 (5.9 KB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
        
        ---------- ethtool -P eth0 -----------------
        Permanent address: 00:1e:06:51:16:5f
        
        ---------- ethtool -P enx000acd418881 -----------------
        Permanent address: 00:0a:cd:41:88:81
        
        ---------- ethtool -P enx000acd418882 -----------------
        Permanent address: 00:0a:cd:41:88:82
        
        ---------- lsblk -a -----------------
        NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 1 28.7G 0 disk ├─sda1 8:1 1 256M 0 part /boot └─sda2 8:2 1 28.4G 0 part / mtdblock0 31:0 0 128K 0 disk mtdblock1 31:1 0 2M 0 disk mtdblock2 31:2 0 1M 0 disk mtdblock3 31:3 0 12M 0 disk nvme0n1 259:0 0 465.8G 0 disk
        
        ---------- lsusb -t -----------------
        /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 06.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 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=ax88179_178a, 5000M |__ Port 2: Dev 4, If 0, Class=Vendor Specific Class, Driver=ax88179_178a, 5000M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M |__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 1: Dev 2, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
        
        ---------- lsmod -----------------
        Module Size Used by aes_ce_blk 28672 0 crypto_simd 16384 1 aes_ce_blk cryptd 20480 1 crypto_simd crc32_ce 16384 0 crct10dif_ce 16384 0 ghash_ce 20480 0 uio_pdrv_genirq 16384 0 uio 20480 1 uio_pdrv_genirq sch_fq_codel 20480 4 ip_tables 28672 0 x_tables 28672 1 ip_tables ipv6 421888 24 autofs4 36864 0 hid_generic 16384 0 spidev 20480 0 sd_mod 36864 3 usbhid 32768 0 ahci_platform 16384 0 libahci_platform 20480 1 ahci_platform libahci 32768 2 libahci_platform,ahci_platform libata 188416 3 libahci,libahci_platform,ahci_platform ax88179_178a 24576 0
        
        --------------------------
        
        Next publication will certainly get output from 22.04.1 (v1.3)
        
        James A. Chambers
        November 10, 2022 at 8:08 am
        
        Hey Frederic,
        
        There honestly isn’t anything I can do if it doesn’t work with the current kernel to be perfectly honest with you. This project doesn’t rebuild or modify the kernel (nor would I ever undertake such an endeavor as one man with zero resources). Hopefully they’ve fixed it already but this is not something within my control to fix if they haven’t.
        
        This is as low-level of a hardware problem as it gets. It literally just cuts off when you plug it into a USB 3.0 hardware port. We’d have to go much, much lower than lsusb to see anything wrong.
        
        You can actually upgrade your stock image to my new image yourself. All you need to do to turn the stock image into mine is change /etc/apt/sources.list to jammy and then install the newer kernel with:
        
        sudo apt install linux-image-6.0.0-odroid-arm64
        
        That is all my image is. It just has that package installed and is otherwise the stock image. I suspect if you install linux-image-5.19.0-odroid or linux-image-5.18.0-odroid you would get the same result. You could actually try this if you want. You just upgrade to jammy first by editing /etc/apt/sources.list and then reboot. After that install any one of the packages available:
        
        odroid@odroidm1:~$ sudo apt search "odroid-arm64" Sorting... Done Full Text Search... Done
        
        linux-image-5.15.0-odroid-arm64/stable 5.15.74-202211101131~jammy arm64
        Linux 5.15 for 64-bit ARMv8 machines
        
        linux-image-5.16.0-odroid-arm64/stable 5.16.16-202204242219~jammy arm64
        Linux 5.16 for 64-bit ARMv8 machines
        
        linux-image-5.17.0-odroid-arm64/stable 5.17.1-202204241200~jammy arm64
        Linux 5.17 for 64-bit ARMv8 machines
        
        linux-image-5.18.0-odroid-arm64/stable,now 5.18.0-202205181718~jammy arm64 [installed,automatic]
        Linux 5.18 for 64-bit ARMv8 machines
        
        linux-image-5.19.0-odroid-arm64/stable 5.19.17-202211021456~jammy arm64
        Linux 5.19 for 64-bit ARMv8 machines
        
        linux-image-6.0.0-odroid-arm64/stable,now 6.0.2-202210171716~jammy arm64 [installed]
        Linux 6.0 for 64-bit ARMv8 machines
        
        The new kernel doesn’t seem to work with this device for some reason (and we can’t even find an error message to tell us why, we don’t even know where to begin). If you’d like you could actually try all of those available kernel versions by installing them through apt (may need to remove the newer packages to get it to switch). You could try going as close to the old kernel as they have available which would be linux-image-5.15.0-odroid-arm64.
        
        Basically the people that would need to look at this are the ODROID kernel team. To investigate an issue with zero error messages that is this low-level is going to require tools I don’t have available to me for sure. Presumably when they release the newer kernel branches officially this problem will still exist (unless they’re aware of it and fix it before release). That’s all you are using with this kernel basically is their newer kernel that hasn’t been officially packaged as 22.04 yet.
        
        This is presumably a kernel driver bug. It’s obviously not a hardware issue as the device works on the older kernels so your testing has ruled that out (although it’s possible there’s firmware updates available for the adapter that could help potentially). If this is the case then the ODROID 6.0.x kernel branch needs a patch/fix. I suppose it’s possible it could be a problem with the device tree / dtb as well but these are also generally built with the kernel (but are definitely easier to work with than the entire kernel source tree). This device may have to wait for official support/fixes (worst case scenario)!
        
        I would definitely keep looking for some kind of output related to this. Any type of error message telling us a place to start. It might even take turning on the kernel debugging flags or something like that to see the issue!
        
        I just want to make it clear though that this isn’t a custom kernel and is only using the linux-image-6.0.0-odroid-arm64 package and changing the apt sources to jammy and running apt dist-upgrade basically. You’ve definitely clearly demonstrated this is an issue for sure but from my perspective it’s really puzzling as you would get this same behavior installing the linux-image-6.0.0-odroid-arm64 package yourself if you upgraded your 20.04 install to jammy and installed that package. Something seems to have somehow broken this in the new kernels in a way that doesn’t make a lot of sense (you wouldn’t expect them to mess with a formerly working driver in the old kernel very much).
        
        I almost wonder if this should be reported to the ODROID kernel team. Even though the kernel isn’t released yet for the M1 officially I’d imagine they would still want to hear this is happening (and maybe they even have a fix for it potentially). Hopefully that helps!
        
        Frédéric
        November 10, 2022 at 1:28 pm
        
        Hi James,
        
        Thanks a lot for your support, I understand this is not the main goal this place here, and you were the only guy that has spent time to find a fix or the main root cause.
        
        I think that I’ve understood what happens, let me first to tell you that the 3 images are working the same way:
        
        Upper USB3 is working perfectly but bottom one doesn’t
        
        this PM I’ve decided to run minimal hardware config test:
        – nvme SSD
        – internal ethernet
        – no other external extension
        
        and a floating usb card that I will connect / disconnect usb port by usb port. bad news: 2 ou of 2 news Odroid M1 (received 2 days ago) got the same USB3 that is not working (bottom USB3)
        
        Inserted into Bottom USB-3
        
        root@odroidm1:~# lsblk -t && lsusb -t NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME nvme0n1 0 512 0 512 512 0 mq-deadline 256 128 0B ├─nvme0n1p1 0 512 0 512 512 0 mq-deadline 256 128 0B └─nvme0n1p2 0 512 0 512 512 0 mq-deadline 256 128 0B
        
        /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M root@odroidm1:~#
        
        Inserted into Top USB-3
        root@odroidm1:~# lsblk -t && lsusb -t NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME sda 0 512 0 512 512 1 mq-deadline 2 128 0B └─sda1 0 512 0 512 512 1 mq-deadline 2 128 0B nvme0n1 0 512 0 512 512 0 mq-deadline 256 128 0B ├─nvme0n1p1 0 512 0 512 512 0 mq-deadline 256 128 0B └─nvme0n1p2 0 512 0 512 512 0 mq-deadline 256 128 0B
        
        /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M root@odroidm1:~#
        
        Inserted into Top USB-2
        
        oot@odroidm1:~# lsblk -t && lsusb -t NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME sda 0 512 0 512 512 1 mq-deadline 2 128 0B └─sda1 0 512 0 512 512 1 mq-deadline 2 128 0B nvme0n1 0 512 0 512 512 0 mq-deadline 256 128 0B ├─nvme0n1p1 0 512 0 512 512 0 mq-deadline 256 128 0B └─nvme0n1p2 0 512 0 512 512 0 mq-deadline 256 128 0B
        
        /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M root@odroidm1:~#
        
        Inserted into BOTTOM USB-2
        
        root@odroidm1:~# lsblk -t && lsusb -t NAME ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED RQ-SIZE RA WSAME sda 0 512 0 512 512 1 mq-deadline 2 128 0B └─sda1 0 512 0 512 512 1 mq-deadline 2 128 0B nvme0n1 0 512 0 512 512 0 mq-deadline 256 128 0B ├─nvme0n1p1 0 512 0 512 512 0 mq-deadline 256 128 0B └─nvme0n1p2 0 512 0 512 512 0 mq-deadline 256 128 0B
        
        /: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
        /: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
        /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
        /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
        /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
        |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 480M
        /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
        /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M
        /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M
        root@odroidm1:~#
        
        the result is exactly the same into the second Odroid M1.
        
        So, I gonna to check the third one (I’ve ordered 3 Odroid M1 for infrastructure needs) and then will send an email to Odroid support. this not normal that a serie got a dead USB.
        
        Thanks a lot,
        
        Fred.
        
        PS: did you have to deal with Odroid support?
        
        James A. Chambers
        November 10, 2022 at 3:05 pm
        
        Hey Frederic,
        
        Excellent work, I’m so relieved you were able to narrow the cause of this down. It makes perfect sense. I kept mentioning that it is behaving like a hardware issue as the Thanos-level decimation is pretty hard to explain (especially without any output in the kernel, that part kept sticking for me as well as I *always* can find something in there when it’s kernel/driver related). Definitely one of the the toughest issues I’ve seen on the site to troubleshoot in a while!
        
        Thanks for helping me improve the image as well! I was able to bring the server image’s networking in line with the desktop image and fix that MAC issue once and for all. It’s definitely a hacky fix but it’s not clear to me that there is a “real” MAC address for these ODROID boards and that it’s probably always doing some kind of trick like this to store it somewhere (although probably fancier than just in the netplan file like this is using for now). We also got a more appropriate level of base packages such as usbutils and the other ones you suggested.
        
        I haven’t worked with ODROID’s support yet but I’d love to hear about your experience if you get a chance to share it as I’m fairly new to covering ODROID and am always interested in hearing what the experience people have is directly from them. Thanks and let me know if there’s other things you find in the image I should improve / fix / add, take care!
        
        Frédéric
        November 25, 2022 at 11:58 am
        
        Hi James,
        
        I did not forget my promess to notice your blog about my trouble with my 2 M1s.
        Incredible the guys from UK distributor require to get some CRM training.
        They spend 100 time more energy to try to find an argument to put the fault on me rather than to find a way to fix the issue.
        
        The 2 boards are travelling to UK currently, I will inform you as soon as they will do (or not) their RMA job!
        
        but from my 1st experience with them: Their CRM room of improvement is amazing!
        
        James A. Chambers
        November 25, 2022 at 1:33 pm
        
        Hey Frédéric,
        
        Welcome back! That does indeed sound like there’s room for improvement there for sure. I’ve definitely dealt with engineers in my career that way as well so I definitely understand what you mean.
        
        Definitely let us know it turns out, thanks for the update!
        
        Frédéric
        December 16, 2022 at 9:33 am
        
        Hi James,
        
        just a notification here to tell that RMA is still ongoing, as since my 2 x M1 are back to factory, it seems that we are not on the same side of event horizon.
        
        James A. Chambers
        December 16, 2022 at 9:54 am
        
        Hey Frédéric,
        
        Wow, I can’t believe that is still going on! That’s definitely disappointing.
        
        It may be that they are sending it to their engineers to investigate but if I were them I still would have just shipped you out brand new replacements right away and investigated it later. Maybe they’re concerned that all of their boards are going to have this issue though. Maybe it’s something that would take a hardware revision to solve on the boards which is making them hesitate to send you replacements.
        
        The two you have sent them are the only two you had unless I’m misremembering. I’m suspecting all M1’s might do this though with that specific hardware you used (and perhaps ODROID knows it or has figured it out since then). The explanation for this might be some sort of hardware or design issue (that couldn’t be fixed by a firmware update and may require a board revision or redesign of some part of it) which is why they are dragging their feet.
        
        I suppose it’s also possible they haven’t even looked at them yet and are just really slow and have a terrible, bottlenecked RMA process. I did some Google searches though of things like ODROID RMA issues and some variations of those keywords to see if there was a huge amount of people out there saying their RMA process was incredibly slow. I actually didn’t find very many people complaining about the RMA process. If I searched for Raspberry Pi RMA complaints I would have found 1000x more so I’m giving them the benefit of the doubt here that they probably are actually investigating your boards (and they are not liking what they’re finding would be my guess as it will probably need some sort of board revision / hardware fix).
        
        I’m very curious if it will turn out to be they’re investigating or if they haven’t even looked at it. Keep us posted if you wouldn’t mind and thanks!
Sachin
October 27, 2022 at 12:48 pm

Hi! Balena Etcher complained that the image is not bootable when trying to write the tar.xz. When I wrote it regardless, the system was not bootable. Upon extracting the tar.xz to img.xz and then writing it, everything was fine and the system booted but the partition did not resize automatically. I had to manually resize / by using Parted and resize2fs.

The Mac address changes on every boot. Can that be fixed so that it does not change?
1. James A. Chambers
  October 27, 2022 at 1:15 pm
  
  Hey Sachin,
  
  Thanks for leaving your experience! You’re right that it needs to be extracted first. I will update the documentation and this article to make this more clear as that was something we figured out / fixed a week or two back at most. I’ll definitely investigate the automatic resize here so thanks for letting me know something didn’t work quite right with it for you.
  
  The MAC address changing is an interesting observation. I believe this is actually a netplan problem. Can you try editing your netplan configuration with:
  
  sudo nano /etc/netplan/50-cloud-init.yml
  
  We’re going to add a macaddress line in like this:
  
  network: ethernets: eth0: dhcp4: true macaddress: 52:54:00:6b:3c:59 optional: true version: 2 renderer: NetworkManager
  
  Be very careful with the spacing (and don’t try to use tabs) as if it isn’t the exact right amount of spaces the file will break. Once you’ve done that do:
  
  sudo netplan --debug generate sudo netplan --debug apply
  
  The moment I did the second command my connection dropped and sure enough I could see a new connection in my router’s connection manager:
  
  IP Address 192.168.51.92 MAC Address 52:54:00:6b:3c:59
  
  There’s our fake MAC address! It took effect basically immediately and gave me a new IP address (since it thought it was a different device now). This should take care of it for you and you can set it to whatever you would like. Hopefully that helps!
  1. Sachin
    October 27, 2022 at 4:09 pm
    
    Thanks. MacChanger will also do the same thing (apt install macchanger)although only temporarily. However, I am curious as to why the odroid-M1 gives a new Mac address every time it is rebooted. My guess is that either there is a configuration in boot.ini which is causing this or petitboot is somehow causing it (though I don’t see how).
    1. James A. Chambers
      October 27, 2022 at 4:26 pm
      
      Hey Sachin,
      
      It’s the stock ODROID image basically just with updates installed so I’d be curious if the regular stock ODROID 20.04 Ubuntu server image does the same thing (which is basically what this is only with updates on top). The source code for the project downloads the official ODROID image and just runs apt updates in it (and installing a desktop flavor basically).
      
      Basically nothing really has been changed, added, designed, or anything else by me that would explain it unless simply updating the image causes this to happen for some reason as that is all these are (and can be built yourself to verify). It uses a chroot jail to log into the original image and run apt update and apt install ubuntu-desktop (if the desktop flavors are being used).
      
      Maybe there’s a questionable modification in the old 4.x kernel that is some sort of hack to accomplish this that isn’t present in the newer 5.19.x kernel branch? I’ve seen other boards have kernel hacks to save these in a file on the root partition before as just a text file. It’s not uncommon for ARM boards to not store a MAC address anywhere persistent like NVRAM / a ROM chip (or anything not on your root storage basically) and to use tricks like this. When this is the case reimaging it will cause the MAC address to change (very common).
      
      I think macchanger is a fine solution as well. That should take care of any MAC address shenanigans. Hopefully that helps!
Nikodemus
October 8, 2022 at 1:18 pm

Hi James,
Could you make a small how-to get your image to a bootable device (i.e. USB-Stick). If I try to create one using Etcher, it says “Not a bootable image….”.
thx
Nik
1. James A. Chambers
  October 8, 2022 at 2:41 pm
  
  Hey Nikodemus,
  
  Wow, that is an interesting idea, I have not tried it before but I definitely will give that a try (to make sure there aren’t additional unexpected issues doing this)!
  
  So I’ve personally wrote the images with the built-in Gnome disk image writer tool available in Ubuntu desktop but dd’ing the image right onto the disk from the CLI would work as well.
  
  If you are on Windows I would recommend using Win32DiskImager.
  
  I used the Ubuntu Gnome disk image writer to write it to my 16GB flash drive to test this. I removed my eMMC I usually move completely from the board and it actually booted right into it so you should be able to do this no problem.
  
  I think the issue is Etcher just doesn’t recognize this as a bootable media. Using Win32DiskImager or the Linux disk utilities should do the trick here!
  1. Ken Fox
    October 17, 2022 at 12:38 pm
    
    Hi James,
    I’ve also run into the problem that the image is not bootable. On my ubuntu desktop, I’ve tried dd, cat > /dev/sda, as well as gnome-disk-utility 42.0, all with the same results. I’d really appreciate some guidance on troubleshooting.
    1. James A. Chambers
      October 17, 2022 at 12:46 pm
      
      Hey Ken,
      
      Welcome! Can you tell me what is happening when you try to boot it? What are you seeing or what errors are you getting? Are you seeing the image in Petitboot when you try to start it up? Which specific image/images are you trying (in case I have a broken upload and need to double check one)?
      
      There’s a couple more things that could be going on. I would try completely deleting all partitions off whatever it is that you are imaging here first with:
      
      sudo fdisk /dev/sda p d
      
      Next if you did a:
      
      cat > /dev/sda
      
      After doing this type of a clone you first need to unplug the device and plug it back in again. Next do a forced fsck like this:
      
      sudo e2fsck -yfv /dev/sda1
      
      I’d imagine that it’s booting you into the console (instead of the image). Is that right? If so then the above step will prevent you from having to do it on the command line before first startup. The first startup will sit on a black screen with about 4 lines of text for 2-3 minutes or so which is normal while it resizes your root partition to match the disk so make sure you aren’t giving up before it finishes resizing the disks.
      
      You can actually run that same command on the command line though if you are in the place I think it’s taking you to fix it. I would just recommend doing it right after imaging though. I’ve done it from the bootloader before though and it does let you run fsck and then it would probably boot. Perhaps I need to add /forcefsck to the image which would make it do this automatically on the first boot.
      
      If this works for you I can definitely add it to the article / documentation to make sure to perform a fsck with the above command if it takes you to a bootloader console (or patch in a fix even potentially depending on what you find). Let’s see if that gets it going here!
      1. Ken Fox
        October 18, 2022 at 10:22 am
        
        Thanks for your help James. So I followed your steps verbatim using a 32G microSD card.
        Deleted partitions on /dev/sda using fdisk (there were none though).
        
        cat legendary-ubuntu-22.04.1-server-odroidm1-v1.1.img > /dev/sda
        
        Then ran e2fsck:
        
        sudo e2fsck -yfv /dev/sda1 e2fsck 1.46.5 (30-Dec-2021) e2fsck: No such file or directory while trying to open /dev/sda1 Possibly non-existent device?
        
        I’m going to try a different one of your images and see if I get different results and let you know. Thanks again!
        
        James A. Chambers
        October 18, 2022 at 10:29 am
        
        Hey Ken,
        
        Did you unplug the SD card and plug it back in again before trying to run fsck? It won’t find any partitions otherwise and there should definitely be at least one partition available on there for sure. That helps to know it’s the server image.
        
        32G SD card sounds pretty standard for sure. I wouldn’t expect any problems there so that is good!
        
        Ken Fox
        October 18, 2022 at 10:42 am
        
        Same result using the Ubuntu Desktop image unfortunately.
        
        James A. Chambers
        October 18, 2022 at 10:56 am
        
        Hey Ken,
        
        I’m not sure as I haven’t been able to reproduce this. Do you have any other storage devices you could try with like a USB drive or another SD card?
        
        Ken Fox
        October 18, 2022 at 11:48 am
        
        Sure. In an effort to rule out hardware, I’ve been simply trying to mount the images to my dev machine (running Ubuntu desktop), which also fail though. Shouldn’t I be able to mount the image file?
        
        James A. Chambers
        October 18, 2022 at 12:02 pm
        
        Hey Ken,
        
        Great question! So you can absolutely mount them. There’s a few ways to do it. The easiest way in Ubuntu is just to right click on the .img file and click “Open with other application”. Choose “Disk Image Mounter”.
        
        You should immediately see “BOOT” and “ROOT” pop up. I think you are on the right track ruling things out. That’s exactly what I’m trying to do here as well and I really like the idea of mounting them inside the OS!
        
        You may want to update your M1 firmware / Petitboot loader as well. That’s the only other thing I can think of!
        
        Ken Fox
        October 18, 2022 at 5:23 pm
        
        Yeah- none of the images will mount. The ubuntu 20.4 image from odroid mounts fine.
        
        James A. Chambers
        October 18, 2022 at 6:26 pm
        
        Hey Ken,
        
        I tried downloading it off of GitHub and it wouldn’t mount for me either. Very strange. Great thinking on testing mounting it within the OS as this did eventually help me find a way to reproduce what you are seeing.
        
        Let me try building it again fresh here as when I tried mounting my own copy it worked. Maybe it was a bad upload to GitHub somehow? Let’s try with V1.2 when it comes up here and see if we can get it going!
        
        Ken Fox
        October 18, 2022 at 7:31 pm
        
        FWIW I tried building it in vscode and ran into a number of permission errors and “file not found” issues. Most were around accessing the /mnt path. I didn’t dig to deep to see what was going on. Assumed my PC needs additional configuration/software to build properly.
        
        James A. Chambers
        October 18, 2022 at 7:36 pm
        
        Hey Ken,
        
        Don’t sweat it at all. I’m building them completely fresh. Thank you for sticking with me long enough for me to find the problem as I’m certain this was the issue in the other cases but people gave up before we figured out exactly where the issue was.
        
        So far it has built Server, Desktop and Mate-Desktop and it is working on Xubuntu now. It’s very slow to build them downloading the packages clean but since there was a problem I wanted a completely clean build. These should probably come up in an hour or two at the most!
        
        EDIT: Oh wow, I am a moron. You won’t believe what the problem is. The problem is the downloads are actually .tar.xz files and not .img.xz files. That means all you need to do is:
        
        tar -xf legendary-ubuntu-22.04.1-server-odroidm1-v1.1.img.xz
        
        THAT will give you a working image file that can be mounted (you could do this with 1.1 or whatever version you have downloaded already). I’m reuploading a fixed version that uses the correct file extensions. Sorry about that!
        
        Ken Fox
        October 19, 2022 at 11:40 am
        
        Awesome thanks James! Will check it out.
        
        James A. Chambers
        October 19, 2022 at 11:50 am
        
        Hey Ken,
        
        Excellent! I’m immensely grateful to you as I knew something was up with the images but I needed someone to humor me enough through the process of elimination to figure out exactly what the problem was. It’s never fun to go through that process for anyone though especially when it takes more than 2-3 replies. The process of elimination is just the best process to firmly figure out what is going on but it takes more time / effort than most people have to spare.
        
        I missed this several times because I was looking in the wrong places. The reason this happened is that I used the exact same code I used for my Orange Pi i96 image. If you’ll notice in the releases section there they are distributed as .tar.xz files. My mistake I made was I used that compression code but went with the same naming scheme ODROID uses but these are indeed not the same format.
        
        Further, it turns out that it will let us decompress it (as a .img.xz instead of a .tar.xz) without complaining! It will just be completely broken/invalid. That was another reason this was harder to track down than it should have been for a wrong file extension as the applications weren’t telling us “hey this is the wrong type of file”. They were just doing it and giving us garbage.
        
        Definitely let me know how it goes!
        
        Ken Fox
        October 19, 2022 at 12:37 pm
        
        Worked great- thanks again.
        
        James A. Chambers
        October 19, 2022 at 1:39 pm
        
        No problem, enjoy and take care!
Dima
October 5, 2022 at 3:06 pm

Is it possible to run these images with VU8m screen ?
1. James A. Chambers
  October 5, 2022 at 3:23 pm
  
  Hey Dima,
  
  I checked the overlays folder in /boot/dtbs/5.19.0-odroid-arm64/rockchip/overlays/odroidm1 and I don’t see the display_vu8m.dtbo in the new kernel yet.
  
  There is however one in /boot/dtbs/4.19.219-odroid-arm64/rockchip/overlays/odroidm1/display_vu8m.dtbo.
  
  I do not know if these will be compatible enough but if you have the screen and are trying to enable the overlay it’s worth a try to copy that overlay to the overlays folder for the new kernel in /boot/dtbs/5.19.0-odroid-arm64/rockchip/overlays/odroidm1.
  
  If it’s completely incompatible you’ll see some errors in dmesg related to it most likely here but this is an easy thing to try if you’re already all set up. It’s worth a try to see if this will enable the module (after adding the overlay in config.ini).
  
  If this works for you (or you’re able to get it working) I’d be happy to integrate these fixes into the image directly!