Ok, Ok, I’m not a pro in the update processes, but why not force to go back to the previous version of dracut or at least report it. Not easy for uninitiated people, especially since the update is marked as stable.
So, if I go back to the previous version of dracut, it’s good? dracut 100 or other?
sudo dnf install fedora-repos-archive
sudo dnf downgrade dracut
# re-create the initramfs for the a specific kernel version
sudo dracut --force --kver 6.8.12-300.fc40.x86_64
# or use option --regenerate-all instead of --kver
# sudo dracut --force updates for the currenty running kernel version only
you can disable the updates-archive repository if you wish with
for now you'll want to prevent upgrades for dracut until this has been resolved.
either by adding the line
exclude=dracut\*
to /etc/dnf/dnf.conf
or by setting up a version lock
sudo dnf install python3-dnf-plugin-versionlock
sudo dnf versionlock add dracut\*
sudo dnf versionlock list
man dnf-versionlock for more info
or by adding the option --exclude=dracut\* to any dnf upgrade command
important: you will also need to disable automatic updates in any GUI app like Software (gnome)!
I've just setup a virtual VM with encrypted luks volume (default gnome image )
$ uname -r
6.8.12-300.fc40.x86_64
$ rpm -qa dracut\*
dracut-060-1.fc40.x86_64
dracut-network-060-1.fc40.x86_64
dracut-live-060-1.fc40.x86_64
dracut-config-rescue-060-1.fc40.x86_64
dracut-squash-060-1.fc40.x86_64
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 20G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 1G 0 part /boot
└─sda3 8:3 0 19G 0 part
└─luks-d49955f8-e762-413c-bc68-aef03f78ef68 253:0 0 19G 0 crypt /home
/
sr0 11:0 1 1024M 0 rom
zram0 252:0 0 3.8G 0 disk [SWAP]
I have the same problem with nfsd. This kernel shouldn't have gotten this far and shouldn't be released with a critical error in a critical service. It has the potential to bring down thousands of servers and to disrupt an untold number of users. If this goes forward, then what is the point of testing?
@robatino, I've updated the bug. It does not happen on 6.8.11 -- I've reverted to that kernel for the time being.
@bojan, I do not see the potential fix queued for 6.9; that's why I'm requesting a look at the following commit and requesting review that it might be the fix and should be included in the next kernel for Fedora 40 (whatever that is)
This update has been submitted for testing by jforbes.
This update's test gating status has been changed to 'waiting'.
Works on our systems. (Download from koji.)
LGTM
This update's test gating status has been changed to 'passed'.
VM in virtualbox
This update has been pushed to testing.
This update can be pushed to stable now if the maintainer wishes
Works.
The 6.9.12 stable kernel update contains a number of important fixes across the tree. ???
The problem with dracut fixed? Because kernel 6.8.11 and dracut 101 do not work.
works also on bare metal with dracut-101 (not using encryted volumes! ) kernel regression and performance tests successfully passed
Boot fails with kernel-6.8.12, dracut-101 and partition luks. Boot fails before reaching the LUKS password
Same with kernel 6.8-11, but it’s ok with kernel-6.8.10
Identical configuration
@micmor no reason to give a negative karma. it's not a kernel issue but a dracut issue downgrade dracut to the previous version
@anotheruser
Ok, Ok, I’m not a pro in the update processes, but why not force to go back to the previous version of dracut or at least report it. Not easy for uninitiated people, especially since the update is marked as stable.
So, if I go back to the previous version of dracut, it’s good? dracut 100 or other?
Thank you
the previous version was dracut-060
what you can do:
you can disable the updates-archive repository if you wish with
for now you'll want to prevent upgrades for dracut until this has been resolved.
important: you will also need to disable automatic updates in any GUI app like Software (gnome)!
I've just setup a virtual VM with encrypted luks volume (default gnome image )
oh well, the newly instaled vm boots a initramfs created with dracut-101.
open a thread on askfedora so more people can look into this. It's probably something specific with your setup...
LGTM on Framework 13 AMD 7840U. dracut is at 101-1.fc40. btrfs on LUKS, GNOME on Wayland.
#2284279 NFS server failure
RIP: 0010:gss_free_in_token_pages+0x2b/0xc0 [auth_rpcgss]Works without issues till now
Works without issues till now
I can confirm what @amessina posted above - NFS server is indeed broken.
default & performance tests pass (KVM)
Works fine on Lenovo ThinkPad P1 Gen 2
Working fine for me in a VirtualBox VM.
@jforbes is looks like upstream may have worked out the nfs server issue I reported earlier: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/net/sunrpc?h=next-20240604&id=4a77c3dead97339478c7422eb07bf4bf63577008
Are you able to say if this will be included the the next kernel release?
It seems to be lined up in 6.9.x, which will be the next kernel, given 6.8 is dead. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/log/net/sunrpc?h=queue/6.9
I have the same problem with nfsd. This kernel shouldn't have gotten this far and shouldn't be released with a critical error in a critical service. It has the potential to bring down thousands of servers and to disrupt an untold number of users. If this goes forward, then what is the point of testing?
Is nfs broken with 6.8.11 (the current stable kernel) as well? #2284279 doesn't say.
I've only seen these traces with .12.
@robatino, I've updated the bug. It does not happen on 6.8.11 -- I've reverted to that kernel for the time being.
@bojan, I do not see the potential fix queued for 6.9; that's why I'm requesting a look at the following commit and requesting review that it might be the fix and should be included in the next kernel for Fedora 40 (whatever that is)
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/net/sunrpc?h=next-20240604&id=4a77c3dead97339478c7422eb07bf4bf63577008
Yes, you are correct @amessina. I thought this was the same patch in 6.9 queue:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/?h=queue/6.9&id=8ca148915670a2921afcc255af9e1dc80f37b052
But, that's a fix for a different issue.
Works fine for me with Thinkpad P1 Gen4 and LUKS. Didn't test NFS.
NFS (server) works fine for me and this release actually fixes a similar general protection fault (#2290881) for me.
rathann edited this update.
(edited the 6.9.12 -> 6.8.12 typo in the description)
Works fine in a server I am using.
Works fine for me with LUKS. NFS not tested
Asus Zenbook 14 UX3405MA camera can't be detected after upgrading to this kernel
The internal camera is well recognized. lsusb : Bus 001 Device 007: ID 5986:0683 Bison Electronics Inc. BisonCam, NB Pro .
It's queued now @amessina: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/commit/net/sunrpc?h=queue/6.9&id=2e851b6d4a1e23e92f7f3d02f2d1b31cbce5f37b
This update has been obsoleted by kernel-6.9.4-200.fc40.