B@M2 ?
Bit's weird how it does truly seem random
Myepp. LIke I said. I first thought it was something with kinoite based on F39.... but F40 I'm like wtf
Bkinoite and surface seem to be broken both 9 hours ago and 1hour ago in f40 but others?
Mkinoite's failure is just transaction failed. No other reason. The asus ones didn't kernel swap for some reason. The old kernel was there and dracut failed because of it.
BI'd love to see a cause for
error: Error -1 running transactionBThis one failed VERY fast https://github.com/ublue-os/hwe/actions/runs/10008285666/job/27668102987
Mhttps://github.com/ublue-os/hwe/actions/runs/10008285666/job/27668106961#step:13:332
this is bad kernel swap
this is bad kernel swap
Bis that dracut error coming from the regenerate initramfs ?
B- /tmp/build-initramfs.sh
Myes. Dracut is trying to regenerate the initramfs and it's trying to use the old kernel instead of the new kernel
Bhmmm
Mi wonder if I'm using a glob instead of kernel there
Myeah it's splitting there and thinking there are two modules directorys
Mhttps://github.com/ublue-os/hwe/actions/runs/10008285666/job/27668098247#step:13:419
Yeah looks like on onyx it split randomly while here it was fine
Yeah looks like on onyx it split randomly while here it was fine
GitHub
Fedora variants with support for ASUS devices, Nvidia devices, and Surface laptops - ublue hwe 40 · ublue-os/hwe@2f63b20
Bnot sure what you mean by "split"
Boh,
Bi can at least see how this one was good
Mgoing to add x to the initramfs script and an ls on /usr/lib/modules to maybe see what's going on there.
Theory is that on some surface/asus kernel swaps its not fully removing the /lib/modules/OLDKERNEL/ path
Theory is that on some surface/asus kernel swaps its not fully removing the /lib/modules/OLDKERNEL/ path
Byeah
Bgood plan
Msomething must be wrong with F40 onyx build
Mhttps://github.com/ublue-os/hwe/actions/runs/10009720949/job/27669240947#step:13:301
For some reason rpm thinks there are two kernels installed even though only one in /lib/modules
For some reason rpm thinks there are two kernels installed even though only one in /lib/modules
GitHub
Fedora variants with support for ASUS devices, Nvidia devices, and Surface laptops - chore(ci): Debugging build failures · ublue-os/hwe@894e0ea
Bthis does use
could there be an extra package left behind?
rpm -qa https://github.com/ublue-os/hwe/blob/main/build-initramfs.sh#L16could there be an extra package left behind?
Bone that wasn't explicitly replaced
Beh, looks pretty clear it's 2 packages named like
kernel-6.9.9-2YZ.fc40.x86_64Mbut it's not happening on all images
Mwe could use find there instead of using the rpm -qa maybe?
Mtrying a dumb idea. But for some reason on some images rpm is reporting two kernels installed
Bso, there's 2 problems...
1) even though we have 2 kernel packages installed, we'd want the correct action of building for the desired kernels, so we could make that detection more specific...
2) it's pretty crazy there's a kernel package left behind at all
1) even though we have 2 kernel packages installed, we'd want the correct action of building for the desired kernels, so we could make that detection more specific...
2) it's pretty crazy there's a kernel package left behind at all
Mon surface it's bizarre since we explicitly remove kernel packages. I guess we could try doing a glob remove?
Mthis seemed to fix asus
https://github.com/ublue-os/hwe/actions/runs/10009936626/job/27669960659#step:13:306
But onyx must be a corrupted image or something?
https://github.com/ublue-os/hwe/actions/runs/10009936626/job/27669960659#step:13:306
But onyx must be a corrupted image or something?
GitHub
Fedora variants with support for ASUS devices, Nvidia devices, and Surface laptops - chore(ci): Debugging build failures · ublue-os/hwe@45fbc66
MI think we give this a day since something different is happening than before
MIt is hitting bluefin as well
MGitHub
The next generation Linux workstation, designed for reliability, performance, and sustainability. - Aurora Latest · ublue-os/bluefin@c8c2d15
MAurora failed to build while Bluefin was fine
MGitHub
The next generation Linux workstation, designed for reliability, performance, and sustainability. - Bluefin Latest · ublue-os/bluefin@c8c2d15
Merrors both start after the change in main from m0gg. However, as noted we had some weird global issue yesterday and maybe there are knock on effects occuring
Mif this is still bugged in 2 days I think we revert m0gg's PR to see if things go back to normal. We are for some reason getting a transaction errors and rpm is not cleaning itself up properly
M
MSo here's are problem. For some reason rpm-ostree override replace isn't always cleaning up the rpm database
M@Kyle Gospo see above. On kinoite 39/40, Onyx 40 the above is occuring.
rpm-ostree override replace is not removing the previous kernel name. Something more is happening with Onyx
KI'm in agreement on the revert, I think kernels in main is ambitious
Kthey're hard to install to begin with
Mi'm unsure if its the kernel swap causing the issue or if it's the pr using a nested buildah
Mbut its also not on all images which is more confusing
Kcould test that w/ a quick fork
Ksee if it does anything different not as a PR
Mthe issue is that main is building green and its only a certain few images not working right. Silverblue is for some reason but not kinoite
Msame behaviour from CI is happening locally with Onyx 40
