Could this be useful for populating /opt or similar during container build-time? I don't know if my

Could this be useful for populating /opt or similar during container build-time?

I don't know if my interpretation of the changelog is correct, but my understanding is that if you shove stuff in /usr/share/factory/var (such as 1Password stuff or RPMs that expect to be able to write to /opt?), it will be copied to /var on boot

https://github.com/ostreedev/ostree/releases/tag/v2023.8

GitHub

Release 2023.8 · ostreedev/ostree

This release stabilizes "deployment finalization locking" which
is very useful for automatic update workflows.

sysroot: Stabilize deployment finalization, add API by @cgwalters in #3090
...

RRobert Could this be useful for populating /opt or similar during container build-time?...

akdev•12/6/23, 5:20 PM

The easy solution would be to create a symlink in /opt -> /usr/share/factory/var/opt in the container during build time and remove it at the end of the build

le_melon•12/6/23, 7:41 PM

Does this have positive implications for including pre-installed Flatpaks and Homebrew?

akdev•12/6/23, 8:47 PM

Flatpaks probably not a good idea

akdev•12/6/23, 8:47 PM

As it would require double the storage

le_melon•12/6/23, 11:00 PM

However, it may work yeah?

Lle_melon However, it may work yeah?

EyeCantCU•12/6/23, 11:07 PM

At one point I was doing something similar to this but caching it in a different directory. Suffice to say it led to monstrous image sizes that toppled over what GHCR could handle. I would say no as is. There's some work being done to make this process better though

EyeCantCU•12/6/23, 11:09 PM

The problem is you're not just bringing.in the program. You take in the deps too. Which as you can imagine, especially for systems that use the NVIDIA driver, this can be huuuge

Kyle Gospo•12/6/23, 11:11 PM

makes every update bigger too untl diffed downloads is complete

Lle_melon However, it may work yeah?

akdev•12/6/23, 11:29 PM

Yeah but it is already possible to do that with Lorax (not sure about osbuild)

Fedora upstream does it like this: https://github.com/akdev1l/mkociso/blob/main/src/mkociso/lorax_templates/lorax-embed-flatpaks.tmpl

bsherman•12/7/23, 6:19 AM

We've got a nice improvement for "just update" pending an approval. Please take a lool.

https://github.com/ublue-os/config/pull/167

HikariKnight•12/7/23, 12:34 PM

ooo thats a nice addition

EEyeCantCU At one point I was doing something similar to this but caching it in a different...

le_melon•12/7/23, 7:03 PM

OK, thank you. Yeah ghcr gets the job done a bunch of the time but it does have a bunch of challenges to it.
Given a different registry, potentially different outcomes

Lle_melon OK, thank you. Yeah ghcr gets the job done a bunch of the time but it does have ...

EyeCantCU•12/7/23, 7:04 PM

Even if it could handle the larger image sizes, Kyle makes a good point. Bigger and bigger updates would be a hurdle as well

EyeCantCU•12/7/23, 7:04 PM

And no problem

Aakdev Yeah but it is already possible to do that with Lorax (not sure about osbuild) ...

le_melon•12/7/23, 7:05 PM

Thank you for the link.
I'm wondering whether similar commands are able to be called inside of the build steps inside a Fedora image

EEyeCantCU Even if it could handle the larger image sizes, Kyle makes a good point. Bigger ...

le_melon•12/7/23, 7:08 PM

I'm interested in how this can be solved in a way where the image size isn't through the room and at least some Flatpaks are pre-installed. Does the standard Fedora Silverblue ISO not include any Flatpaks by default?

Lle_melon I'm interested in how this can be solved in a way where the image size isn't thr...

EyeCantCU•12/7/23, 7:11 PM

Standard GNOME version does but only in the installation media

EyeCantCU•12/7/23, 7:11 PM

They are not shipped on the image itself

EyeCantCU•12/7/23, 7:11 PM

We can do this with lorax

EyeCantCU•12/7/23, 7:11 PM

But the isogenerator we have in place doesn't support it

le_melon•12/7/23, 7:26 PM

OK, gotcha

le_melon•12/7/23, 7:28 PM

The purpose of what I'm trying to achieve is to have a pre-installed OS on a bootable USB media to have software, a user account all there.
I'm wondering if it's possible with osbuild, given I'm using this
https://github.com/osbuild/bootc-image-builder and bootcbootc (trialing each for the purpose)

GitHub

GitHub - osbuild/bootc-image-builder

