Aeon - transitional update remains immutable -> kernel source needed

Hi!

I am testing Aeon on a virtual machine to see if it is something for me, or that I should stick to Tumble Weed.

Everything I needs runs fine. Containerbased is really my thing. All my services run on a remote server or in a container.

But, I can´t get the transitional-update working in order to compile a kernel module for my Moxa Serial To USB Converter. When I install the needed kernel source in Distrobox, Zypper installes version 6.10.5-1.1 in Distrobox. Aeon runs 6.9.9.1-1. I want to enforce an update on Aeon with transitional update. It installs the right kernel version

Retrieving: kernel-default-6.10.5-1.1.x86_64 (openSUSE-Tumbleweed-Oss) (422/429), 171,5 MiB    
Retrieving: kernel-default-6.10.5-1.1.x86_64.rpm [...................................................................................done (21,3 MiB/s)]
(424/431) Installing: kernel-default-6.10.5-1.1.x86_64 [.......................................................................................................

But it ends with an error

2024-08-19 20:58:10 Discarding snapshot 3.
Cannot delete snapshot 3 since it is the next to be mounted snapshot.
ERROR: `snapper modify --default 3 2>&1` returned with error code 1.

After a reboot, all the installeds software is gone. It seems that Aeon was still in immutable mode or something.

Am I doing the update correct? And this is the righ way to install a kernel module. And is Aeon designed to install an own kernel module, or is this more for TW and LY distro’s?

Complete output of transitional-update

2024-08-19 20:57:28 Application returned with exit status 0.
2024-08-19 20:57:28 Transaction completed.
Trying to rebuild kdump initrd
2024-08-19 20:57:30 tukit 4.7.0 started
2024-08-19 20:57:30 Options: close 3 
2024-08-19 20:58:10 Discarding snapshot 3.
Cannot delete snapshot 3 since it is the next to be mounted snapshot.
ERROR: `snapper modify --default 3 2>&1` returned with error code 1.

Warning: The following files were changed in the snapshot, but are shadowed by
other mounts and will not be visible to the system:
/.snapshots/3/snapshot/var/lib/systemd/catalog/database
/.snapshots/3/snapshot/var/lib/systemd/rpm/systemd-pre_210_fixed
/.snapshots/3/snapshot/var/lib/systemd/rpm/systemd-i18n_migrated
/.snapshots/3/snapshot/var/lib/flatpak/repo/config
/.snapshots/3/snapshot/var/lib/flatpak/.changed

Please reboot your machine to activate the changes and avoid data loss.

WARNING: This snapshot has been created from a different base (1)
         than the previous default snapshot (2) and does not
         contain the changes from the latter.

@Joris6 Hi Aeon is only supported on bare-metal… what module is needed, is this an out-of tree module, then I would look at creating as a kmp and install as such.

Run transaction-update --interactive dup to see where it’s failing and correct as required.

Thanks. This is not an out-of tree module. Moxa supplies a solution for a driver in Linux . I am even delighted they took the time to make a solution, and even for older kernels and Arm. Even though I have sometimes recompile the module, I am happy that it runs in Linux.

The run of transitional-update --interactive dup gives the same output. But, if I run the transitional-update directly again, it restarts all the update.

I see this message Separate /var detected. Can this be a hint? I checked if there is enough room at /var, that is the case. 8.5GB of 61GB in use.

It could be a virtualization issue. Then I have to wait when Aeon is released, due to the situation I don´t have time/resources to install on my computer. :wink:

@Joris6 The “mxuport.ko” and “mxusbserial.ko” are out of tree kernel modules :wink: You don’t have to be on Aeon to create either, Aeon tracks Tumbleweed, but the issue with Aeon will be signing the modules.

Can you confirm those are the two modules that you need?

@Joris6 so muxport.ko is already in the kernel;

 /sbin/modinfo mxuport 
filename:       /usr/lib/modules/6.10.5-1-default/kernel/drivers/usb/serial/mxuport.ko.zst
license:        GPL
author:         <support@moxa.com>
author:         Andrew Lunn <andrew@lunn.ch>
suserelease:    openSUSE Tumbleweed
srcversion:     A304D1F92CDB388C19F7097
alias:          usb:v110Ap1653d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v110Ap1613d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v110Ap1658d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v110Ap1618d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v110Ap1451d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v110Ap1450d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v110Ap1410d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v110Ap1251d*dc*dsc*dp*ic*isc*ip*in*
alias:          usb:v110Ap1250d*dc*dsc*dp*ic*isc*ip*in*

Perhaps all that is needed is the udev rule…

mxuport from Moxa supports more devices. But we have zero information what device OP has.

How exactly is virtual machine different from bare metal in this case?

@arvidjaar @Joris6 provided a link to the UPort 1200/1400/1600 Series devices.

Thank you all for the support.
It is a Uport1250 that has settings that can be changed via the command setserial. It is not a generic USB to serial converter. Those ones work indeed out of the box with Linux.

I see the MXuport and will dive into it.

Then I have my question open is Aeon is designed for compiling (manual or via installer) or is that a reason to stay with TW or Leap? And the transactional-update issue is there. The distrobox installs versions for a newer kernel than the running one. That could be a virtualization issue.

@Joris6 So check your device product/vendor id match the alias list for the modinfo output. Then it’s likely a udev rule needed.

Well for Aeon, any hardware supported by kernel divers that are plugged in should be used at a host level, applications should then be installed via flatpak/distrobox to access that hardware.

Sounds like Aeon is still not updated… I have it sitting here at 20240819 (6.10.5-1-default kernel) and tonight it will auto update to 20240820.

Sounds like a fresh install is needed, big USB device and it should backup your existing data and re-install, BUT always make a backup

Thanks. It seems that the driver in the kernel is not 100% functional with proper udev. I have the feeling the kernel driver is only tested Let’s try find support for it.

About the update. If I run the transitional update, it should update my Aeon? If I understand the Wiki correctly, this is the exact same update process as the trigger by the 00:00 update or +2 hr operation time. I find it strange that my update is not stored. But that could be a virtualization issue.

My system is a virtual test system, no back-ups needed. :wink:

@Joris6 Yes, transactional-update dup

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.