Rebasing by selecting date brings images from the latest stream

[etvt]

Describe the bug

My suspicion is that when rebasing on a particular date, I get the images from the latest stream and not the stable-daily stream.
This is also confirmed by receiving the latest kernel and some other packages removed/added. Additionally, there is a much higher number of missing layers (41) compared to the usual 3-5 layers.

Steps to reproduce:
ujust rebase-helper -> rebase -> date -> select a date (version) and confirm the rebase.
See output below:

❯ ujust rebase-helper 
Choose your action.
Which Tag would you like to rebase to?
The default selection is stable (weekly builds) and stable-daily (daily builds) are for enthusiasts, and latest is for testers
Warning: This will pin you to a specific version, do not forget to rebase back to a channel to resume receiving updates.
Rebase Target is ghcr.io/ublue-os/aurora-dx:41-20250113.7
Confirm Rebase
Pulling manifest: ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:41-20250113.7
Importing: ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:41-20250113.7 (digest: sha256:09170913ea8e5047fe9d336de32a184a4f430700d28a7ef24e34532d50bc0c4e)
ostree chunk layers already present: 31
ostree chunk layers needed: 41 (2.8 GB)
[0/41] Fetching ostree chunk dffab2dabd27fb0d857 (278.7 MB)... done
[1/41] Fetching ostree chunk 61c4e4278545251142d (116.3 MB)... done
[2/41] Fetching ostree chunk dd5dbd6ccabc39cc2d9 (148.7 MB)... done
[3/41] Fetching ostree chunk 57e4bbe6522363a15ff (153.1 MB)... done
[4/41] Fetching ostree chunk 63506c5eede5d892f68 (59.7 MB)... done
[5/41] Fetching ostree chunk f53da0096f09da1af8e (124.6 kB)... done
[6/41] Fetching ostree chunk e9fd11d23c627cd9f2d (93.4 MB)... done
[7/41] Fetching ostree chunk 71fdce34326a03d0ad1 (87.0 MB)... done
[8/41] Fetching ostree chunk 2d16b81d45e806773d6 (16.1 MB)... done
[9/41] Fetching ostree chunk 2a67e05c63cf8a63717 (7.3 MB)... done
[10/41] Fetching ostree chunk ec96e874ecf2b75c865 (24.9 MB)... done
[11/41] Fetching ostree chunk 291102a13017ad0cd81 (38.7 MB)... done
[12/41] Fetching ostree chunk cce2cddf49cd5677a2c (55.3 MB)... done
[13/41] Fetching ostree chunk 5391bb07993b03690a6 (98.7 MB)... done
[14/41] Fetching ostree chunk 1e97f87f7159c884e98 (103.7 MB)... done
[15/41] Fetching ostree chunk 3c93528c969a44e482e (31.5 MB)... done
[16/41] Fetching ostree chunk 4b062e94fcb027c1b2d (53.0 MB)... done
[17/41] Fetching ostree chunk 31cbd2f2b359e0da3a2 (210.3 MB)... done
[18/41] Fetching ostree chunk a36b031f71be6e2d4e0 (48.1 MB)... done
[19/41] Fetching ostree chunk d523789da031cd7bb60 (45.3 MB)... done
[20/41] Fetching ostree chunk 2899928b83fcbd313b7 (43.7 MB)... done
[21/41] Fetching ostree chunk 667abf5d407ccb723a4 (44.4 MB)... done
[22/41] Fetching ostree chunk efe1045a6636a66b668 (26.5 MB)... done
[23/41] Fetching ostree chunk 470eb08a4aebe75e3a3 (44.3 MB)... done
[24/41] Fetching ostree chunk a2f116f96fb3c18f303 (56.9 MB)... done
[25/41] Fetching ostree chunk e7831421a3f182b1cea (48.2 MB)... done
[26/41] Fetching ostree chunk 1f7d403dd0daff41a18 (50.8 MB)... done
[27/41] Fetching ostree chunk bcbfd2567de95ba9776 (50.3 MB)... done
[28/41] Fetching ostree chunk 0850e737390885f8982 (40.9 MB)... done
[29/41] Fetching ostree chunk a95250f5acd91087c10 (52.8 MB)... done
[30/41] Fetching ostree chunk f59536a19013d9a981f (36.3 MB)... done
[31/41] Fetching ostree chunk d2d61da59c9b0c4564b (86.1 MB)... done
[32/41] Fetching ostree chunk 3f0fcd076064061e991 (53.9 MB)... done
[33/41] Fetching ostree chunk cd4a35366f5b9fa805d (36.9 MB)... done
[34/41] Fetching ostree chunk cb9172c62e49ca891cc (86.9 MB)... done
[35/41] Fetching ostree chunk 060e3cabcd021aeb3e0 (32.7 MB)... done
[36/41] Fetching ostree chunk e88f9570e70b1cb9b15 (28.7 MB)... done
[37/41] Fetching ostree chunk f313e9a6a9d259209ca (43.0 MB)... done
[38/41] Fetching ostree chunk b74d163f1a7d3ec48d8 (23.3 MB)... done
[39/41] Fetching ostree chunk 63ec40e2e34899d7cea (182.6 MB)... done
[40/41] Fetching ostree chunk 2183103eaef8dafc880 (12.2 MB)... done
Staging deployment... done
Upgraded:
  kernel 6.11.11-300.fc41 -> 6.12.8-200.fc41
  kernel-core 6.11.11-300.fc41 -> 6.12.8-200.fc41
  kernel-devel 6.11.11-300.fc41 -> 6.12.8-200.fc41
  kernel-devel-matched 6.11.11-300.fc41 -> 6.12.8-200.fc41
  kernel-modules 6.11.11-300.fc41 -> 6.12.8-200.fc41
  kernel-modules-core 6.11.11-300.fc41 -> 6.12.8-200.fc41
  kernel-modules-extra 6.11.11-300.fc41 -> 6.12.8-200.fc41
