• Kernel 4.18: Boot only possible with GRUB Fallback


    After updating to the new kernel boot stops at ‘starting version 239’. With kernel 4.18.3 booting worked once.
    Now I am looking for the difference between the normal boot and the fallback. Maybe the reason lies in the automatic recognition of the necessary hooks (in fallback mode).

    So I looked first in /etc/mkinitcpio.conf. But following looks like OK for me.
    HOOKS="base udev autodetect modconf block keyboard keymap resume filesystems fsck"
    Anybody have any ideas?

  • I don’t if it is the solution, but I also had the same problem with GDM and LightDM webkit2 greeter (Antergos) I’ve switched to slick-greeter and the problem vanished.
    My KDE machine with SDDM doesn’t have that problem either.

  • @bryanpwo
    Yes, this problem I also had. But in this case I found a record in journalctl -b.
    Now booting stops before the journal starts.

  • @sinci
    Again I didn’t investigate it further after the greeter switch. My solution was just a gut feeling, since the path to SDDM went without flaws.

  • @sinci
    That may be a regression of kernel 4.18. Maybe future updates take care of it.

    But meanwhile you might want to use the LTS kernel (linux-lts) instead of linux.

    sudo pacman -S linux-lts
    sudp pacman -S linux-lts-headers  # if needed
    

    You could even reinstall the default kernel:

    sudo pacman -S linux
    

    that might help or not, but shouldn’t hurt anyway.

  • A typo above, sudo instead of sudp… :)

  • @sinci said in Kernel 4.18: Boot only possible with GRUB Fallback:

    Now I am looking for the difference between the normal boot and the fallback

    Hello!
    This usually indicates a problem creating initramfs when upgrading a new kernel version.
    I believe booting in fallback and running sudo mkinicpio -P and then reboot should do the trick.

  • No problem at all here, kernel 4.18.4-arch1-1

  • BTW, I have

    HOOKS=(base udev autodetect modconf block filesystems keyboard fsck)
    

    in /etc/mkinitcpio.conf

  • @all - thanks for support

    @fernandomaroto
    I tried it without typo sudo mkinitcpio -P, but no success

    @manuel
    I tried also your hooks, nevertheless no success

    But I waited longer during booting and got some more information. But doesn’t look useful.
    Starting version 239
    INFO: rcu_preempt detected stalls on CPUs/tasks:
    :
    :
    RCU grace-period kthread stack dump:
    INFO: rcu_shed detected stalls on CPUs/tasks:
    :
    :
    RCU grace-period kthread stack dump:
    INFO: task kworker/1:0:23 blocked for more than 120 seconds.
    Not tainted 4.18.3-arch1-1-ARCH #1
    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disable this message.

    The last three lines came more often.

  • I always had the following warnings, but never bothered to follow them.

    sudo mkinitcpio -P
    ==> Building image from preset: /etc/mkinitcpio.d/linux-lts.preset: 'default'
      -> -k /boot/vmlinuz-linux-lts -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-lts.img
    ==> Starting build: 4.14.65-1-lts
      -> Running build hook: [base]
      -> Running build hook: [udev]
      -> Running build hook: [autodetect]
      -> Running build hook: [modconf]
      -> Running build hook: [block]
      -> Running build hook: [filesystems]
      -> Running build hook: [keyboard]
      -> Running build hook: [fsck]
      -> Running build hook: [keymap]
      -> Running build hook: [resume]
    ==> Generating module dependencies
    ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-lts.img
    ==> Image generation successful
    ==> Building image from preset: /etc/mkinitcpio.d/linux-lts.preset: 'fallback'
      -> -k /boot/vmlinuz-linux-lts -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-lts-fallback.img -S autodetect
    ==> Starting build: 4.14.65-1-lts
      -> Running build hook: [base]
      -> Running build hook: [udev]
      -> Running build hook: [modconf]
      -> Running build hook: [block]
    ==> WARNING: Possibly missing firmware for module: wd719x
    ==> WARNING: Possibly missing firmware for module: aic94xx
      -> Running build hook: [filesystems]
      -> Running build hook: [keyboard]
      -> Running build hook: [fsck]
      -> Running build hook: [keymap]
      -> Running build hook: [resume]
    ==> Generating module dependencies
    ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-lts-fallback.img
    ==> Image generation successful
    ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
      -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
    ==> Starting build: 4.18.3-arch1-1-ARCH
      -> Running build hook: [base]
      -> Running build hook: [udev]
      -> Running build hook: [autodetect]
      -> Running build hook: [modconf]
      -> Running build hook: [block]
      -> Running build hook: [filesystems]
      -> Running build hook: [keyboard]
      -> Running build hook: [fsck]
      -> Running build hook: [keymap]
      -> Running build hook: [resume]
    ==> Generating module dependencies
    ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img
    ==> Image generation successful
    ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
      -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
    ==> Starting build: 4.18.3-arch1-1-ARCH
      -> Running build hook: [base]
      -> Running build hook: [udev]
      -> Running build hook: [modconf]
      -> Running build hook: [block]
    ==> WARNING: Possibly missing firmware for module: wd719x
    ==> WARNING: Possibly missing firmware for module: aic94xx
      -> Running build hook: [filesystems]
      -> Running build hook: [keyboard]
      -> Running build hook: [fsck]
      -> Running build hook: [keymap]
      -> Running build hook: [resume]
    ==> Generating module dependencies
    ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-fallback.img
    ==> Image generation successful
    
  • @manuel said

    That may be a regression of kernel 4.18. Maybe future updates take care of it.

    But meanwhile you might want to use the LTS kernel (linux-lts) instead of linux.

    sudo pacman -S linux-lts
    sudp pacman -S linux-lts-headers  # if needed
    

    Could not agree more with this. On one of my machines, 4.18-1 kernel presented me with the same issue. I had to use the LTS kernel till 4.18-3 fixed that.
    Cheers (and sorry for being a little absent lately).

  • In GRUB I can also choose lts, it is installed. But what’s wrong with 3.18.3 fallback?
    Can I not manipulate the GRUB? So that fallback becomes standard?

  • Why would one want to fall back, especially on a rolling release distro?
    Besides, the LTS kernel by no means is any inferior to the standard one. It just is a little conservative. In practice, it has saved my @ss quite a few times till there was a fix to restore issues (which by the way was within a relatively short time).

  • Maybe I have the wrong idea about fallback. I have my info from
    https://unix.stackexchange.com/questions/45475/what-is-arch-fallback-in-arch-boot-menu#45488

    The fallback image utilizes the same configuration file as the default image, except the autodetect hook is skipped during creation, thus including a full range of modules. The autodetect hook detects required modules and tailors the image for specific hardware, shrinking the initramfs.

  • I’ve read this topic with interest and most of it I understand. One question remains with me, though: Can anyone explain why I had this problem also on my XFCE set up and it was solved by switching from LightDm webkit2-greeter to LightDm slick-greeter and on my KDE set up with SDDM the problem wasn’t there at all?
    In my mind something got screwed up on the way to start up with one of those DM’s (GDM had the same result btw)

  • @bryanpwo I have read your post with interest. In practice how to switch from LightDm webkit2-greeter to LightDm slick-greeter?

  • Got also 4.18.4-arch1-1 today, still same problem. So I will check once more: “What is Arch Fallback in Arch boot menu?”

  • @anarch said in Kernel 4.18: Boot only possible with GRUB Fallback:

    Why would one want to fall back, especially on a rolling release distro?

    I don’t understand this! What is the meaning? Fallback is only a different way to boot, isn’t it?

  • I checked /var/log/pacman.log once more. Fallback is using following hooks.

    [2018-08-23 09:36] [ALPM-SCRIPTLET]   -> Running build hook: [base]
    [2018-08-23 09:36] [ALPM-SCRIPTLET]   -> Running build hook: [udev]
    [2018-08-23 09:36] [ALPM-SCRIPTLET]   -> Running build hook: [modconf]
    [2018-08-23 09:36] [ALPM-SCRIPTLET]   -> Running build hook: [block]
    [2018-08-23 09:36] [ALPM-SCRIPTLET]   -> Running build hook: [filesystems]
    [2018-08-23 09:36] [ALPM-SCRIPTLET]   -> Running build hook: [keyboard]
    [2018-08-23 09:36] [ALPM-SCRIPTLET]   -> Running build hook: [fsck]
    [2018-08-23 09:36] [ALPM-SCRIPTLET]   -> Running build hook: [keymap]
    [2018-08-23 09:36] [ALPM-SCRIPTLET]   -> Running build hook: [resume]
    

    Running build hook: [autodetect] is missed. So the only difference between both kinds of booting is
    normal booting use hook autodect
    fallback DOESN’T use hook autodect

    If I remove autodetect in /etc/mkinitcpio.conf and run sudo mkinitcpio -P I can boot normal. But what are the consequences? The next step is to find out what the hook autodetect does exactly.

    Sure, it’s easier to use lts-kernel, but so I can learn about the system.

kernel148 Posts 29Views 2365
Log in to reply
Bloom Email Optin Plugin

Looks like your connection to Antergos Community Forum was lost, please wait while we try to reconnect.