[SOLVED] Linux 3.14 boot error

nierro · 2014-04-11 07:29:00

Hi!
Since i upgraded to 3.14 (i'm on testing, so a week or so), i encountered this problem.
My system will start only with the fallback initramfs, or well, to be honest *sometimes* it still boots with the normal grub entry.
Iit only hangs after i press the grub entry, but the screen is not black (as others reported), it is grey (just like X is starting), but there is no hdd/cpu activity.
I don't know what are the differences between fallback and normal menu entry. Initially i thought about a radeon DPM problem (ati hd5650 here), but if the other initramfs is starting, i guess it isn't the case.
So...here is /default/grub:

GRUB_DEFAULT=0
GRUB_TIMEOUT=1
GRUB_DISTRIBUTOR="Arch"
GRUB_CMDLINE_LINUX_DEFAULT="quiet fastboot raid=noautodetect libahci.ignore_sss=1 loglevel=1 pcie_aspm=force ipv6.disable=1 logo.nologo nmi_watchdog=0 radeon.agpmode=8 acpi_osi=Linux acpi_backlight=vendor"
GRUB_CMDLINE_LINUX=""

# Preload both GPT and MBR modules so that they are not missed
GRUB_PRELOAD_MODULES="part_gpt part_msdos"

I already tried removing acpi.osi and acpi_backlight, with no effect.

du -h /boot/*
8,0M	/boot/initramfs-linux-fallback.img
8,0M	/boot/initramfs-linux.img
3,7M	/boot/vmlinuz-linux

Last thing: when I'm able to start the normal initramfs, something like "decoding failed, corrupted image" is printed just before starting X, but then there are no effects. It doesn't happen with the fallback image.
Already tried to "mkinitcpio -p linux" several times.

So...any help will be appreciate

EDIT: here is the error i said above:

[  +0,027078] Initramfs unpacking failed: data corrupted

And here is mkinitcpio.conf

# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES="piix ide_disk reiserfs"
MODULES="radeon ext4 ahci sd_mod"

# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image.  This is run last, so it may be used to
# override the actual binaries included by a given hook
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES=""

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way.  This is useful for config files.
FILES=""

# HOOKS
# This is the most important setting in this file.  The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added.  Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
##   This setup specifies all modules in the MODULES setting above.
##   No raid, lvm2, or encrypted root is needed.
#    HOOKS="base"
#
##   This setup will autodetect all modules for your system and should
##   work as a sane default
#    HOOKS="base udev autodetect block filesystems"
#
##   This setup will generate a 'full' image which supports most systems.
##   No autodetection is done.
#    HOOKS="base udev block filesystems"
#
##   This setup assembles a pata mdadm array with an encrypted root FS.
##   Note: See 'mkinitcpio -H mdadm' for more information on raid devices.
#    HOOKS="base udev block mdadm encrypt filesystems"
#
##   This setup loads an lvm2 volume group on a usb device.
#    HOOKS="base udev block lvm2 filesystems"
#
##   NOTE: If you have /usr on a separate partition, you MUST include the
#    usr, fsck and shutdown hooks.
HOOKS="systemd"

# COMPRESSION
# Use this to compress the initramfs image. By default, gzip compression
# is used. Use 'cat' to create an uncompressed image.
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"
COMPRESSION="lz4"

# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=""

Last edited by nierro (2014-04-11 15:01:08)

jgmdev · 2014-04-11 14:09:28

I'm having same issue, in my case the normal boot option starts correctly, I can see first messages until the system resets the resolution. When the system resets the resolution the scree stays black/gray but I see hard drive is still booting and while I do not see it I know gdm seems to load properly, so I press ctrl + alt + f2 still screen is black/gray but then I can ctrl + alt + del to restart the system, so it has to be something graphics related.

I have a radeon hd 6670 and as I posted here https://bbs.archlinux.org/viewtopic.php?id=179829 I fixed it by setting GRUB_GFXPAYLOAD_LINUX to "text" instead of "keep" and regenerating grub.cfg

In any case other people reported similar issues here https://bugs.archlinux.org/task/39795 as another guy on my post reported same issue with intel gpu but in his case it seems GRUB_GFXPAYLOAD_LINUX=text didn't did the trick. So there gotta be something in this new kernel that is causing graphic issues/corruptions.

jcd · 2014-04-11 14:27:20

jgmdev wrote:

I'm having same issue, in my case the normal boot option starts correctly, I can see first messages until the system resets the resolution. When the system resets the resolution the scree stays black/gray but I see hard drive is still booting and while I do not see it I know gdm seems to load properly, so I press ctrl + alt + f2 still screen is black/gray but then I can ctrl + alt + del to restart the system, so it has to be something graphics related.
I have a radeon hd 6670 and as I posted here https://bbs.archlinux.org/viewtopic.php?id=179829 I fixed it by setting GRUB_GFXPAYLOAD_LINUX to "text" instead of "keep" and regenerating grub.cfg
In any case other people reported similar issues here https://bugs.archlinux.org/task/39795 as another guy on my post reported same issue with intel gpu but in his case it seems GRUB_GFXPAYLOAD_LINUX=text didn't did the trick. So there gotta be something in this new kernel that is causing graphic issues/corruptions.

having a similar problem, in my case the screen flickered wildly after the system resets the resolution.
gpu is: ATI RADEON HD 6570

in my case, i just downgraded the kernel to linux-3.13.8-1-x86_64.pkg.tar.xz before trying any GRUB tricks, and i think i will stay here until i have time to try anything else.

==EDIT==

Today i had some time to play around. After trying the GRUB_GFXPAYLOAD_LINUX=text, it worked for me too

Last edited by jcd (2014-04-14 19:43:46)

jgmdev · 2014-04-11 14:37:31

I just disabled the quite kernel parameter and noticed that the resolution issue happens when the Virtual Console is being setup

WonderWoofy · 2014-04-11 14:43:58

@nierro, I see you have attempted to strip down the initramfs. Now that you have moved to using systemd in the initramfs, this is actually pretty useless. At the point that systemd or udev is pulled into the mix, you are really not saving much (if anything) in the initramfs size. But while it may take a bit longer for it to actually decompress and load the initramfs due to its size, I think that this is often negated by the fact that systemd is quite fast.

Try with the standard mkinitcpio.conf and see if things improve.

MODULES="radeon"
BINARIES=""
FILES=""
HOOKS="systemd autodetect modconf keyboard block filesystems fsck"
COMPRESSION="cat"

Typically the use of compression in general slows things down. So if it is speed you are after, then a sequentially written and non-compressed initramfs is what you want. But of course that assumes you have enough space in /boot to handle the larger size of the initramfs and its fallback.

nierro · 2014-04-11 14:51:44

@WonderWoofy: thanks for your hints
I use systemd because it is faster...well on a ssd it really doesn't matter, last boot was 3.7'' with X starting a kde session (i use xlogin from aur), i'll see if no compressed image can improve that!

Meanwhile, i found other strange things: 1) it hangs after it prints "loading initial initramfs"; so just before KMS changes resolution.
2) It seems it just a cold start issue. Rebooting will always work flawlessly (obviously from a fallback initramfs).
I'll try with a "more standard" mkinitcpio, and report back.

nierro · 2014-04-11 14:57:19

Well, just removing lz4 as compression method seems to have fixed...at least i could cold boot with normal initramfs (not fallback).
@WonderWoofy it is as fast as lz4 (3.6'')
Btw it seems really strange that was the problem, because i'm using lz4 also on my netbook, with intel graphics, and i haven't got any problem. So i think it is not a fix. I'll try to boot again a couple of times...

Last thing: i cannot change vt and reboot with ctrl-alt-del. So it is not a "black screen after kernel is loaded" issue.

EDIT: other 2 boots went fine...well it seems kind of fixed, don't know how. I'll mark the thread closed, may be i'll need to open it again.

Thanks to everyone!

Last edited by nierro (2014-04-11 15:00:52)

WonderWoofy · 2014-04-11 15:10:16

Yeah, I am hesitant to say that lz4 is really the issue here. I have lz4 set on my laptop and one of my other computers as well, and it works just fine. I know that the lz4 kernel implementation is not the same as the lz4 utility, but this difference should by resolved by using the legacy format (which mkinitcpio does automatically).

In reality, it is probably not the best idea to use lz4 in general, as it's support is new-ish and not incredibly well tested. But I use it because I like to live on the edge.

My fallback is a plain old gzip format though. I use btrfs, so I like to have all the btrfs binaries in the fallback just in case. In order to do this, I have to have the configs in /etc/mkinitcpio.d point to two different mkinitcpio.conf's. The main one uses /etc/mkinitcpio.conf and the other uses /etc/mkinitcpio-fallback.conf.

# mkinitcpio preset file for the 'linux' package

#ALL_config="/etc/mkinitcpio.conf"
ALL_kver="/boot/vmlinuz-linux"

PRESETS=('default' 'fallback')

default_config="/etc/mkinitcpio.conf"
default_image="/boot/initramfs-linux.img"
#default_options=""

fallback_config="/etc/mkinitcpio-fallback.conf"
fallback_image="/boot/initramfs-linux-fallback.img"
fallback_options="-S autodetect"

By doing that I can make them as wondefully different as I want. In fact the fallback also still uses base and udev instead of systemd, so that if I boot with 'break=premount' to fix the filesystem I still have a minimal filesystem to work from, and the udev module is well tested and has been in use with Arch for a loooooong time.

nierro · 2014-04-11 15:14:29

Yes you had a great idea
But it is as easy as chrooting from a livecd and rebuild an initramfs, if something went wrong! Eheh!
Btw I'm curious to check if the issue will present again.

WonderWoofy · 2014-04-11 15:22:56

My issue is moreso that I want to have the latest btrfs-progs in the fallback. So if I rely on the archiso for those tools, I am stuck with the current stable version. In the initramfs I put the btrfs-progs from David Serba's integration branch, which often have all kinds of wonderful fixes and features that the stable version doesn't have.

But I also have a small partition at the end of one of my SSDs that has the archiso as well. So I can boot that with grub's loopback support as well. So I still do have the ability to fix it through that as well.

In any case, this is veering pretty far OT. Sorry about that.

Edit: Oh and BTW, since you don't use the autodetect hook in your mkinitcpio.conf, the two initramfs' should be the same. You can always check out the contents of the initramfs with lsinitcpio, which is provided by the mkinitcpio package.

Last edited by WonderWoofy (2014-04-11 15:24:13)

nierro · 2014-04-11 15:40:37

In fact their dimension is the same (as provided in first post).
And lsinitcpio confirmed that now. So...i start to guess it is a grub issue...or whatelse? I really don't know...

WonderWoofy · 2014-04-11 23:11:28

At this point, I haven't a clue. Sorry.

Edit: You might just try to use one of the other compression methods and see if they prove more reliable. I have found that both gzip and lzo provide decent compression levels with pretty good speeds. Or you can just stick with cat...

Last edited by WonderWoofy (2014-04-11 23:12:36)

nierro · 2014-04-12 13:44:06

I'm still with "cat" and did not encountered any problem since i made the switch.
Still asking myself "How??", but...it's ok

WonderWoofy · 2014-04-12 16:29:09

Okay, well as long as it works, then great!

I would still recommend moving away from your (attempted) strip down of mkinitcpio. With systemd in the initramfs there isn't much point to it. It is particularly a good idea to at least have the fsck hook in the initramfs. That way, it can do it from a unmounted filesystem rather that a read-only situation. The default in Arch these days is to have grub automatically stick 'rw' on the kernel command line, which causes systemd to skip the systemd-fsck-root.service. Thus your rootfs is never being checked for consistency.

Arch Linux

#1 2014-04-11 07:29:00

[SOLVED] Linux 3.14 boot error

#2 2014-04-11 14:09:28

Re: [SOLVED] Linux 3.14 boot error

#3 2014-04-11 14:27:20

Re: [SOLVED] Linux 3.14 boot error

#4 2014-04-11 14:37:31

Re: [SOLVED] Linux 3.14 boot error

#5 2014-04-11 14:43:58

Re: [SOLVED] Linux 3.14 boot error

#6 2014-04-11 14:51:44

Re: [SOLVED] Linux 3.14 boot error

#7 2014-04-11 14:57:19

Re: [SOLVED] Linux 3.14 boot error

#8 2014-04-11 15:10:16

Re: [SOLVED] Linux 3.14 boot error

#9 2014-04-11 15:14:29

Re: [SOLVED] Linux 3.14 boot error

#10 2014-04-11 15:22:56

Re: [SOLVED] Linux 3.14 boot error

#11 2014-04-11 15:40:37

Re: [SOLVED] Linux 3.14 boot error

#12 2014-04-11 23:11:28

Re: [SOLVED] Linux 3.14 boot error

#13 2014-04-12 13:44:06

Re: [SOLVED] Linux 3.14 boot error

#14 2014-04-12 16:29:09

Re: [SOLVED] Linux 3.14 boot error

Board footer