Re: Last kernel update leads to emergency mode
On Thu, Aug 31, 2023 at 3:50 PM George N. White III wrote: > >> >[...] >> > Given the fact that an older kernel works, but a newer one doesn't, it >> > sure seems like it is somehow related to the kernel. Since the same >> > version of systemd works on an old kernel, it is unlikely to be >> > systemd. Maybe you should change the bugzilla to point to the >> > kernel. You could also look through the kernel updates at >> > https://lkml.org/ to see if there is one related to warm restarts. I >> > think that might also be called suspend. There are lot of updates, >> > though, so this is a significant task. >> >> Thanks, again, Stan. I will be paying attention to >> >> https://lkml.org/ > > Search for "site: lkml.org warm reboot restart" shows a lot of activity, > often related to > specific hardware, so it is most useful if you know low level details for > your hardware. > You may want to try running a stripped down configuration to see of some > add-on > card causing the issue. Thanks, George, for your suggestion! Fortunately, the bug report I have filed has recently had reasonable activity. Paul ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On Thu, Aug 31, 2023 at 9:26 AM Paul Smith wrote: > On Wed, Aug 30, 2023 at 2:04 PM stan via users > wrote: > >[...] > > Given the fact that an older kernel works, but a newer one doesn't, it > > sure seems like it is somehow related to the kernel. Since the same > > version of systemd works on an old kernel, it is unlikely to be > > systemd. Maybe you should change the bugzilla to point to the > > kernel. You could also look through the kernel updates at > > https://lkml.org/ to see if there is one related to warm restarts. I > > think that might also be called suspend. There are lot of updates, > > though, so this is a significant task. > > Thanks, again, Stan. I will be paying attention to > > https://lkml.org/ > Search for "site: lkml.org warm reboot restart" shows a lot of activity, often related to specific hardware, so it is most useful if you know low level details for your hardware. You may want to try running a stripped down configuration to see of some add-on card causing the issue. -- George N. White III ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On Wed, Aug 30, 2023 at 2:04 PM stan via users wrote: > > > Maybe the following is relevant: > > > > > > # dracut --force --kver 6.4.12-200.fc38.x86_64 --verbose > > dracut: Executing: /usr/bin/dracut --force --kver > > 6.4.12-200.fc38.x86_64 --verbose > > dracut: dracut module 'busybox' will not be installed, because command > > 'busybox' could not be found! > > dracut: dracut module 'connman' will not be installed, because command > > 'connmand' could not be found! > > dracut: dracut module 'connman' will not be installed, because command > > 'connmanctl' could not be found! > > dracut: dracut module 'connman' will not be installed, because command > > 'connmand-wait-online' could not be found! > I see the connman errors when I build the initramfs, but it works fine. > > dracut: dracut module 'network-wicked' will not be installed, because > > command 'wicked' could not be found! > > dracut: dracut module 'biosdevname' will not be installed, because > > command 'biosdevname' could not be found! > > dracut: dracut module 'busybox' will not be installed, because command > > 'busybox' could not be found! > > dracut: dracut module 'connman' will not be installed, because command > > 'connmand' could not be found! > > dracut: dracut module 'connman' will not be installed, because command > > 'connmanctl' could not be found! > > dracut: dracut module 'connman' will not be installed, because command > > 'connmand-wait-online' could not be found! > > dracut: dracut module 'network-wicked' will not be installed, because > > command 'wicked' could not be found! > I think these can be taken as warnings rather than errors, unless you > are using busybox or network-wicked in the suspended version. > > dracut: *** Including module: bash *** > > dracut: *** Including module: systemd *** > > dracut: *** Including module: systemd-initrd *** > > dracut: *** Including module: systemd-sysusers *** > > dracut: *** Including module: nss-softokn *** > > dracut: *** Including module: dbus-broker *** > > dracut: *** Including module: rngd *** > > dracut: *** Including module: dbus *** > > dracut: *** Including module: i18n *** > > dracut: *** Including module: network-manager *** > > dracut: *** Including module: network *** > > dracut: *** Including module: ifcfg *** > > dracut: *** Including module: drm *** > > dracut: *** Including module: plymouth *** > > dracut: *** Including module: dm *** > > dracut: Skipping udev rule: 64-device-mapper.rules > > dracut: Skipping udev rule: 60-persistent-storage-dm.rules > > dracut: Skipping udev rule: 55-dm.rules > > dracut: *** Including module: kernel-modules *** > > dracut: *** Including module: kernel-modules-extra *** > > dracut: *** Including module: kernel-network-modules *** > > dracut: *** Including module: lvm *** > > dracut: Skipping udev rule: 64-device-mapper.rules > > dracut: Skipping udev rule: 56-lvm.rules > > dracut: Skipping udev rule: 60-persistent-storage-lvm.rules > > dracut: *** Including module: resume *** > > dracut: *** Including module: rootfs-block *** > > dracut: *** Including module: terminfo *** > > dracut: *** Including module: udev-rules *** > > dracut: Skipping udev rule: 40-redhat.rules > > dracut: Skipping udev rule: 50-firmware.rules > > dracut: Skipping udev rule: 50-udev.rules > > dracut: Skipping udev rule: 91-permissions.rules > > dracut: Skipping udev rule: 80-drivers-modprobe.rules > > dracut: Skipping udev rule: 70-persistent-net.rules > > dracut: *** Including module: dracut-systemd *** > > dracut: *** Including module: usrmount *** > > dracut: *** Including module: base *** > > dracut: *** Including module: fs-lib *** > > dracut: *** Including module: memstrack *** > > dracut: *** Including module: shutdown *** > > dracut: *** Including modules done *** > > dracut: *** Installing kernel module dependencies *** > > dracut: *** Installing kernel module dependencies done *** > > dracut: *** Resolving executable dependencies *** > > dracut: *** Resolving executable dependencies done *** > > dracut: *** Hardlinking files *** > > dracut: Mode: real > > dracut: Method: sha256 > > dracut: Files:2153 > > dracut: Linked: 81 files > > dracut: Compared: 0 xattrs > > dracut: Compared: 974 files > > dracut: Saved:563.14 KiB > > dracut: Duration: 0.057574 seconds > > dracut: *** Hardlinking files done *** > > dracut: *** Generating early-microcode cpio image *** > > dracut: *** Constructing AuthenticAMD.bin *** > > dracut: *** Store current command line parameters *** > > dracut: *** Stripping files *** > > dracut: *** Stripping files done *** > > dracut: *** Creating image file > > '/boot/initramfs-6.4.12-200.fc38.x86_64.img' *** dracut: Using > > auto-determined compression method 'pigz' dracut: *** Creating > > initramfs image file '/boot/initramfs-6.4.12-200.fc38.x86_64.img' > >
Re: Last kernel update leads to emergency mode
On Wed, 30 Aug 2023 00:38:08 +0100 Paul Smith wrote: > Maybe the following is relevant: > > > # dracut --force --kver 6.4.12-200.fc38.x86_64 --verbose > dracut: Executing: /usr/bin/dracut --force --kver > 6.4.12-200.fc38.x86_64 --verbose > dracut: dracut module 'busybox' will not be installed, because command > 'busybox' could not be found! > dracut: dracut module 'connman' will not be installed, because command > 'connmand' could not be found! > dracut: dracut module 'connman' will not be installed, because command > 'connmanctl' could not be found! > dracut: dracut module 'connman' will not be installed, because command > 'connmand-wait-online' could not be found! I see the connman errors when I build the initramfs, but it works fine. > dracut: dracut module 'network-wicked' will not be installed, because > command 'wicked' could not be found! > dracut: dracut module 'biosdevname' will not be installed, because > command 'biosdevname' could not be found! > dracut: dracut module 'busybox' will not be installed, because command > 'busybox' could not be found! > dracut: dracut module 'connman' will not be installed, because command > 'connmand' could not be found! > dracut: dracut module 'connman' will not be installed, because command > 'connmanctl' could not be found! > dracut: dracut module 'connman' will not be installed, because command > 'connmand-wait-online' could not be found! > dracut: dracut module 'network-wicked' will not be installed, because > command 'wicked' could not be found! I think these can be taken as warnings rather than errors, unless you are using busybox or network-wicked in the suspended version. > dracut: *** Including module: bash *** > dracut: *** Including module: systemd *** > dracut: *** Including module: systemd-initrd *** > dracut: *** Including module: systemd-sysusers *** > dracut: *** Including module: nss-softokn *** > dracut: *** Including module: dbus-broker *** > dracut: *** Including module: rngd *** > dracut: *** Including module: dbus *** > dracut: *** Including module: i18n *** > dracut: *** Including module: network-manager *** > dracut: *** Including module: network *** > dracut: *** Including module: ifcfg *** > dracut: *** Including module: drm *** > dracut: *** Including module: plymouth *** > dracut: *** Including module: dm *** > dracut: Skipping udev rule: 64-device-mapper.rules > dracut: Skipping udev rule: 60-persistent-storage-dm.rules > dracut: Skipping udev rule: 55-dm.rules > dracut: *** Including module: kernel-modules *** > dracut: *** Including module: kernel-modules-extra *** > dracut: *** Including module: kernel-network-modules *** > dracut: *** Including module: lvm *** > dracut: Skipping udev rule: 64-device-mapper.rules > dracut: Skipping udev rule: 56-lvm.rules > dracut: Skipping udev rule: 60-persistent-storage-lvm.rules > dracut: *** Including module: resume *** > dracut: *** Including module: rootfs-block *** > dracut: *** Including module: terminfo *** > dracut: *** Including module: udev-rules *** > dracut: Skipping udev rule: 40-redhat.rules > dracut: Skipping udev rule: 50-firmware.rules > dracut: Skipping udev rule: 50-udev.rules > dracut: Skipping udev rule: 91-permissions.rules > dracut: Skipping udev rule: 80-drivers-modprobe.rules > dracut: Skipping udev rule: 70-persistent-net.rules > dracut: *** Including module: dracut-systemd *** > dracut: *** Including module: usrmount *** > dracut: *** Including module: base *** > dracut: *** Including module: fs-lib *** > dracut: *** Including module: memstrack *** > dracut: *** Including module: shutdown *** > dracut: *** Including modules done *** > dracut: *** Installing kernel module dependencies *** > dracut: *** Installing kernel module dependencies done *** > dracut: *** Resolving executable dependencies *** > dracut: *** Resolving executable dependencies done *** > dracut: *** Hardlinking files *** > dracut: Mode: real > dracut: Method: sha256 > dracut: Files:2153 > dracut: Linked: 81 files > dracut: Compared: 0 xattrs > dracut: Compared: 974 files > dracut: Saved:563.14 KiB > dracut: Duration: 0.057574 seconds > dracut: *** Hardlinking files done *** > dracut: *** Generating early-microcode cpio image *** > dracut: *** Constructing AuthenticAMD.bin *** > dracut: *** Store current command line parameters *** > dracut: *** Stripping files *** > dracut: *** Stripping files done *** > dracut: *** Creating image file > '/boot/initramfs-6.4.12-200.fc38.x86_64.img' *** dracut: Using > auto-determined compression method 'pigz' dracut: *** Creating > initramfs image file '/boot/initramfs-6.4.12-200.fc38.x86_64.img' > done *** # This all looks fine. The journalctl log you posted showed that the initramfs was working properly, and was able to start systemd to do the actual boot. It only failed at verifying that
Re: Last kernel update leads to emergency mode
On Tue, Aug 29, 2023 at 11:41 PM Paul Smith wrote: > > > > > > Thanks, Stan. I guess the files are almost similar, since they > > > > > have almost the same size: > > > > > > > > I agree. Your issue isn't the issue I had. Debugging these early > > > > issues is hard, because it has to be done from the emergency > > > > console. But, I think I remember there being other consoles to > > > > switch to that had things like logs, and there are some commands > > > > available, if you do an > > > > ls /usr/bin > > > > or > > > > ls /usr/sbin > > > > you should be able to examine the system to some extent to find why > > > > it is failing. I remember using less and vi at least. Could you > > > > mount one of the partitions and save / cp or cat the logs to a file > > > > there, maybe in your home directory. Then you can examine them > > > > from a working system, and even attach them to a bugzilla or email. > > > > > > > > > # ls -n /boot/initramfs* > > > > > -rw---. 1 0 0 83396891 Jan 21 2020 > > > > > /boot/initramfs-0-rescue-5cbe81aa795444b29a47ec1bf2b6dca1.img > > > > > -rw---. 1 0 0 37876860 Aug 14 11:45 > > > > > /boot/initramfs-6.4.10-200.fc38.x86_64.img > > > > > -rw---. 1 0 0 37878341 Aug 26 12:28 > > > > > /boot/initramfs-6.4.12-200.fc38.x86_64.img > > > > > > Thanks, Stan. Finally, I was able to capture the log of > > > > > > journalctl -xb > > > > > > which is at: > > > > > > https://bugzilla-attachments.redhat.com/attachment.cgi?id=1985687 > > > > So, this seems to be the error: > > Aug 28 19:05:39 localhost @ystemctl[626]: Failed to switch root: > > Specified switch root path '/sysroot' does not seem to be an OS tree. > > os-release file is missing. > > > > And it looks like it was triggered by this: > > Aug 28 19:05:39 localhost systemd[1]: Received SIGRTMIN+20 from PID 569 > > (plymouthd). > > > > After that message, systemd starts shutting down instead of starting up. > > > > Do you have fedora-release for fc38 installed? I can't see how you > > wouldn't, but just confirming. It looks like there is a bug in the > > code that is determining whether os-release is present, but only for > > warm restarts, not for cold boots. That would be plymouthd. > > Or whatever is creating the warm restart isn't creating it properly, so > > that plymouthd can recognize it, I think that would be systemd. > > > > Were either of those in the large batch of updates you installed? If > > so, you could try downgrading them from koji to see if it fixes the > > error. > > https://koji.fedoraproject.org/koji/ > > Thanks, Stan. > > I do have: > > # rpm -q fedora-release-38 > fedora-release-38-36.noarch > # > > Moreover, both plytmouth and systemd that I have installed correspond > to versions dated earlier than the date of the first occurrence of the > reported issue. > > With the older > > kernel-6.4.10-200.fc38.x86_64 > > there is no issue. Maybe the following is relevant: # dracut --force --kver 6.4.12-200.fc38.x86_64 --verbose dracut: Executing: /usr/bin/dracut --force --kver 6.4.12-200.fc38.x86_64 --verbose dracut: dracut module 'busybox' will not be installed, because command 'busybox' could not be found! dracut: dracut module 'connman' will not be installed, because command 'connmand' could not be found! dracut: dracut module 'connman' will not be installed, because command 'connmanctl' could not be found! dracut: dracut module 'connman' will not be installed, because command 'connmand-wait-online' could not be found! dracut: dracut module 'network-wicked' will not be installed, because command 'wicked' could not be found! dracut: dracut module 'biosdevname' will not be installed, because command 'biosdevname' could not be found! dracut: dracut module 'busybox' will not be installed, because command 'busybox' could not be found! dracut: dracut module 'connman' will not be installed, because command 'connmand' could not be found! dracut: dracut module 'connman' will not be installed, because command 'connmanctl' could not be found! dracut: dracut module 'connman' will not be installed, because command 'connmand-wait-online' could not be found! dracut: dracut module 'network-wicked' will not be installed, because command 'wicked' could not be found! dracut: *** Including module: bash *** dracut: *** Including module: systemd *** dracut: *** Including module: systemd-initrd *** dracut: *** Including module: systemd-sysusers *** dracut: *** Including module: nss-softokn *** dracut: *** Including module: dbus-broker *** dracut: *** Including module: rngd *** dracut: *** Including module: dbus *** dracut: *** Including module: i18n *** dracut: *** Including module: network-manager *** dracut: *** Including module: network *** dracut: *** Including module: ifcfg *** dracut: *** Including module: drm *** dracut: *** Including module: plymouth *** dracut: *** Including module: dm *** dracut: Skipping udev rule: 64-device-mapper.rules dracut: Skipping udev rule:
Re: Last kernel update leads to emergency mode
On Tue, Aug 29, 2023 at 6:15 PM stan via users wrote: > > > > > Thanks, Stan. I guess the files are almost similar, since they > > > > have almost the same size: > > > > > > I agree. Your issue isn't the issue I had. Debugging these early > > > issues is hard, because it has to be done from the emergency > > > console. But, I think I remember there being other consoles to > > > switch to that had things like logs, and there are some commands > > > available, if you do an > > > ls /usr/bin > > > or > > > ls /usr/sbin > > > you should be able to examine the system to some extent to find why > > > it is failing. I remember using less and vi at least. Could you > > > mount one of the partitions and save / cp or cat the logs to a file > > > there, maybe in your home directory. Then you can examine them > > > from a working system, and even attach them to a bugzilla or email. > > > > > > > # ls -n /boot/initramfs* > > > > -rw---. 1 0 0 83396891 Jan 21 2020 > > > > /boot/initramfs-0-rescue-5cbe81aa795444b29a47ec1bf2b6dca1.img > > > > -rw---. 1 0 0 37876860 Aug 14 11:45 > > > > /boot/initramfs-6.4.10-200.fc38.x86_64.img > > > > -rw---. 1 0 0 37878341 Aug 26 12:28 > > > > /boot/initramfs-6.4.12-200.fc38.x86_64.img > > > > Thanks, Stan. Finally, I was able to capture the log of > > > > journalctl -xb > > > > which is at: > > > > https://bugzilla-attachments.redhat.com/attachment.cgi?id=1985687 > > So, this seems to be the error: > Aug 28 19:05:39 localhost @ystemctl[626]: Failed to switch root: > Specified switch root path '/sysroot' does not seem to be an OS tree. > os-release file is missing. > > And it looks like it was triggered by this: > Aug 28 19:05:39 localhost systemd[1]: Received SIGRTMIN+20 from PID 569 > (plymouthd). > > After that message, systemd starts shutting down instead of starting up. > > Do you have fedora-release for fc38 installed? I can't see how you > wouldn't, but just confirming. It looks like there is a bug in the > code that is determining whether os-release is present, but only for > warm restarts, not for cold boots. That would be plymouthd. > Or whatever is creating the warm restart isn't creating it properly, so > that plymouthd can recognize it, I think that would be systemd. > > Were either of those in the large batch of updates you installed? If > so, you could try downgrading them from koji to see if it fixes the > error. > https://koji.fedoraproject.org/koji/ Thanks, Stan. I do have: # rpm -q fedora-release-38 fedora-release-38-36.noarch # Moreover, both plytmouth and systemd that I have installed correspond to versions dated earlier than the date of the first occurrence of the reported issue. With the older kernel-6.4.10-200.fc38.x86_64 there is no issue. Paul ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On Mon, 28 Aug 2023 19:33:41 +0100 Paul Smith wrote: > On Mon, Aug 28, 2023 at 3:25 PM stan wrote: > > > > > Thanks, Stan. I guess the files are almost similar, since they > > > have almost the same size: > > > > I agree. Your issue isn't the issue I had. Debugging these early > > issues is hard, because it has to be done from the emergency > > console. But, I think I remember there being other consoles to > > switch to that had things like logs, and there are some commands > > available, if you do an > > ls /usr/bin > > or > > ls /usr/sbin > > you should be able to examine the system to some extent to find why > > it is failing. I remember using less and vi at least. Could you > > mount one of the partitions and save / cp or cat the logs to a file > > there, maybe in your home directory. Then you can examine them > > from a working system, and even attach them to a bugzilla or email. > > > > > # ls -n /boot/initramfs* > > > -rw---. 1 0 0 83396891 Jan 21 2020 > > > /boot/initramfs-0-rescue-5cbe81aa795444b29a47ec1bf2b6dca1.img > > > -rw---. 1 0 0 37876860 Aug 14 11:45 > > > /boot/initramfs-6.4.10-200.fc38.x86_64.img > > > -rw---. 1 0 0 37878341 Aug 26 12:28 > > > /boot/initramfs-6.4.12-200.fc38.x86_64.img > > Thanks, Stan. Finally, I was able to capture the log of > > journalctl -xb > > which is at: > > https://bugzilla-attachments.redhat.com/attachment.cgi?id=1985687 So, this seems to be the error: Aug 28 19:05:39 localhost @ystemctl[626]: Failed to switch root: Specified switch root path '/sysroot' does not seem to be an OS tree. os-release file is missing. And it looks like it was triggered by this: Aug 28 19:05:39 localhost systemd[1]: Received SIGRTMIN+20 from PID 569 (plymouthd). After that message, systemd starts shutting down instead of starting up. Do you have fedora-release for fc38 installed? I can't see how you wouldn't, but just confirming. It looks like there is a bug in the code that is determining whether os-release is present, but only for warm restarts, not for cold boots. That would be plymouthd. Or whatever is creating the warm restart isn't creating it properly, so that plymouthd can recognize it, I think that would be systemd. Were either of those in the large batch of updates you installed? If so, you could try downgrading them from koji to see if it fixes the error. https://koji.fedoraproject.org/koji/ ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On Mon, Aug 28, 2023 at 3:25 PM stan wrote: > > > Thanks, Stan. I guess the files are almost similar, since they have > > almost the same size: > > I agree. Your issue isn't the issue I had. Debugging these early > issues is hard, because it has to be done from the emergency console. > But, I think I remember there being other consoles to switch to that > had things like logs, and there are some commands available, if you do > an > ls /usr/bin > or > ls /usr/sbin > you should be able to examine the system to some extent to find why it > is failing. I remember using less and vi at least. Could you mount > one of the partitions and save / cp or cat the logs to a file there, > maybe in your home directory. Then you can examine them from a working > system, and even attach them to a bugzilla or email. > > > # ls -n /boot/initramfs* > > -rw---. 1 0 0 83396891 Jan 21 2020 > > /boot/initramfs-0-rescue-5cbe81aa795444b29a47ec1bf2b6dca1.img > > -rw---. 1 0 0 37876860 Aug 14 11:45 > > /boot/initramfs-6.4.10-200.fc38.x86_64.img > > -rw---. 1 0 0 37878341 Aug 26 12:28 > > /boot/initramfs-6.4.12-200.fc38.x86_64.img Thanks, Stan. Finally, I was able to capture the log of journalctl -xb which is at: https://bugzilla-attachments.redhat.com/attachment.cgi?id=1985687 Paul ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On Sat, Aug 26, 2023 at 3:30 PM stan via users wrote: > > > > > I have been able to take a screen-shot: > > > > > > > > https://i.imgur.com/nAsE6i6.jpg > > > > > > This means that dracut was unable to start systemd in order to > > > continue the boot once the initramfs was finished creating the > > > bootstrap. I have had this happen, but not with stock kernels. I > > > build custom kernels, and dracut was not building a complete > > > initramfs when they were installed. I had to write a script that > > > created a custom file that told dracut to include all missing > > > libraries, and run dracut again after install to fix the problem. > > > The missing libraries included some vital systemd libraries. > > > Because library versions change, I run the script to be sure that > > > the custom file includes the latest libraries. If this *is* the > > > cause, it will be obvious in /boot. The failing initramfs size will > > > be about half the size of an initramfs file that works. I could > > > not find any reason that dracut wasn't working properly when it > > > first installed the kernel; all the settings said it should have > > > put those libraries in, but I just could not get it to do so. > > > > > > If it is your issue, post back and I'll attach the file of > > > libraries and the directory to put it in, as well as the dracut > > > command to run. They might not work for you, since the version has > > > to be included. There is also a way to actually examine what is in > > > the initramfs, so you could see if the systemd libraries were > > > there. From the dracut man page, > > > > > > Inspecting the Contents > > >To see the contents of the image created by dracut, you can > > > use the lsinitrd tool. > > > > > ># lsinitrd | less > > > > > >To display the contents of a file in the initramfs also use > > > the lsinitrd tool: > > > > > ># lsinitrd -f /etc/ld.so.conf > > >include ld.so.conf.d/*.conf > > > > Thanks to all for your help! > > > > I have meanwhile been able to take photos from the > > > > journalctl -xb > > > > output, and I think that now the cause of the problem is isolated. > > > > I was hopeful that the new kernel update would fix the problem, but > > it did not. > > > > The photos of the journalctl logs are at: > > > > https://i.imgur.com/NJAjOmN.jpg > > You didn't show the listing of the /boot directory. > > ls -n /boot/ > or > ls -n /boot/initramfs* > > Is the initramfs for the failing kernel smaller than the initramfs for > the successful kernel? If you can still boot into an older kernel, you > can try rebuilding the initramfs manually, to see if it will fix any > problem. You have to run this within the /boot directory, as root or > sudo. Your command should be something like the following. > > # /usr/bin/dracut -f -v --no-compress --no-uefi > initramfs-6.4.11-200.fc38.x86_64.img --kver 6.4.11-200.fc38.x86_64 > > I use no compression and no uefi, but you can remove those if they don't fit > your system. > > Once you have a new initramfs, run lsinitrd on it and redirect it into > a file. Do the same for a working initramfs. Then run a diff on the > two with the output piped to less. For example, > > lsinitrd /boot/initramfs-6.4.11-200.fc38.x86_64.img > new_initramfs.txt > lsinitrd /boot/initramfs-6.4.8-200.fc38.x86_64.img > old_initramfs.txt > diff old_initramfs.txt new_initramfs.txt | less > > There should be almost no differences if the initramfs is OK. Thanks, Stan. I guess the files are almost similar, since they have almost the same size: # ls -n /boot/initramfs* -rw---. 1 0 0 83396891 Jan 21 2020 /boot/initramfs-0-rescue-5cbe81aa795444b29a47ec1bf2b6dca1.img -rw---. 1 0 0 37876860 Aug 14 11:45 /boot/initramfs-6.4.10-200.fc38.x86_64.img -rw---. 1 0 0 37878341 Aug 26 12:28 /boot/initramfs-6.4.12-200.fc38.x86_64.img # Paul ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On Sat, 26 Aug 2023 13:02:12 +0100 Paul Smith wrote: > On Fri, Aug 25, 2023 at 4:23 PM stan via users > wrote: > > > > > I have been able to take a screen-shot: > > > > > > https://i.imgur.com/nAsE6i6.jpg > > > > This means that dracut was unable to start systemd in order to > > continue the boot once the initramfs was finished creating the > > bootstrap. I have had this happen, but not with stock kernels. I > > build custom kernels, and dracut was not building a complete > > initramfs when they were installed. I had to write a script that > > created a custom file that told dracut to include all missing > > libraries, and run dracut again after install to fix the problem. > > The missing libraries included some vital systemd libraries. > > Because library versions change, I run the script to be sure that > > the custom file includes the latest libraries. If this *is* the > > cause, it will be obvious in /boot. The failing initramfs size will > > be about half the size of an initramfs file that works. I could > > not find any reason that dracut wasn't working properly when it > > first installed the kernel; all the settings said it should have > > put those libraries in, but I just could not get it to do so. > > > > If it is your issue, post back and I'll attach the file of > > libraries and the directory to put it in, as well as the dracut > > command to run. They might not work for you, since the version has > > to be included. There is also a way to actually examine what is in > > the initramfs, so you could see if the systemd libraries were > > there. From the dracut man page, > > > > Inspecting the Contents > >To see the contents of the image created by dracut, you can > > use the lsinitrd tool. > > > ># lsinitrd | less > > > >To display the contents of a file in the initramfs also use > > the lsinitrd tool: > > > ># lsinitrd -f /etc/ld.so.conf > >include ld.so.conf.d/*.conf > > Thanks to all for your help! > > I have meanwhile been able to take photos from the > > journalctl -xb > > output, and I think that now the cause of the problem is isolated. > > I was hopeful that the new kernel update would fix the problem, but > it did not. > > The photos of the journalctl logs are at: > > https://i.imgur.com/NJAjOmN.jpg You didn't show the listing of the /boot directory. ls -n /boot/ or ls -n /boot/initramfs* Is the initramfs for the failing kernel smaller than the initramfs for the successful kernel? If you can still boot into an older kernel, you can try rebuilding the initramfs manually, to see if it will fix any problem. You have to run this within the /boot directory, as root or sudo. Your command should be something like the following. # /usr/bin/dracut -f -v --no-compress --no-uefi initramfs-6.4.11-200.fc38.x86_64.img --kver 6.4.11-200.fc38.x86_64 I use no compression and no uefi, but you can remove those if they don't fit your system. Once you have a new initramfs, run lsinitrd on it and redirect it into a file. Do the same for a working initramfs. Then run a diff on the two with the output piped to less. For example, lsinitrd /boot/initramfs-6.4.11-200.fc38.x86_64.img > new_initramfs.txt lsinitrd /boot/initramfs-6.4.8-200.fc38.x86_64.img > old_initramfs.txt diff old_initramfs.txt new_initramfs.txt | less There should be almost no differences if the initramfs is OK. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On Fri, Aug 25, 2023 at 4:23 PM stan via users wrote: > > > I have been able to take a screen-shot: > > > > https://i.imgur.com/nAsE6i6.jpg > > This means that dracut was unable to start systemd in order to continue > the boot once the initramfs was finished creating the bootstrap. I > have had this happen, but not with stock kernels. I build custom > kernels, and dracut was not building a complete initramfs when > they were installed. I had to write a script that created a custom file > that told dracut to include all missing libraries, and run dracut again > after install to fix the problem. The missing libraries included some > vital systemd libraries. Because library versions change, I run the > script to be sure that the custom file includes the latest libraries. > If this *is* the cause, it will be obvious in /boot. The failing > initramfs size will be about half the size of an initramfs file that > works. I could not find any reason that dracut wasn't working properly > when it first installed the kernel; all the settings said it should > have put those libraries in, but I just could not get it to do so. > > If it is your issue, post back and I'll attach the file of libraries and > the directory to put it in, as well as the dracut command to run. They > might not work for you, since the version has to be included. There is > also a way to actually examine what is in the initramfs, so you could > see if the systemd libraries were there. From the dracut man page, > > Inspecting the Contents >To see the contents of the image created by dracut, you can use > the lsinitrd tool. > ># lsinitrd | less > >To display the contents of a file in the initramfs also use the > lsinitrd tool: > ># lsinitrd -f /etc/ld.so.conf >include ld.so.conf.d/*.conf Thanks to all for your help! I have meanwhile been able to take photos from the journalctl -xb output, and I think that now the cause of the problem is isolated. I was hopeful that the new kernel update would fix the problem, but it did not. The photos of the journalctl logs are at: https://i.imgur.com/NJAjOmN.jpg Paul ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On Thu, 24 Aug 2023 17:44:52 +0100 Paul Smith wrote: > I have been able to take a screen-shot: > > https://i.imgur.com/nAsE6i6.jpg This means that dracut was unable to start systemd in order to continue the boot once the initramfs was finished creating the bootstrap. I have had this happen, but not with stock kernels. I build custom kernels, and dracut was not building a complete initramfs when they were installed. I had to write a script that created a custom file that told dracut to include all missing libraries, and run dracut again after install to fix the problem. The missing libraries included some vital systemd libraries. Because library versions change, I run the script to be sure that the custom file includes the latest libraries. If this *is* the cause, it will be obvious in /boot. The failing initramfs size will be about half the size of an initramfs file that works. I could not find any reason that dracut wasn't working properly when it first installed the kernel; all the settings said it should have put those libraries in, but I just could not get it to do so. If it is your issue, post back and I'll attach the file of libraries and the directory to put it in, as well as the dracut command to run. They might not work for you, since the version has to be included. There is also a way to actually examine what is in the initramfs, so you could see if the systemd libraries were there. From the dracut man page, Inspecting the Contents To see the contents of the image created by dracut, you can use the lsinitrd tool. # lsinitrd | less To display the contents of a file in the initramfs also use the lsinitrd tool: # lsinitrd -f /etc/ld.so.conf include ld.so.conf.d/*.conf ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On 8/24/23 09:44, Paul Smith wrote: On Thu, Aug 24, 2023 at 4:26 PM Ranjan Maitra wrote: Are other also experience that with the new kernel: 6.4.10-200.fc38.x86_64 I have already file a bug but no answer: https://bugzilla.redhat.com/show_bug.cgi?id=2232838 I didn't have any problems, but I updated to 6.4.11 this morning so maybe try that. Thanks, Patrick: My bad: the problematic kernel is: kernel-6.4.11-200.fc38.x86_64 Can you boot into the older kernel? Yes, Ranjan, I can boot into an older kernel. Thanks! When such a thing very rarely has happened to me, it usually means that grub did not finish installing the new kernel update. Try reinstalling perhaps? Or rebuild grub? Thanks, Rajan and old sixpack13. I have tried to remove and then install the problematic kernel, but that does not fix the problem, unfortunately. I have been able to take a screen-shot: https://i.imgur.com/nAsE6i6.jpg If you remove the "quiet rhgb" from the end of the grub line before booting, you might be able to see better what's failing at the end. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On 08/24/2023 10:44 AM, Paul Smith wrote: I have been able to take a screen-shot: https://i.imgur.com/nAsE6i6.jpg Were you able to save the report and if so, can you attach it to your reply? I doubt that I'll be able to make use of it, but with luck, somebody here will. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On Thu, Aug 24, 2023 at 4:26 PM Ranjan Maitra wrote: > > > > > > > Are other also experience that with the new kernel: > > > > > > > > > > > > 6.4.10-200.fc38.x86_64 > > > > > > > > > > > > I have already file a bug but no answer: > > > > > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2232838 > > > > > > > > > > I didn't have any problems, but I updated to 6.4.11 this morning so > > > > > maybe try that. > > > > > > > > Thanks, Patrick: My bad: the problematic kernel is: > > > > > > > > kernel-6.4.11-200.fc38.x86_64 > > > > > > Can you boot into the older kernel? > > > > Yes, Ranjan, I can boot into an older kernel. Thanks! > > > > When such a thing very rarely has happened to me, it usually means that grub > did not finish installing the new kernel update. Try reinstalling perhaps? > Or rebuild grub? Thanks, Rajan and old sixpack13. I have tried to remove and then install the problematic kernel, but that does not fix the problem, unfortunately. I have been able to take a screen-shot: https://i.imgur.com/nAsE6i6.jpg Paul ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
> Dear All, > > Are other also experience that with the new kernel: > > 6.4.10-200.fc38.x86_64 > > I have already file a bug but no answer: > > https://bugzilla.redhat.com/show_bug.cgi?id=2232838 > > Have a nice day, > > Paul Personal I do not have trouble with kernel > 6.4.8, but my brother with his pure Intel Acer notebook (before graph. login: a black screen beginning with kernel 6.4.9). more ?: https://discussion.fedoraproject.org/t/f38-intel-skylake-xorg-and-kernel-6-4-9/87479/2 === anyway Kernel 6.4.9 fixed some CPU HW Bug's, but AFAIK without the kernel maintainer who usually do those task, and - AFAIK- therefore it seems Kernel 6.4.10 and later got some corrections. long story short: care to test kernel 6.4.12 ? https://bodhi.fedoraproject.org/updates/FEDORA-2023-bb4e6cd88b +++ be aware +++ that dnf do not remove your last correct booting kernel !!! ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On Tue Aug22'23 04:19:23PM, Paul Smith wrote: > From: Paul Smith > Date: Tue, 22 Aug 2023 16:19:23 +0100 > To: Community support for Fedora users > Reply-To: Community support for Fedora users > Subject: Re: Last kernel update leads to emergency mode > > On Tue, Aug 22, 2023 at 2:26 PM Ranjan Maitra wrote: > > > > > > > Are other also experience that with the new kernel: > > > > > > > > > > 6.4.10-200.fc38.x86_64 > > > > > > > > > > I have already file a bug but no answer: > > > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2232838 > > > > > > > > I didn't have any problems, but I updated to 6.4.11 this morning so > > > > maybe try that. > > > > > > Thanks, Patrick: My bad: the problematic kernel is: > > > > > > kernel-6.4.11-200.fc38.x86_64 > > > > Can you boot into the older kernel? > > Yes, Ranjan, I can boot into an older kernel. Thanks! > When such a thing very rarely has happened to me, it usually means that grub did not finish installing the new kernel update. Try reinstalling perhaps? Or rebuild grub? Ranjan ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On Tue, Aug 22, 2023 at 6:21 PM Samuel Sieb wrote: > > >>> Are other also experience that with the new kernel: > >>> > >>> 6.4.10-200.fc38.x86_64 > >>> > >>> I have already file a bug but no answer: > >>> > >>> https://bugzilla.redhat.com/show_bug.cgi?id=2232838 > >> > >> You didn't really provide any info that would help. Can you get any > >> journal output or the sos file? Is there any indication of what is > >> going wrong? > > > > Thanks, Samuel and Geoffrey. > > > > I have meanwhile uploaded the log file corresponding to > > > > journalctl -xb > > That's not the log from the failed boot. It looks like you booted to > the previous kernel and ran that from the running system. The log won't > be written to disk, so you have to look at it right then and possibly > save it to some external storage if possible. Thanks, Samuel. The problem is that, apparently, it is not possible to mount a pendrive. Therefore, I do not know how to grab the log file. Paul ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On 8/22/23 03:37, Paul Smith wrote: On Tue, Aug 22, 2023 at 4:31 AM Samuel Sieb wrote: Are other also experience that with the new kernel: 6.4.10-200.fc38.x86_64 I have already file a bug but no answer: https://bugzilla.redhat.com/show_bug.cgi?id=2232838 You didn't really provide any info that would help. Can you get any journal output or the sos file? Is there any indication of what is going wrong? Thanks, Samuel and Geoffrey. I have meanwhile uploaded the log file corresponding to journalctl -xb That's not the log from the failed boot. It looks like you booted to the previous kernel and ran that from the running system. The log won't be written to disk, so you have to look at it right then and possibly save it to some external storage if possible. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On Tue, Aug 22, 2023 at 2:26 PM Ranjan Maitra wrote: > > > > > Are other also experience that with the new kernel: > > > > > > > > 6.4.10-200.fc38.x86_64 > > > > > > > > I have already file a bug but no answer: > > > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2232838 > > > > > > I didn't have any problems, but I updated to 6.4.11 this morning so > > > maybe try that. > > > > Thanks, Patrick: My bad: the problematic kernel is: > > > > kernel-6.4.11-200.fc38.x86_64 > > Can you boot into the older kernel? Yes, Ranjan, I can boot into an older kernel. Thanks! Paul ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On Mon Aug21'23 05:13:34PM, Paul Smith wrote: > From: Paul Smith > Date: Mon, 21 Aug 2023 17:13:34 +0100 > To: Community support for Fedora users > Reply-To: Community support for Fedora users > Subject: Re: Last kernel update leads to emergency mode > > On Mon, Aug 21, 2023 at 5:10 PM Patrick O'Callaghan > wrote: > > > > > Are other also experience that with the new kernel: > > > > > > 6.4.10-200.fc38.x86_64 > > > > > > I have already file a bug but no answer: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2232838 > > > > I didn't have any problems, but I updated to 6.4.11 this morning so > > maybe try that. > > Thanks, Patrick: My bad: the problematic kernel is: > > kernel-6.4.11-200.fc38.x86_64 > Can you boot into the older kernel? Ranjan ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On Tue, Aug 22, 2023 at 4:31 AM Samuel Sieb wrote: > > > Are other also experience that with the new kernel: > > > > 6.4.10-200.fc38.x86_64 > > > > I have already file a bug but no answer: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2232838 > > You didn't really provide any info that would help. Can you get any > journal output or the sos file? Is there any indication of what is > going wrong? Thanks, Samuel and Geoffrey. I have meanwhile uploaded the log file corresponding to journalctl -xb at: https://bugzilla.redhat.com/attachment.cgi?id=1984571 Paul ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On Mon, 21 Aug 2023 20:30:44 -0700 Samuel Sieb wrote: > On 8/21/23 08:56, Paul Smith wrote: > > Are other also experience that with the new kernel: > > > > 6.4.10-200.fc38.x86_64 > > > > I have already file a bug but no answer: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2232838 > > You didn't really provide any info that would help. Can you get any > journal output or the sos file? Is there any indication of what is > going wrong? FWIW I had a similar problem recently with a F37 system. After being unable to figure out a reason for the emergency mode -- in particular journalctl was clean, as was fstab -- I re-installed, which resolved the problem. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On 8/21/23 08:56, Paul Smith wrote: Are other also experience that with the new kernel: 6.4.10-200.fc38.x86_64 I have already file a bug but no answer: https://bugzilla.redhat.com/show_bug.cgi?id=2232838 You didn't really provide any info that would help. Can you get any journal output or the sos file? Is there any indication of what is going wrong? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On Mon, 2023-08-21 at 17:13 +0100, Paul Smith wrote: > On Mon, Aug 21, 2023 at 5:10 PM Patrick O'Callaghan > wrote: > > > > > Are other also experience that with the new kernel: > > > > > > 6.4.10-200.fc38.x86_64 > > > > > > I have already file a bug but no answer: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2232838 > > > > I didn't have any problems, but I updated to 6.4.11 this morning so > > maybe try that. > > Thanks, Patrick: My bad: the problematic kernel is: > > kernel-6.4.11-200.fc38.x86_64 That's the one I'm using now. Haven't seen any issues with it, touch wood. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On Mon, Aug 21, 2023 at 5:10 PM Patrick O'Callaghan wrote: > > > Are other also experience that with the new kernel: > > > > 6.4.10-200.fc38.x86_64 > > > > I have already file a bug but no answer: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2232838 > > I didn't have any problems, but I updated to 6.4.11 this morning so > maybe try that. Thanks, Patrick: My bad: the problematic kernel is: kernel-6.4.11-200.fc38.x86_64 Paul ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Last kernel update leads to emergency mode
On Mon, 2023-08-21 at 16:56 +0100, Paul Smith wrote: > Dear All, > > Are other also experience that with the new kernel: > > 6.4.10-200.fc38.x86_64 > > I have already file a bug but no answer: > > https://bugzilla.redhat.com/show_bug.cgi?id=2232838 > I didn't have any problems, but I updated to 6.4.11 this morning so maybe try that. poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Last kernel update leads to emergency mode
Dear All, Are other also experience that with the new kernel: 6.4.10-200.fc38.x86_64 I have already file a bug but no answer: https://bugzilla.redhat.com/show_bug.cgi?id=2232838 Have a nice day, Paul ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
