407

Could be, but I suspect the language packs for the package manager are standalone and optional, so they'll need to be manually reinstalled. I'll take a look and see if it's something that can be automated.

1 Like
408

I just did a PR (https://github.com/openwrt/asu/pull/1155) for the luci-i18n-opkg- -> luci-i18n-package-manager- conversion. Have you run into any other language packages with this issue?

1 Like
409

I don’t think so, if I come across it I’ll definitely let you know.
P.S.
As I wrote, there is a problem with AdBlock-Fast.
Packages are not installed
Missing recommended package: 'gawk'
Missing recommended package: 'grep'
Missing recommended package: 'sed'
Missing recommended package: 'coreutils-sort'

1 Like
410

Those are not required package dependencies, they are either installed or not installed at the end user's (your) whim, if you want them or not. Nothing to do with owut or ASU. If you install them, then owut will see that and re-install them, otherwise it doesn't know anything about them.

1 Like
411

But without them it doesn't start and doesn't work.
You know better of course, I'll ask the author of the plugin.
Thank you.

412

Hi,
By mistake when setting up my NanoPi R5C for the first time, I installed the Immortal fork of OpenWrt instead of the main one.

When I noticed, I edited "/etc/config/attendedsysupgrade" to point it to the official sysupgrade server.

Problem is that now when trying to "upgrade" it won't let me, as it actually looks as if Immortal is ahead in many package versions and there is also a large number of missing packages:

[...]
39 packages missing in target version, cannot upgrade
28 packages were downgraded
78 packages are out-of-date

Is there any way of easily moving from Immortal to official without having to just reinstall and configure everything from scratch?

Thanks

413

That one is the show stopper, if you have packages from Immortal that you are actually using, and they don't exist in OpenWrt, then you're sort of out of luck.

If you want to give it a try, make a file containing the missing packages, then --remove them from the build request (assumes owut 2025.01.06):

owut check | awk '/missing to-version/ {print $1}' > missing-packages
owut check --remove "$(cat missing-packages)"

If that last check seems ok, just do an upgrade --remove..., maybe with a --force if it's needed to overcome any of the less serious mismatches.

414

I will try that when I get a chance, thanks!!

Out of curiosity, how legitimate is this Immortal fork? As I said, I installed it somehow by accident, but it looks pretty much like OpenWRT with some more stuff.

415

As far as I know, it's completely legit. It think they started off as a fork that provided better Chinese language support, but then started adding their own packages and support for some weird devices.

1 Like
416

That is not the only show-stopper, configurations aren't expected to be compatible between OpenWrt and immortalwrt either (they might happen to be, but as immortalwrt often flirts with various vendors SDKs, there can be quite material differences in the configuration semantics and syntax).

This is not a case for owut, but for a clean sysupgrade without retaining settings.

417

Where's your sense of adventure? I want to see if it crashes and burns, or actually gets somewhere... :grin:

A NanoPi should be unbrickable, so it's not going to do anything but waste time if it fails, so if it were me, I'd give it a go and see if I learned anything.

418

What an amazing tool! Thank you and everybody who contributed to this. Tested upgrading on a Fritzbox 4040 and a couple of arm boards, other than missing ssl packages (my mistake) everything went smoothly. The wiki is great and had all the info I was looking for. I'm impressed!

Not only is this a great for upgrades but its never been easier to setup a router, install all packages, configure it, make sure it's up to date with owut and save the image/manifest/checksums + backup somewhere. Makes it very easy to recover or setup another router.

1 Like
419

At least coming from qsdk or Mediatek SDK builds, the expected result would be a guaranteed brick (because they have very different ideas for /etc/config/network and -wireless).

420

Tried checking for an updated build for a couple of days hoping this error would go away: ERROR: Checks reveal errors, do not upgrade

Cause by:

1 packages missing in target version, cannot upgrade

The package in question: libuci20130104 2024.11.26~10f7996e-r1 missing to-version

Tried running: root@OpenWrt:~# owut upgrade -r libuci20130104 -a libuci
But that gave me:

WARNING: package 'libuci20130104' has dependents and removal will have no effect on the build
ERROR: Package 'libuci' is not available on this platform
ERROR: Errors collecting package data, terminating.

That is one confusing warning, so stuff depends on it but removing it has no effect on the build? I would guess otherwise...

Anyways, the package name has changed to libuci20250120 and running the following command worked for me: owut upgrade -r libuci20130104 -a libuci20250120

(Alas, ASU server is stuck on validate_manifest. Probably will work later today or tomorrow.)

421

Full version:

That's why I say way up in the OP describing this solution

But I'm not sure how else to phrase it any better in a one-liner. What it means is:

  1. Something in the install depends on the package you removed,
  2. apk sees that dependency, so
  3. apk reinstalls the removed package during the build,
  4. There is ultimately no effect (that is, your -r xxx is a NO-OP).

The above will actually be meaningful in a normal context, where there aren't unfinished pieces in the underlying packaging tools (i.e., the ABI-versioned names that are at issue here). Consider the case where we are removing some other package, say owut upgrade --remove kernel. owut says "uh? ok, whatever" and produces above warning; build says, "nah, the kernel is needed by a bunch of stuff" and adds it in anyhow.

Right, that's why my instructions at the top don't specify "add libuci" because it does not exist in the apk world, the package is only present in its ABI-version-mangled form (if you were in opkg land, 24.10, then adding libuci would have worked fine). It appears to owut that the package simply disappeared, and although another new one with a sort-of-similar name magically appeared, there's no connection between them. You can (as you did) dig around and figure out what the new name is (libuci20250120 or whatever), but since it's going to be installed as a dependency anyway, there's no need.

This whole situation is due to the incomplete state of (or "bug in", if you prefer) the apk-based packaging system, owut should never see the libblahABI names, only libblah, so us humans are working around it by saying "just ignore that libblahABI and carry on". (Note that this trick will only work with dependent packages, not top-level ones, but since all of the ABI-versioned packages fit that profile, we can survive this easily until the fix is in.)

4 Likes
422

I should read the instructions instead of trying to figure something out...

423

Nah, keep doing what you're doing. Every time someone reports a confusing issue like this, it makes me re-examine the situation and I often can improve things. I'm currently fixing up the message you referenced above, and some others related to similar issues...

3 Likes
424

Since we already have something with a name like "owut," maybe they should rename LuCI to OMG (OpenWrt Management GUI). It's great for LOL (Linux online) with ROFL (Routers Open, Free, and Libre). :wink:

4 Likes
425

Hello @efahl. I tried out OWUT for the latest RC. I see in the documentation that configuration is supposed to be kept

which will proceed with the build and install, keeping all configuration.

, so I just wanted to mention an instance where this did not quite work as expected.
I have a x86/64 device that I wanted to upgrade to the RC6 build. I used the following input in CLI:

owut upgrade -S 1024

The device upgrades, my root partition is set to 1024MB; however, the configuration is not kept. Luckily, through experience, I had just automatically saved my configuration file before upgrading and could use that to restore my configuration.

I upgraded another device, an ASUS TUF AX6000, simply using the

owut upgrade

command and in that instance the result was that my configuration was kept. This makes me wonder if whether setting the root partition size does not translate to the configuration being kept.

If there is any more information you want, let me know.

Another question regarding the upgrade parameter is when -S variable is used: is there a reason the end of the range of the root size is arbitrarily set to 1024MB? I know there won't be many instances you would have to use a larger root partition, but why not use all the available space if there is more on a hard drive?

426

For your first question: https://openwrt.org/docs/guide-user/installation/sysupgrade.owut#expanding_root_file_system

Additionally, it also details a way to save the rootfs size in a UCI setting, so you don't have to manually specify it each time you upgrade.

For your second question: https://openwrt.org/docs/guide-user/installation/sysupgrade.owut#faq

1 Like