@bsherman we can now default to systemd-resolved on bluefin LTS
@bsherman we can now default to systemd-resolved on bluefin LTS
Jwait what are we using now?
Tnetworkmanager's default resolv.conf thing
Joh
Jew
Tyes.
Ti hate it too
Tand it breaks tailscale
JI know I get the errors
JI wish fedora would do a reboot and just throw away all this old shit
Jit's like "First!" but not really
Tyeah i hate all this stuff too
Jthis is what happens when people whine about supporting bios computers on modern distros, they get stuck in the past.
Tlike, centos' default desktop group includes that old logging method i forgot the name of
Bwhat changed? is this related to bootc#1167?
Twe wont get those weird podman errors on
/etc/resolv.conf and /etc/hostnamefeels like there was a different issue, but i'm happy to move to systemd-resolved if it works
JIt'd be nice to have working tailscale lol
Ti mean, you can get it working fine, but its not the default (sadly)
JI had to fix it on my trip
Bit needs to work right on the build 
Tugh that sucks
Jbut I did what tailscale told me to do I didn't switch to resolved
Talso works
Jwhat's fedora on?
Tsystemd-resolved
Tthats why tailscale just works
Joh we should match that then imo
Jwe can discuss that in the bluefin channel later
Tyupyup
Mokay. I'm going to see if I can rewrite the main workflows to move on
Additionally should make it easier to port to another CI system
justAdditionally should make it easier to port to another CI system
Malso, apparently the default hostname is generated by systemd from /etc/os-release.
It is then in /run/systemd/hostname
It is then in /run/systemd/hostname
Jhttps://github.com/pulls?user=ublue-os lots of things in the queue if people looking to do some reviews
J(this url is always linked in the topic of this channel btw)
TThis is as expected, as you will see from my initial report, linked above. When Distrobox sees that there is no
/etc/hostnamepodman run --hostname (?) flag instead of bind-mounting /etc/hostnamepodman inspect mybox for a 41 and 42 ’box for details.) The problem comes when migrating a 41 ’box to 42, since it remains hard-coded to expect the bind-mounted file to be there.TBy hard-coded, I refer to attributes baked into the generated container, not in the image. This is why rebuilding the ’box fixes it.
TI believe there is a JSON file hidden somewhere on the graphroot you can hack to fix this, but that's ugly.
Rhttps://github.com/89luca89/distrobox/blob/3b9f0e8d3d8bd102e1636a22afffafe00777d30b/distrobox-create#L908-L917
This is the part that sets up the bind mount.
It's not a F41 -> F42 thing, but rather a bootc bump which is causing this
This is the part that sets up the bind mount.
It's not a F41 -> F42 thing, but rather a bootc bump which is causing this
JAnyone else's builds pick up SRPMs again?
JMakmod-openrazer was the cause this time
MI feel like dnf thinks there is an unmatched version or something
AYes
JGitHub
Describe the bug After the update to stable-20250427.1 distrobox enter does not work anymore. ~ ❯ distrobox enter bazzite-arch Error: unable to start container "de958224666fe6aeb9d6eac26f49a64...
Rwhat's Rstudio?
MSo that was to have a rootful podman container take over your install for a little bit.
Basically you could test out a new image without installing.... On your current running system.
Basically you could test out a new image without installing.... On your current running system.
Toooooooooh its that cool thing!
Ti know yeah!
Tdo we still wanna do that?
MI have removed a lot of traces of it. I seriously don't know if there were any hardware effects since basically a new systemd instance with access to your hardware runs
MIt's probably one of those things that if you know you need this.... You know