Contribute to osbuild/bootc-image-builder development by creating an account on GitHub.

jstone•12/7/23, 9:04 PM

Can someone with the right permissions sync this repo to bump the nvidia driver version? https://github.com/ublue-os/asus-nvidia

GitHub

GitHub - ublue-os/asus-nvidia: ASUS Fedora variants with built-in N...

ASUS Fedora variants with built-in Nvidia drivers. Contribute to ublue-os/asus-nvidia development by creating an account on GitHub.

Jjstone Can someone with the right permissions sync this repo to bump the nvidia driver ...

EyeCantCU•12/7/23, 9:06 PM

On it

jstone•12/7/23, 9:08 PM

Thank you!

j0rge•12/7/23, 9:31 PM

woo all green!

j0rge•12/7/23, 9:31 PM

(unless onyx 39 470 decides to hate us)

EyeCantCU•12/7/23, 9:34 PM

Got Surface NVIDIA too

EyeCantCU•12/7/23, 9:39 PM

Quite happy with how well everything has been working on my Pro 7+. Just need IPU4 camera support but I don't expect that anytime soon... Pixel got an update to use it as a webcam so not the end of the world either

EyeCantCU•12/7/23, 9:40 PM

Trying Squeekboard on GNOME too see if it's a viable replacement for GNOME keyboard in our downstream images for Surface and Deck too

j0rge•12/7/23, 9:42 PM

we have an open issue for ipu4

j0rge•12/7/23, 9:43 PM

there's a copr and everything

j0rge•12/7/23, 9:44 PM

https://github.com/ublue-os/main/issues/229 oh sorry that's IPU6, I'm unfamiliar with the nomenclature of these new cameras

EyeCantCU•12/7/23, 9:44 PM

Interesting IPU6 support came before IPU4

EyeCantCU•12/7/23, 9:45 PM

From what I've read, IPU3 support took forever so I wouldn't expect IPU4 support anytime soon. I've seen work on a driver for it though it doesn't work atm

Javvy•12/7/23, 9:50 PM

Javvy•12/7/23, 9:50 PM

that is a curious binary

jstone•12/7/23, 9:51 PM

It looks like the updated images haven't yet been pushed, is that to be expected? https://github.com/ublue-os/asus-nvidia/pkgs/container/silverblue-asus-nvidia

j0rge•12/7/23, 9:55 PM

I kicked off a build, the merge didn't fire off a build

j0rge•12/7/23, 9:55 PM

https://github.com/ublue-os/asus-nvidia/actions/runs/7134444554

JJavvy Click to see attachment

beekabop•12/7/23, 9:58 PM

https://packages.fedoraproject.org/pkgs/coreutils/coreutils/fedora-39.html its coming from this package

coreutils-9.3-4.fc39 - Fedora Packages

View coreutils-9.3-4.fc39 in Fedora 39. coreutils: A set of basic GNU tools commonly used in shell scripts

Javvy•12/7/23, 9:58 PM

cool cool

Javvy•12/7/23, 10:03 PM

Javvy•12/7/23, 10:04 PM

we can switch back to 4.8.1 soon, it's still in testing for F38

jstone•12/7/23, 10:05 PM

Excellent, that worked!

$ rpm-ostree update
note: automatic updates (stage) are enabled
Pulling manifest: ostree-image-signed:docker://ghcr.io/ublue-os/silverblue-asus-nvidia:latest
Importing: ostree-image-signed:docker://ghcr.io/ublue-os/silverblue-asus-nvidia:latest (digest: sha256:8ecb7ef30c4398907f7bba27328b8f11b4b4596f05096267aff485357b6bf076)
ostree chunk layers already present: 65
custom layers already present: 2
custom layers needed: 1 (714.9 MB)
Staging deployment... done
Upgraded:
  kmod-nvidia-6.6.3-666.rog.fc39.x86_64 3:535.129.03-1.fc39 -> 3:545.29.06-1.fc39
  nvidia-persistenced 3:535.129.03-1.fc39 -> 3:545.29.06-1.fc39
  nvidia-settings 3:535.129.03-1.fc39 -> 3:545.29.06-1.fc39
  xorg-x11-drv-nvidia 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39
  xorg-x11-drv-nvidia-cuda 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39
  xorg-x11-drv-nvidia-cuda-libs 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39
  xorg-x11-drv-nvidia-cuda-libs 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39
  xorg-x11-drv-nvidia-devel 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39
  xorg-x11-drv-nvidia-kmodsrc 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39
  xorg-x11-drv-nvidia-libs 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39
  xorg-x11-drv-nvidia-libs 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39
  xorg-x11-drv-nvidia-power 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39
