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
ODROID M1 4GB
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.
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.
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 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.
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!
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!
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
1 year ago
Hi james,
Is there a way to install this image to the SSD from a USB stick?
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!
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
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
2 years ago
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?
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
2 years ago
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.
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:
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!
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
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.
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
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) 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.
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
---------- 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
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!
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)
/: 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:~#
/: 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:~#
/: 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:~#
/: 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.
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!
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!
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!
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.
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
2 years ago
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?
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:
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:
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!
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).
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
2 years ago
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
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.
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!
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.
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!
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).
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!
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?
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!
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!
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.
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!
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.
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!
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!
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
Hi james,
Is there a way to install this image to the SSD from a USB stick?
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!
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
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!
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?
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!
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 localesand reconfigure kbd, locales according to my conf.
and add rclone using:
sudo -v ; curl https://rclone.org/install.sh | sudo bashrather than standard package as v1.60 vs v1.53 ==> 2-3 years of improvement.
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 -aCan 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!
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 -aLinux 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:~# lsusbBus 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 -vBus 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:~# lsmodModule 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 /-nvme0n1p2 259:2 0 465,5G 0 part /nvme0n1 259:0 0 465,8G 0 disk
|-nvme0n1p1 259:1 0 256M 0 part /boot
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.
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 EthernetWhat 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:
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!
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.
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 -aifconfig -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 1500inet6 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 MOUNTPOINTsda 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 byaes_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)
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-arm64That 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!
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 -tNAME 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 -tNAME 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 -tNAME 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?
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!
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!
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!
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.
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!
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?
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.ymlWe’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 generatesudo 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.92MAC 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!
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).
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!
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
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!
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.
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/sdap
d
Next if you did a:
cat > /dev/sdaAfter 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/sda1I’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!
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/sdaThen ran e2fsck:
sudo e2fsck -yfv /dev/sda1e2fsck 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!
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!
Same result using the Ubuntu Desktop image unfortunately.
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?
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?
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!
Yeah- none of the images will mount. The ubuntu 20.4 image from odroid mounts fine.
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!
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.
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.xzTHAT 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!
Awesome thanks James! Will check it out.
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!
Worked great- thanks again.
No problem, enjoy and take care!
Is it possible to run these images with VU8m screen ?
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!