Thanks for the logs.
It has failed to write rootfs.
Kernel is fine, it booted 6.6 ok...
I wonder if the factory ubifs is getting in the way, normally this is cleaned up by /lib/upgrade/ubnt.sh, but this would only run if you do a normal sysupgrade prior to attempting migration.
May need to integrate this snippet into stage2 scripts
This might be it. The two times I attempted the migration was effectively on a "stock-to-OpenWrt" install. I don't recall doing any sysupgrades between OpenWrt releases on my EdgeRouter X.
I am rolling back a device to factory now to test.
OK, the image that boots after installing factory.tar, is the stripped down image running entirely from the kernel slot. Normally you need to sysupgrade from here to get your full openWRT (from which migration scripts would have worked), however...
Scripts now handle this intermediate "factory.tar" state also 
So you can skip a step and go directly to 24.10.
@tbsky @elbertmai Please test again with updated scripts.
I can confirm your updated script works 
Yes, the script is working fine now!
I migrated my ER-X to 24.10rc2 from 23.05.3 using your scripts. Worked great. Thank you so much for maintaining OpenWrt support of this target!
Minor suggestion: Next time you are editing the wiki instructions, it may help some to insert a chmod +x *.sh to make the scripts executable after they are copied to /tmp/
Thanks for the script
-Edgerouter-X user!
Somewhat noob question - will the layout migration be happening for an attended sysupgrade 23.05 -> 24.10 when officially released? I'd like to minimize downtime and avoid having to plug into a wiped router at a hard to access place to restore packages and configuration.
Nope that wont be possible, not able to integrate the required changes within 23.05 sysupgrade. I am hoping though the migration scripts can be included in a future 23.05 release.
I suppose if you can capture the build outputs from attended sysupgrade, you could use them with the migration scripts:
but by default this is still going to wipe all your settings
I guess someone could create a custom 23.05 image with your pull request, so there's a path from 'official 23.05' -> 'custom 23.05 with update script' -> 24.10?
It adds a step in between, but might be more user-friendly.
I have an older branch for 23.05 which integrates with sysupgrade rather than standalone migration scripts. Its possible to keep your settings this way. No idea if it works with attended upgrades though, but I suppose it might.
If someone wanted to build custom 23.05 images probably better to use this as a base.
Finally made some time to try to update to 24.10, but immediately after running the script, I get an error: Incompatible compat version
I'm running OpenWrt 23.05.5 r24106-10cc5fcd00 / LuCI openwrt-23.05 branch git-24.332.79522-a493155, so not sure why my compat-version should be anything other than 1.1?
You need to use the migration scripts as detailed on the wiki. The compat version was bumped to protect against direct sysupgrades which would brick your device.
If you restore a backup after the migration process, then you may need to manually bump the compat version. But only do this after you are sure your running the new partition layout.
I am using the migration scripts as detailed on the wiki.
For some reason, my /etc/config/system did not contain a line for option compat_version, that's why uci -q get system.@system[0].compat_version did not give any return and why the script failed without much detail.
Manually adding option compat_version '1.1' in /etc/config/system (on 23.05) did the trick, so posting this as reference for anyone else facing the same issue.
oh right, didnt realise that could fail. I will update the script to behave better in this case.
Perhaps it's 'safer' for the script to query the kernel version instead of compat_version? The kernel version is an 'independent' way to verify the release version, while compat_version is dependent on what a users has/hasn't set in /etc/config/system?
This isnt managed by the user though. It should be automatically setup so not sure how it can be missing. Is it set on your device to "2.0" after migration?
Regardless I will just relax the check on compat_version, and assume missing compat_version requires migration, its harmless to run the script again even if already migrated.
On a clean install of 24.10 I do indeed see option compat_version '2.0', so it's part of the config default. After that, a user can remove/change it. In my case, I guess it got removed while restoring a config.
It would go back to old version if you restore a backup. But it shouldn't be empty unless user has removed it?