This needs adjustments for the spec file. I can look into that in a while. I've been pretty busy wit
This needs adjustments for the spec file. I can look into that in a while. I've been pretty busy with family this week
Dwait why does it need adjustments in the spec file?
KIt's built into an rpm
KYou added a new file so the spec that defines the rpm has to be updated
Doh ok
Dthnx
Dyes, that is why I did the PR. I also did it so you can use sudo for things that are installed with nix (default profile only)
Awould it be possible for the surface-specific images to use the refind bootloader instead of grub? refind supports touchscreens, i feel like it'd be a better choice than grub on a tablet
FI think that's hard to implement & requires a lot of maintainance
Aah
Dare the maintainers aware that the bazzite image is five days old?
EYep. Not concerned. Lots of stuff shifted this week
Doh ok. just glad you are aware. I also kept in mimd that the maintainers have life outside of discord and coding.
EIt's all right... I kind of see it like this - even if updates were pushed out only once every two weeks that's still more frequent than a lot of other projects
Dyeah and most of the things that get updated when new images are built are from upstream
DI just need one more person to approve this then it will be ready to merge
Tis there more to this issue that's being done elsewhere? https://github.com/ublue-os/bazzite/issues/237
I ran into this, and manage to rollback a pinned deploy but I'm not sure if the process is a bug or not in ostree or rpm-ostree, because it doesn't make sense and it's not documented AFAICT?
I ran into this, and manage to rollback a pinned deploy but I'm not sure if the process is a bug or not in ostree or rpm-ostree, because it doesn't make sense and it's not documented AFAICT?
Jwhat's the problem?
Bthat is because of the kargs
Bbooted images, setting kargs new image, and normal you only have two, current and rollback. so any non pinned deployment will roll of
Ti rebased to bazzite, it did a second deploy such that a simple 'rpm-ostree rollback' would not have rolled back to my previous deploy that i was at when I rebased
Tyes, the kargs
Tbazzite rebooted with this:
Initramfs: '-I /etc/crypttab /etc/modprobe.d/amdgpu.conf'Byeah so to rollback you can not use rollback, but need todo a rebase instead
Bat least not in the case where kargs have been set
TI ended up doing
ostree admin deploy <commit_id> where commit_id matched the pinned deployment , but I still needed to do a rollbackBpinned deployments are in grub aren't they?
Boh i see
Tyes. I was apprehensive about booting into it with grub because I read that it would only be a temporary fix
Tif you can rebase into a pinned version, that's cool. I didn't see how to do that
Bno if i'm correct you boot via grub into your pinned deployment, and then when you get an update it just writes a new deployment unpinned
Band the pinned one just stays there
T.. because the new updated deployment becomes the new default in grub? makes sense
Bexactly
Tor just any rpm-ostree install <pkg>
Bi think you are right 
Byep i just verified. i've pinned a previous deployment, booted into it. cleanup the now "pending" one, did an upgrade and it turned out exactly as we say earlier
JGitHub
Contribute to Ultramarine-Linux/ostree-config development by creating an account on GitHub.
AIt’s doing the same thing we are doing
Awith Lorax
Jyeah I thought I'd just point it out!
JAThe way they handle the imgref is way cleaner
Hok i finished making the changes to bazzite-hardware-setup to make it support user defined initramfs arguments and such.
if this is something needed across ublue i will gladly write something more ublue generic as i know this only was an issue with bazzite (with vfio enabled) and how it handles initramfs arguments for different hardware support
https://github.com/ublue-os/bazzite/pull/586
hope the americans are having a nice thanksgiving weekend
if this is something needed across ublue i will gladly write something more ublue generic as i know this only was an issue with bazzite (with vfio enabled) and how it handles initramfs arguments for different hardware support
https://github.com/ublue-os/bazzite/pull/586
hope the americans are having a nice thanksgiving weekend
GitHub
This adds come needed flexibility to how bazzite-hardware-setup handles initramfs args.
Changes:
Added /etc/bazzite/initramfs/ as $INITRAMFS_DIR
Added /etc/bazzite/initramfs/args.d/ as $INITRAMFS_C...
Changes:
Added /etc/bazzite/initramfs/ as $INITRAMFS_DIR
Added /etc/bazzite/initramfs/args.d/ as $INITRAMFS_C...
Hinput and changes are welcome, i just mocked this up as good as possible to solve the problem i knew we had at least
Jawesome! I'd love to have this in bluefin and kyle says we'll need this in nvidia too?
KOn nvidia it's useful for loading the driver and unloading nouveau
KLittle more bulletproof
KAlso doesn't need the same huge build time increase since only a file in /etc/ is needed
