this is awesome, would you consider working on this to submit it to the documentation? It'd be amazi
this is awesome, would you consider working on this to submit it to the documentation? It'd be amazing.
BI need to get comfortable with the devcontainers workflow... i think it's the step which may make dev work better for me
XThe startingpoint rewrite PR is no longer a draft. Reviews this way ->> https://github.com/ublue-os/startingpoint/pull/135
XI also have a small PR for the website to be merged at the same time ->> https://github.com/ublue-os/website/pull/445
XHuge thanks to @Gerblesh for the contributions on this one.
0Yea. It significantly enhanced my dev workflow.
BGitHub
(sorry on a plane will add more detail later) We may have a volunteer to help do this after I announced the project on the framework forums. Just outlining what we'd need to do this. The TLDR i...
MHas there been any work on getting systemd-homed to work? It's seemingly enabled by default and the pam modules are easy enough to edit to work with authselect. However SELinux seems to be a blocker due to the wrong "profiles" not sure of name haven't used SELinux much before.
If I put SELinux into permissive mode it works.
I think systemd-homed would probably be a good fit for this model. But I guess it probably still a bit immature for user creation from the installer
If I put SELinux into permissive mode it works.
I think systemd-homed would probably be a good fit for this model. But I guess it probably still a bit immature for user creation from the installer
E@akdev any inventive ways for how we could set inst.resolution=1280x800 just for Deck here? Since kickstart isn't being pulled in here, I'm not sure how we'd handle isolating the Deck
https://github.com/ublue-os/lorax-compose/blob/main/lorax-templates/efi.tmpl
https://github.com/ublue-os/lorax-compose/blob/main/lorax-templates/efi.tmpl
Anot really, I need to learn a bit more about mako templates
only idea I've had is using env vars but it's kinda bad
only idea I've had is using env vars but it's kinda bad
AI want to expose functionality to override grub with your own template and also inject files but not sure how to it yet
GAlso curious, is everything in place to make an offline M1 Mac ISO? We have lorax compose, so we can easily make the ISO a different architecture, we just need to build an arm image
GI'm guessing we can also install different packages/drivers in the installer with lorax
GThough idk, need to look into lorax more
ANot at all, there's not even apple silicon ostree images
GIt's a different bootloader right?
AI made one and was actually able to boot but my Macbook was really slow
ALike 1 second on the clock would take minutes to pass
GAnd kernel + other packages
AThose images still use grub but they chainload from m1n1
AGAh
GSo still a lot of work to be done
AYeah, it's difficult to debug because I have no idea what I'm doing lmaoo
Am1n1 chainloads to uboot and that chainloads to grub
GWould be nice if Marcan or someone on the asahi project helped out with it
AAnd I tried converting a regular fedora Asahi Remix installation to ostree
ABecause there's no installer for this
AAnaconda can't really I guess and Fedora Asahi people use calamares
GBut I understand it's not a priority at all atm
AThey also use KIWI to compose the OS which i have no clue about lol
AIt's the tool used by opensuse
GWhar
GThey use such weird tooling lol
GLike why calemares?
AI think they just like it better
GAh, yeah I'd prefer KDE first time setup + new anaconda webUI
EThat would be sweet. Don't mind looking into that this weekend but not sure I'd be able to figure it out
EOh wait. It's Saturday 
AI built
mkociso to abstract away lorax so currently we can do like this: mkociso --image ghcr.io/ublue-os/bazzite:38 and it will create an ISOAI think the goal is to add something like:
these two templates are what we need to override to hijack the boot menu
these two templates are what we need to override to hijack the boot menu
Aor maybe it should be like:
EEither would be perfect and accomplish what we need to do
EI personally like the second approach
G@tulili hi, I can't respond on github atm but the bling module only pulls in the items specified, sure it's copied into the image, but it's in /tmp, so all of the rpms are removed from the image. Only the ones that are installed are kept inside the image (specified in bling module) bling module also isn't needed in the recipe.yml
GThis also isn't too streamlined, but technically one could define their own repo and add it in the container file, and write an installer script in modules. Would work just fine
TOh hi!
TNo, no, it wasn't exactly that that I was trying to convey, I just thought that maybe by separating where the modules are declared from the repos themselves might be a good idea
TLike, before all files that were cloned onto the images based off of StartingPoint were declared in their own repos, and that made updating things like the ublue-nix-install script a lot worse, since it wasn't necessarily centralized onto one repo (in this case, bling!)
TI just thought that maybe my moving the "modules" folder in the Startingpoint template to other repo, like bling, we could have a better way to keep everyone up-to-date with their module implementations, without requiring them to sync their repos with github's fork thing (which can be very annoying at times when merge conflicts happen)
