You are not logged in.
I'm running an x200 with libreboot and had the same problem as op. I fixed it temporarily by downgrading the kernel.
Offline
Just to confirm this most likely affects just Intel Core 2 Duo processors: I also had a booting problem with the latest kernel, running on Intel Core 2 Duo CPU P8600, using systemd-boot. Temporarily fixed by downgrading linux and linux-firmware.
Last edited by GoatWarning (2018-08-27 07:34:41)
Offline
That works!
In terms of this forum, would this count as a workaround or an actual fix?
False alarm, his morning it won't boot. I can only think that I must have booted the fallback by mistake. Apologies.
@MrLinuxFish I am on libreboot too. Does the fallback work for you? What about adding 'nosmp' to the boot params?
Last edited by benoliver999 (2018-08-20 06:12:27)
Offline
Just to confirm this most likely affects just Intel Core 2 Duo processors: I also had a booting problem with the latest kernel, running on Intel Core 2 Duo CPU P8600, using systemd-boot. Temporarily fixed by downgrading linux and linux-firmware.
It's not limited to C2D, it's happening on my Ryzen 1700 PC also.
Linux user #338966
Offline
I have a Pentium E5700, and I also had problems with the new kernal. But will this new kernel update for version 4.18.3 be solved with this new issue?
Offline
Offline
Just updated to linux 4.18.3.arch1-1 and it's seem to work.
Offline
Just wanted to add that I also am getting this same error on my librebooted x200. I updated the system last night and my pc froze after the update and I had to force reboot. After, I wasn't able to boot back up. What I did was getting a USB with arch linux install on. Mounted boot, root partition, chroot, and downgraded linux and linux-api-headers. Also I was unable to downgrade because of tp_smapi required a newer kernel so I also downgraded that. However, at login screen on tty I get SMAPI not supported and tp_smapi init failed errors. Is there any fix to this? I know tp_smapi is important for thinkpads on linux. Other than that I am able to boot up and use i3 with no issues.
Offline
4.18.3-arch1-1-ARCH has not fixed this for me.
@Striykur Did the fallback image not work for you?
Offline
Just updated to linux 4.18.3.arch1-1 and it's seem to work.
I thought it had for me but after a full poweroff I've got the same issue again.
Offline
FWIW I use an intel core 2 duo (actually also an X200) and have had no problem with the new kernel.
Could be related to libreboot then...? There are other machines with the same issue it seems however. That said they don't all sound like the exact same symptoms. OLD quote ignore this, I am tired...
Last edited by benoliver999 (2018-08-20 19:03:05)
Offline
Hi,
An update to #2. I upgraded to kernel 4.18.3 (on my lenovo sl500), boot problem solved.
To summarize, simple upgrade via pacman to version 4.18.3 fixed my issue.
Hope that helps.
Jason
Offline
I don't know if this is just grub remembering what I picked (and it's the fallback image) but FWIW this issue doesn't happen to me after a reboot. It's only when I power off and power back on again.
Offline
To add to this - it seems to work now about 50% of the time. I can't work out what causes it to stall and what doesn't.
This is with modules added to mkinitcipio.conf. The defaunt .conf won't boot at all.
Last edited by benoliver999 (2018-08-20 20:22:34)
Offline
4.18.3-arch1-1-ARCH has not fixed this for me.
@Striykur Did the fallback image not work for you?
You said that fallback image wasn't working for you anymore, plus I have to clue on how to do it. Anyways, I didn't revert to 4.18.3. Here is the specific command I inputted via chroot. I cd into /var/cache/pacman/pkg/ and then entered:
# pacman -U tp_smapi-0.43-32-x86_64.pkg.tar.xz linux-api-headers-4.16.1-1-any.pkg.tar.xz linux-4.17.3-1-x86_64.pkh.tar.xz.
Not sure if it matters but I also reinstalled base and base-devel and # mkinitcpio -p linux beforehand.
Pardon the formatting. This is my first time on the forums.
Offline
@victorj is you move the autodetect hook to the far right does the normal initrd then function?
Yes, this works. I also moved it in front of every other hook except "base" and "udev", the only other position that also works is in front of "fsck".
Besides I found that booting with the default initramfs (with "autodetect" behind "base udev") and with the parameter "acpi=off" works.
Offline
acpi=off boots for me but I can't move the mouse or type.
Offline
To add to this - it seems to work now about 50% of the time. I can't work out what causes it to stall and what doesn't.
This is with modules added to mkinitcipio.conf. The defaunt .conf won't boot at all.
Seems like a race condition with the modules added events happen in one order triggers the issue another order does not.
the acpi=off resolving the issue would indicate that subsystem is at least involved.
reporting-bugs covers information to supply to upstream.
Before reporting it upstream could everyone affected check the journals is there anything record from the failed boots?
Giving upstream the dmesg from a failed boot will almost certainly help upstream locate the cause of the issue.
Offline
I just finished a bunch of tests in which I tried the 4.18.1 and 4.18.3 kernels, the regular initramfs and the fallback image, with and without intel-ucode as a initrd, and with and without nosmp. This was done on my normal system as well as a completely fresh install of arch on a separate partition, which had zero modifications done to it post install other than intel-ucode, rolling back the kernel, and a couple basic tools. My laptop is running a Core 2 Duo P8800 processor. 40 reboots or so later, here are my results.
My normal system:
4.18.1 kernel, regular initramfs, intel-ucode - doesn't work
4.18.1 kernel, regular initramfs, intel-ucode, nosmp - works
4.18.1 kernel, regular initramfs - works
4.18.1 kernel, regular initramfs, nosmp - works
4.18.1 kernel, fallback initramfs, intel-ucode - doesn't work
4.18.1 kernel, fallback initramfs, intel-ucode, nosmp - works
4.18.1 kernel, fallback initramfs - doesn't work
4.18.1 kernel, fallback initramfs, nosmp - works
4.18.3 kernel, regular initramfs, intel-ucode - doesn't work
4.18.3 kernel, regular initramfs, intel-ucode, nosmp - works
4.18.3 kernel, regular initramfs - works
4.18.3 kernel, regular initramfs, nosmp - works
4.18.3 kernel, fallback initramfs, intel-ucode - doesn't work
4.18.3 kernel, fallback initramfs, intel-ucode, nosmp - works
4.18.3 kernel, fallback initramfs - works
4.18.3 kernel, fallback initramfs, nosmp - works
Freshly installed system:
4.18.1 kernel, regular initramfs, intel-ucode - doesn't work
4.18.1 kernel, regular initramfs, intel-ucode, nosmp - works
4.18.1 kernel, regular initramfs - doesn't work
4.18.1 kernel, regular initramfs, nosmp - works
4.18.1 kernel, fallback initramfs, intel-ucode - works
4.18.1 kernel, fallback initramfs, intel-ucode, nosmp - works
4.18.1 kernel, fallback initramfs - doesn't work
4.18.1 kernel, fallback initramfs, nosmp - works
4.18.3 kernel, regular initramfs, intel-ucode - doesn't work
4.18.3 kernel, regular initramfs, intel-ucode, nosmp - works
4.18.3 kernel, regular initramfs - works
4.18.3 kernel, regular initramfs, nosmp - works
4.18.3 kernel, fallback initramfs, intel-ucode - doesn't work
4.18.3 kernel, fallback initramfs, intel-ucode, nosmp - works
4.18.3 kernel, fallback initramfs - doesn't work
4.18.3 kernel, fallback initramfs, nosmp - works
At least for me, it seems that only the "nosmp" parameter consistantly works
Offline
This is interesting, thanks! Were you able to repeat the results each time? This is what I am struggling with...
Offline
I have the same problem, here is what I could find out so far:
I have an ext4 boot partition, the root partition is placed in a logical volume on an encrypted partition ("LVM on LUKS"). The latest working kernel is 4.17.14.arch1-1-x86_64, since 4.18.arch1-1-x86_64 I can't boot with the default initramfs, but with the fallback initramfs. Booting with the default initramfs and without the parameter "quiet" the following is shown:
:: running early hook [udev] starting version 239 :: running early hook [lvm2] :: running hook [udev] :: Triggering uevents...
This is where the system hangs. I would like to boot with the parameter "udev.log-priority=debug" to see what is going on, but the output just fills my screen too fast and I don't know how to scroll up. If this is where I can get further information, someone has to tell me what to do here.
Since booting with the fallback initramfs works, I did this with the parameter "break=postmount" so that I could get the output of
With break=postmount the root filesystem should be mounted at /new_root . If the messages are in dmesg you could redirect the output to a file under /new_root.
Offline
This is interesting, thanks! Were you able to repeat the results each time? This is what I am struggling with...
2 hours and 80 or so reboots later, I have redone my experiment, testing each configuration at least twice, with a full power down and power on (instead of just a reboot/soft reset)
My normal system:
4.18.1 kernel, regular initramfs, intel-ucode - doesn't work, doesn't work
4.18.1 kernel, regular initramfs, intel-ucode, nosmp - works, works
4.18.1 kernel, regular initramfs - works, doesn't work, doesn't work
4.18.1 kernel, regular initramfs, nosmp - works, works
4.18.1 kernel, fallback initramfs, intel-ucode - works, doesn't work, doesn't work
4.18.1 kernel, fallback initramfs, intel-ucode, nosmp - works, works
4.18.1 kernel, fallback initramfs - doesn't work, doesn't work
4.18.1 kernel, fallback initramfs, nosmp - works, works
4.18.3 kernel, regular initramfs, intel-ucode - works, doesn't work, doesn't work
4.18.3 kernel, regular initramfs, intel-ucode, nosmp - works, works
4.18.3 kernel, regular initramfs - works, works
4.18.3 kernel, regular initramfs, nosmp - works, works
4.18.3 kernel, fallback initramfs, intel-ucode - doesn't work, doesn't work
4.18.3 kernel, fallback initramfs, intel-ucode, nosmp - works, works
4.18.3 kernel, fallback initramfs - works, works
4.18.3 kernel, fallback initramfs, nosmp - works, works
Freshly installed system:
4.18.1 kernel, regular initramfs, intel-ucode - works, doesn't work, doesn't work
4.18.1 kernel, regular initramfs, intel-ucode, nosmp - works, works
4.18.1 kernel, regular initramfs - doesn't work, works, doesn't work
4.18.1 kernel, regular initramfs, nosmp - works, works
4.18.1 kernel, fallback initramfs, intel-ucode - doesn't work, doesn't work
4.18.1 kernel, fallback initramfs, intel-ucode, nosmp - works, works
4.18.1 kernel, fallback initramfs - doesn't work, doesn't work, doesn't work
4.18.1 kernel, fallback initramfs, nosmp - works, works
4.18.3 kernel, regular initramfs, intel-ucode - doesn't work, doesn't work
4.18.3 kernel, regular initramfs, intel-ucode, nosmp - works, works
4.18.3 kernel, regular initramfs - doesn't work, works, works, doesn't work, doesn't work, doesn't work
4.18.3 kernel, regular initramfs, nosmp - works, works, works
4.18.3 kernel, fallback initramfs, intel-ucode - doesn't work, works, doesn't work, doesn't work
4.18.3 kernel, fallback initramfs, intel-ucode, nosmp - works, works, works
4.18.3 kernel, fallback initramfs - doesn't work, doesn't work, doesn't work
4.18.3 kernel, fallback initramfs, nosmp - works, works, works
So for my systems, it seems that using nosmp works consistantly, and leaving it out occasionally works, but usually doesn't work
Offline
Holy moly this is nuts, but I really do appreciate it. It's odd your fallback one doesn't work, I haven't had trouble with it at all, otherwise we are getting similar results.
Offline
I also have this issue: can't boot on new kernel (4.18.3) with similar errors.
I done full system update yesterday from kernel 4.17.14 to 4.18.3 and rebooted and everything was fine. I even power off and boot twice and still it was fine (no errors), until today.
Today I can't boot from this new kernel and from fallback (4.17.14) also.
I have Pentium T4500 (dual core) processor, with is somewhat similar to Core 2 Duo.
It looks like it's something bad happening when systemd is booting (some time desynchronisation?).
I manage to boot by adding to grub nosmp parameter.
I try to find errors by journalctl, but didn't find anything suspicious.
Maybe it has something to do with new Intel firmware update?
I will try to install lts kernel. Maybe this will help.
Offline
Yesterday I tried to boot linux-4.18.3 without "quiet" and an additional kernel cmdline boot parameter "earlyprintk=vga".
There was a message about rcu_preempt and some sort of race.
If I'm not mistaken it's related to real-time ... and the RCU subsystem of the kernel (?)
Today I can't reproduce with the exact message I saw yesterday, but thought I post here anyway.
By reproduce I mean with linux-4.18.3 with the normal and the fallback initramfs.
Normal initramfs will not boot and stall without printing additional messages and fallback just boots normally - both without quiet option.
If I may: I thought about using an additional boot parameter to get systemd to print more helpful insight in what's going on taken from:
*) https://www.freedesktop.org/software/sy … -line.html
*) https://www.kernel.org/doc/html/latest/ … eters.html
Maybe "debug", or "--log-level=debug" shows more output. I'll test it and report back, until someone beats me too it.
Offline