Added:
  nvidia-modprobe-3:545.29.06-1.fc39.x86_64
Run "systemctl reboot" to start a reboot

$ rpm-ostree update
note: automatic updates (stage) are enabled
Pulling manifest: ostree-image-signed:docker://ghcr.io/ublue-os/silverblue-asus-nvidia:latest
Importing: ostree-image-signed:docker://ghcr.io/ublue-os/silverblue-asus-nvidia:latest (digest: sha256:8ecb7ef30c4398907f7bba27328b8f11b4b4596f05096267aff485357b6bf076)
ostree chunk layers already present: 65
custom layers already present: 2
custom layers needed: 1 (714.9 MB)
Staging deployment... done
Upgraded:
  kmod-nvidia-6.6.3-666.rog.fc39.x86_64 3:535.129.03-1.fc39 -> 3:545.29.06-1.fc39
  nvidia-persistenced 3:535.129.03-1.fc39 -> 3:545.29.06-1.fc39
  nvidia-settings 3:535.129.03-1.fc39 -> 3:545.29.06-1.fc39
  xorg-x11-drv-nvidia 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39
  xorg-x11-drv-nvidia-cuda 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39
  xorg-x11-drv-nvidia-cuda-libs 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39
  xorg-x11-drv-nvidia-cuda-libs 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39
  xorg-x11-drv-nvidia-devel 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39
  xorg-x11-drv-nvidia-kmodsrc 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39
  xorg-x11-drv-nvidia-libs 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39
  xorg-x11-drv-nvidia-libs 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39
  xorg-x11-drv-nvidia-power 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39
Added:
  nvidia-modprobe-3:545.29.06-1.fc39.x86_64
Run "systemctl reboot" to start a reboot

JJavvy we can switch back to 4.8.1 soon, it's still in testing for F38

Javvy•12/7/23, 10:10 PM

I created PR for this https://github.com/ublue-os/main/pull/444

GitHub

chore(podman): Remove the workaround for podman by john-ghatas · Pu...

Seeing the package page of Fedora podman 4.8.1 has dropped in the stable branch; https://src.fedoraproject.org/rpms/podman.
I propose we remove this workaround whenever is viable

Javvy•12/7/23, 10:10 PM

Also #444, nice!

j0rge•12/7/23, 10:36 PM

nice.

EyeCantCU•12/7/23, 11:01 PM

Prompt is GOAT. So nice to be able to set a profile with ZSH without overriding the login shell

EyeCantCU•12/7/23, 11:01 PM

And then have one for each distrobox

$ rpm-ostree update note: automatic updates (stage) are enabled Pulling manifest: ostree-image-signed:docker://ghcr.io/ublue-os/silverblue-asus-nvidia:latest Importing: ostree-image-signed:docker://ghcr.io/ublue-os/silverblue-asus-nvidia:latest (digest: sha256:8ecb7ef30c4398907f7bba27328b8f11b4b4596f05096267aff485357b6bf076) ostree chunk layers already present: 65 custom layers already present: 2 custom layers needed: 1 (714.9 MB) Staging deployment... done Upgraded: kmod-nvidia-6.6.3-666.rog.fc39.x86_64 3:535.129.03-1.fc39 -> 3:545.29.06-1.fc39 nvidia-persistenced 3:535.129.03-1.fc39 -> 3:545.29.06-1.fc39 nvidia-settings 3:535.129.03-1.fc39 -> 3:545.29.06-1.fc39 xorg-x11-drv-nvidia 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39 xorg-x11-drv-nvidia-cuda 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39 xorg-x11-drv-nvidia-cuda-libs 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39 xorg-x11-drv-nvidia-cuda-libs 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39 xorg-x11-drv-nvidia-devel 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39 xorg-x11-drv-nvidia-kmodsrc 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39 xorg-x11-drv-nvidia-libs 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39 xorg-x11-drv-nvidia-libs 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39 xorg-x11-drv-nvidia-power 3:535.129.03-2.fc39 -> 3:545.29.06-1.fc39 Added: nvidia-modprobe-3:545.29.06-1.fc39.x86_64 Run "systemctl reboot" to start a reboot

Could this be useful for populating /opt or similar during container build-time? I don't know if my

Similar Threads

Similar Threads

Similar Threads