Removed:
  kmod-zfs-2.2.7-1.fc41.x86_64
  libnvpair3-2.2.7-1.fc41.x86_64
  libuutil3-2.2.7-1.fc41.x86_64
  libzfs5-2.2.7-1.fc41.x86_64
  libzpool5-2.2.7-1.fc41.x86_64
  pcp-conf-6.3.2-2.fc41.x86_64
  pcp-libs-6.3.2-2.fc41.x86_64
  pv-1.8.14-2.fc41.x86_64
  python3-pyzfs-2.2.7-1.fc41.noarch
  sysstat-12.7.6-2.fc41.x86_64
  zfs-2.2.7-1.fc41.x86_64
Added:
  chkconfig-1.31-1.fc41.x86_64
  initscripts-10.26-1.fc41.x86_64
  initscripts-rename-device-10.26-1.fc41.x86_64
  zfs-fuse-0.7.2.2-31.fc41.x86_64
Changes queued for next boot. Run "systemctl reboot" to start a reboot

Note: Before the rebase I was on the version 41.20250113.6 from aurora-dx:stable-daily, and it is still booted, as seen below:

State: idle
Deployments:
  ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:41-20250113.7
                   Digest: sha256:09170913ea8e5047fe9d336de32a184a4f430700d28a7ef24e34532d50bc0c4e
                  Version: latest-41.20250113.7 (2025-01-13T08:03:16Z)
                     Diff: 7 upgraded, 11 removed, 4 added

● ostree-image-signed:docker://ghcr.io/ublue-os/aurora-dx:stable-daily
                   Digest: sha256:d135686f77be55dfe6fad6dd277d4e32e53ca749fe144bc11efebd0bed0cb90c
                  Version: 41.20250113.6 (2025-01-13T07:23:23Z)
                   Pinned: yes

The "problem" here is that the version of the new deployment is latest-41.20250113.7.

What did you expect to happen?

1. My expectation was that when rebasing on a particular date (version), I would get the stable-daily images, which are supposed to be more stable (at least because of the more conservative kernel) than the latest images.

2. To be honest, at this point I'm not even sure what is the difference between latest and stable-daily, except the kernel. Is the latest stream reserved for future potential experiments, like adding the newest unstable versions of KDE or such? In this case I find the naming a bit confusing. For me, instead of latest -> beta-daily describes much better the intent and periodicity.

Please excuse me if I'm mistaken or I misunderstand something, I am relatively new to the ublue ecosystem.

[inffy]

This looks normal to me. When you rebase to a date image it will lock you to that specific date.

It will take you "off" from the stable-daily stream and pin you to image from that date. You will not receive updates unless you rebase back to stable/daily/latest

Difference between stable and latest is the kernel, which in stable is gated from coreOS and in latest has the rolling from normal fedora updates.

[etvt]

When you rebase to a date image it will lock you to that specific date. It will take you "off" from the stable-daily stream and pin you to image from that date. You will not receive updates unless you rebase back to stable/daily/latest

This is fully clear, and I don't see any issue with this.

---

My point is that I think it matters which stream do we take that pinned image from, when we "rebase to date".
Currently seemingly "it is taken" from the latest images, but I think it should be taken from the stable-daily images. I don't see why would anybody want to rebase back into the past to the old latest images. I think it is much more common use case that people want to rebase back to the previous stable-daily images, with more stable kernel. Or if this is not the case, maybe the rebase-helper's "rebase to date" option should offer to choose between latest or stable-daily first, then list the daily versions for that selection.

---

Somewhat independently from the above, it is misleading that the image with name and tag aurora-dx:41-20250113.7 contains the Version: latest-41.20250113.7 (notice latest-). Isn't this a build metainfo bug?

Shouldn't this image's name and tag be aurora-dx:latest-41-20250113.7 (notice the added latest-)?
And shouldn't aurora-dx:41-20250113.7 have the version Version: 41.20250113.7 (notice no latest-)?

[inffy]

I talked to the ublue guys who have created the helper and currently (on Aurora) as we don't have gts-stream the date selection will pick image from the latest branch. The helper was created before bluefin produced the stable/stable-daily streams and hasn't (atleast yet) been updated to the new image streams.

If you want to rebase to stable image with a lower kernel, best way to do it is with the instructions from the Releases page which has rebase commands for the stable releases.

I'll leave this open if we at some point rewrite the helper script

[etvt]

Thanks, that's understandable!

In addition to the instructions on the linked Releases page, which describes how to manually switch to those stable images, it seems that manually switching to stable-daily images works as well, which is exactly what I needed, thanks!

Example output below:

❯ sudo bootc switch --enforce-container-sigpolicy ghcr.io/ublue-os/aurora-dx:stable-daily-20250113.5
[sudo] password for <user>: 
layers already present: 67; layers needed: 5 (559.7 MB)
Fetching layers ████░░░░░░░░░░░░░░░░ 1/5 
 └ Fetching ███████░░░░░░░░░░░░░ 51.55 MiB/142.47 MiB (27.67 MiB/s) ostree chunk 4f2943911488575dfa7d7

Notice the only 5 layers difference, compared to 41 when previously used rebase-helper (which rebased on the latest images).

(It would be nice if in the future this functionality could be included in the rebase-helper too, to assist users in finding all the possible images from the stable-daily or stable streams too.)