I had dependabot turned on on base and it found a version update so PRing to other repos... sorry fo
I had dependabot turned on on base and it found a version update so PRing to other repos... sorry for the noise
Kall good, merging that now, appreciate it
JI figured out the installer last night!
Jok tldr, you whip up a ublue.ks or whatever
Jwith this:
ostreesetup --osname="fedora" --remote="fedora" --url="https://d2uk5hbyrobdzx.cloudfront.net/" --ref="fedora/37/x86_64/silverblue" --nogpgJnow this is the existing thing, so it needs a normal ostree remote, not an oci one (which they haven't written yet)
Jinstall the
lorax package, which gives is the tool: mkksiso ublue.ks Fedora-Server-netinst-x86_64-37-1.7.iso ublue.isoJand that slipstreams the kickstart into a new ISO
Jthen I booted off of it and it installed from that custom url as you would expect
Jso when they land the oci thing, we modify the ks file to be whatever the arguments will be, and then slipstream a 38 build the day after they enable the feature
JI was thinking we'd have a new action, on release snag the everthing or server netinstalls (I tested both and they both work), generate a ks file based on the container address, and then generate the iso, sign it, and attach it to github.
Msweet!
Jbasically, mkkiso is the jam
JI wonder if we should try to have completely offline installers, or have an Everything-style ISO which lets us choose between a variety of images to download
Jthe ks file doesn't need to be huge, if it's missing any part the installer will prompt the user, so with that minimal one all we're setting is the remote address basically
Jyeah so I ran out of time
Jif we wanted to you could take the iso, expand it, and then there's another set of tools to "add a repo" onto the CD.
Jso we could make fat ISOs too
MI also pushed up the first boot installer work from last week: https://github.com/ublue-os/yafti
- going to generate github issues, etc to start fanning out collaboration
Jbut this way is only 550MB or so and it was fast to manipulate
Jto make a real iso the way fedora does it the thing to learn is called
lorax, it replaced an older toolJwhat I will try is a nightly 38 build
HGitHub
Immutable Fedora-based Xfce desktop . Contribute to ublue-os/vauxite development by creating an account on GitHub.
Joh that's that permissions thing again, it can't push
Jwe need to figure that out still, merging it will work fine
CWow
This stuff looks awesome!
I think it covers almost everything I could hope for in an installer; the only thing left is - would it be possible to generalize one step further up to selecting the DE, then the core/gaming/office/etc options?
This stuff looks awesome!
I think it covers almost everything I could hope for in an installer; the only thing left is - would it be possible to generalize one step further up to selecting the DE, then the core/gaming/office/etc options?
J@hyperreal64 yeah merging it should work fine, we need to fix that, it happens to everyone on every PR right now
M@ChaiQi it likely won't be in the core installer, but it could be extended
MAs I write the docs I'll be sure to include clear instructions on how to extend the installer with working code examples
CNice! That sounds rather useful 
Joh nice, this is nicer than the stock installer
Jthere are ZERO flatpaks installed
Jso that means we won't need to rip stuff out and put it back
Jall that's on there is the fedora remotes, but they don't install flatpaks
J@marcoceppi I know this goes without saying but we need to make sure the wizard is idempotent in the beginning
Mmakes sense
Jif the installer is 38 I wonder if that means we should just do 38+ for ISOs
J@ChaiQi you're not the only one apparently: https://www.omgubuntu.co.uk/2023/02/ubuntu-mini-iso-redux
OMG! Ubuntu!Joey Sneddon
A new network installer is in development for Ubuntu 23.04. The size of the ISO could be as low as 140MIB making it a good fit for USB & CDs.
J"brings up a dynamic TUI menu of what Ubuntu images you want to download/install to your target system"
DSo this is basically like debian netinstall?
JI haven't used a debian netinstall since like 2004 so I don't remember what it does lol
Jsounds like this one will just splat the image onto disk so it should be way faster than the older installers
JGitHub
This leverages shell scripting and https://github.com/TomWright/dasel to read the list of packages to install in ublue-firstboot and the containerfile.
If in the future another firstboot solution i...
If in the future another firstboot solution i...
JI need to test the image but their PR can't push to the registry
Jideas?
XWhat yall talked about with the composability / eating our dogfood sounds fantastic, especially as the current selection of non-nvidia images feels very GNOME-oriented.
XAlso: Thanks for adding me to the org!
XYeah, I locally built the image and everything seems to work. Just can't figure out how to rebase without it being in a registry. Don't know why the push fails, thought that was intentional. I don't think anything I changed should affect that.
JI sent an invite, accept it and then it should work, I just put you in the org
CInteresting! The idea occurred to me for two reasons:
- There were already a lot of parallel images, then when I mentioned steam-devices y'all went from it to udev rules to all udev rules to codecs to app bundles to a modular repo system, and the potential image count/complexity ballooned. A unified installer seemed like a great way to manage that complexity in the user space. If you offer base, Silverblue, Kinoite, Vauxite, and two or three more options, that last one dramatically cuts the chance that someone will ever choose any of them over another distro. Big hazard in marketing and the psychology of decision making in general. One installer for all of them with no-selection defaults alleviates it
- Regardless of necessity, it's a relatively "simple" type of feature which at least Windows if not Mac users expect, and it's a lot less imposing as a first step than working from the command line. I would hope that it somewhat bridges the gap of what users somewhat arbitrarily think of as polished and indicative of a consumer-ready operating system due to familiarity and availability heuristics
Jwell, tbh, the udev-rules have been there since the beginning, it was only just a scratch container tho
