Try using another boot manager: this is likely the longstanding issue that has been around since 3.7-8 and there are any number of threads about it...
]]>I use UEFI/gummiboot to boot and the moment I select Arch Linux, the screen goes black and I get no output even with the "extreme" debugging settings from here.
/etc/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="ahci sd_mod ext4"
# 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 fsck"
#
## 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 fsck"
# 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=""
I also use the nvidia blob for my GPU. I'm not sure what would be relevant since I have no output...I've never had booting issues before.
]]>However, this does not explain why the shutdown hook would hang in your case.
]]>----
This is how I came to that conclusion:
This output is not verbose. Try the 'loglevel=7' option instead.
OK, so this is the output for the AMD Laptop and the Toshiba Laptop (no system logs available).
What I noticed is that both stopped at the [shutdown] hook, so the natural idea was to remove it from /etc/mkinitcpio.conf, re-build the initramfs image and see what happened. Once that was done, voilà, I had a booting system.
Why was I using the [shutdown] hook? I'd gotten this error and followed the advice to use the [shutdown] hook, which seemed to sort it out.
Do you think we can class this solved?
]]>NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 465.8G 0 disk
├─sda1 8:1 0 1.5G 0 part
├─sda2 8:2 0 226G 0 part
├─sda3 8:3 0 15.7G 0 part
├─sda4 8:4 0 1K 0 part
├─sda5 8:5 0 141.3G 0 part
├─sda6 8:6 0 250M 0 part /boot
└─sda7 8:7 0 81G 0 part
└─Work 254:0 0 81G 0 crypt
├─Work-lvolroot 254:1 0 30G 0 lvm /
└─Work-lvolhome 254:2 0 51G 0 lvm /home
sr0 11:0 1 1024M 0 rom
And before you ask, there were no logs from this laptop either.
]]>lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 55,9G 0 disk
└─sda1 8:1 0 55,9G 0 part /
sdb 8:16 0 298,1G 0 disk
└─sdb1 8:17 0 298,1G 0 part /run/media/federico/DATA
But i guess it is related to ati radeon graphic (hd5650 here). Are you an ati user too?
It seems it got stuck *sometimes*, but sometimes it doesn't.
It can be related to this https://mailman.archlinux.org/pipermail … 35736.html . But i haven't got a kernel panic, it only hangs instead of booting initrd.
EDIT: i'm writing from 3.14.0-1-ARCH
EDIT2: possibily something related to dpm changes? Just my 2cents here.
]]>:: running early hook [udev]
:: running early hook [lvm2]
:: running hook [udev]
:: Triggering events
A password is required to access the Storage volume:
Enter passphrase for /dev/sda2:
:: performing fsck on '/dev/mapper/Storage-lrootvol'
ArchRoot: clean, 371370/1966080 files, 2545215/7864320 blocks
:: mounting '/dev/mapper/Storage-lrootvol' on real root
:: running cleanup hook [shutdown]
Note the above is with the verbose flag on and typed out from a camera photo. Probably due to my partition layout (see below), there are no journalctl logs (it appears not be able to get as far as mounting my /var volume...):
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 199M 0 part /boot
├─sda2 8:2 0 634.4G 0 part
│ └─Storage 254:0 0 634.4G 0 crypt
│ ├─Storage-lrootvol 254:1 0 30G 0 lvm /
│ ├─Storage-lvarvol 254:2 0 10G 0 lvm /var
│ ├─Storage-lhomevol 254:3 0 300G 0 lvm /home
│ └─Storage-lsteamvol 254:4 0 100G 0 lvm /home/steam
├─sda3 8:3 0 293G 0 part
└─sda4 8:4 0 4G 0 part
sr0 11:0 1 1024M 0 rom
Downgrading back to 3.13.7/8 results in a normal boot. Any ideas?
This is with an AMD 3305M APU with AMD Radeon 6480G graphics, which we will call AMD Laptop.
]]>