Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Kernel hangs immediately after GRUB, does not run...[solved]
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Installing Gentoo
View previous topic :: View next topic  
Author Message
kwesadilo
n00b
n00b


Joined: 12 Jul 2010
Posts: 68
Location: United States

PostPosted: Tue Apr 22, 2014 3:12 am    Post subject: Kernel hangs immediately after GRUB, does not run...[solved] Reply with quote

I am trying to set up a new install with my rootfs on LVM on top of dmcrypt. I am using GRUB and UEFI/GPT. Until yesterday, I thought I wouldn't need an initramfs, but I now know that I do. I generated one with genkernel, reran grub2-mkconfig, and rebooted.

I observe this behavior:

  1. First thing after the UEFI screen, GRUB asks for my LUKS key. I enter it.
  2. The GRUB menu displays, and I select my Gentoo install.
  3. These lines print out on an otherwise black screen:
    Code:
    Loading Linux 3.12.13-gentoo ...
    Loading initial ramdisk ...

  4. The screen flickers once, and the text remains. My NumLock key turns off. Nothing else happens. There is no visible response to keyboard input.
  5. After several minutes of soul-crushing nothingness, I despondently reboot.


I assume (perhaps in error) that the kernel is panicking before it has a chance to print anything out.

Things I have tried that didn't work (as in they had no observable effect):

  • Specify boot=/init or boot=/linuxrc explicitly on the kernel line in GRUB. Apparently boot=/init is the default when an initramfs is specified.
  • Place echo statements throughout /init in my initramfs. None of them printed out. I take it the crash is occurring before the kernel runs /init. I know at least GRUB (if not the kernel) is looking for the initramfs file, because if I spell the initramfs filename wrong, I get an additional message saying it can't be found before
  • Put nomodeset in my kernel command line in case kernel output was being suppressed by an incorrectly specified display.
  • Working on the same logic as above, comment out the load_video command from my GRUB menuentry.
  • Use the "recovery mode" GRUB menuentry. I think it's exactly the same as the regular one, so it's not surprising this didn't do anything.
  • Compress initramfs using GZIP to match what my kernel config says the kernel is using. (genkernel produced an XZ-compressed file.)
  • Use the binary distribution of better-initramfs. I didn't change my kernel parameters for this, so I didn't expect it to boot successfully, but I did expect it to output some kind of message before it failed.


Note that I did my GRUB menuentry edits from within GRUB to avoid rebooting into my live CD and then rebooting back into GRUB for every change.

I'm pretty stumped here. I suppose it could require a combination of the above changes. I run into stuff like this at work, but at work I can attach a JTAG debugger to my board and see what line of code it crashes on. No such luck here.

Here is my disk layout:
Code:
_ SSD
 |_ ESP
 |  |_ /boot/efi
 |
 |_ dmcrypt
    |_ LVM (vgssd-rootfs)
       |_ /
_ HDD
 |_ dmcrypt
   |_ LVM (vghdd-home)
      |_ /home
And my /etc/default/grub:
Code:
# Copyright 1999-2013 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sys-boot/grub/files/grub.default-2,v 1.4 2013/09/21 18:10:55 floppym Exp $
#
# To populate all changes in this file you need to regenerate your
# grub configuration file afterwards:
#     'grub2-mkconfig -o /boot/grub/grub.cfg'
#
# See the grub info page for documentation on possible variables and
# their associated values.

GRUB_DISTRIBUTOR="Gentoo"

GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10

# Append parameters to the linux kernel command line
GRUB_CMDLINE_LINUX="crypt_home=/dev/sda2 dolvm"

# Append parameters to the linux kernel command line for non-recovery entries
#GRUB_CMDLINE_LINUX_DEFAULT=""

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal.
# Note that you can use only modes which your graphic card supports via VBE.
# You can see them in real GRUB with the command `vbeinfo'.
#GRUB_GFXMODE=640x480

# Path to theme spec txt file.
# The starfield is by default provided with use truetype.
# NOTE: when enabling custom theme, ensure you have required font/etc.
#GRUB_THEME="/boot/grub/themes/starfield/theme.txt"

# Background image used on graphical terminal.
# Can be in various bitmap formats.
#GRUB_BACKGROUND="/boot/grub/mybackground.png"

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to kernel
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY=true

GRUB_PRELOAD_MODULES=lvm
GRUB_CRYPTODISK_ENABLE=y
And my /boot/grub.cfg:
Code:
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
insmod lvm
if [ -s $prefix/grubenv ]; then
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
    saved_entry="${chosen}"
    save_env saved_entry
  fi
}

function load_video {
  if [ x$feature_all_video_module = xy ]; then
    insmod all_video
  else
    insmod efi_gop
    insmod efi_uga
    insmod ieee1275_fb
    insmod vbe
    insmod vga
    insmod video_bochs
    insmod video_cirrus
  fi
}

if loadfont unicode ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set lang=en_US
  insmod gettext
fi
terminal_output gfxterm
if sleep --interruptible 0 ; then
  set timeout=10
fi
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/10_linux ###
Finally initrd = initramfs-genkernel-x86_64-3.12.13-gentoo
menuentry 'Gentoo GNU/Linux' --class gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-517b41ec-7cb4-4fcd-8755-b3e5226a7432' {
   load_video
   insmod gzio
   insmod part_gpt
   insmod cryptodisk
   insmod luks
   insmod gcry_rijndael
   insmod gcry_rijndael
   insmod gcry_sha1
   insmod gcry_sha256
   insmod lvm
   insmod ext2
   set root='lvm/vgssd-root'
   if [ x$feature_platform_search_hint = xy ]; then
     search --no-floppy --fs-uuid --set=root --hint='lvm/vgssd-root'  517b41ec-7cb4-4fcd-8755-b3e5226a7432
   else
     search --no-floppy --fs-uuid --set=root 517b41ec-7cb4-4fcd-8755-b3e5226a7432
   fi
   echo   'Loading Linux 3.12.13-gentoo ...'
   linux   /boot/kernel-3.12.13-gentoo root=/dev/mapper/vgssd-root ro crypt_home=/dev/sda2 dolvm
   echo   'Loading initial ramdisk ...'
   initrd   /boot/initramfs-genkernel-x86_64-3.12.13-gentoo
}
submenu 'Advanced options for Gentoo GNU/Linux' $menuentry_id_option 'gnulinux-advanced-517b41ec-7cb4-4fcd-8755-b3e5226a7432' {
   menuentry 'Gentoo GNU/Linux, with Linux 3.12.13-gentoo' --class gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.12.13-gentoo-advanced-517b41ec-7cb4-4fcd-8755-b3e5226a7432' {
      load_video
      insmod gzio
      insmod part_gpt
      insmod cryptodisk
      insmod luks
      insmod gcry_rijndael
      insmod gcry_rijndael
      insmod gcry_sha1
      insmod gcry_sha256
      insmod lvm
      insmod ext2
      set root='lvm/vgssd-root'
      if [ x$feature_platform_search_hint = xy ]; then
        search --no-floppy --fs-uuid --set=root --hint='lvm/vgssd-root'  517b41ec-7cb4-4fcd-8755-b3e5226a7432
      else
        search --no-floppy --fs-uuid --set=root 517b41ec-7cb4-4fcd-8755-b3e5226a7432
      fi
      echo   'Loading Linux 3.12.13-gentoo ...'
      linux   /boot/kernel-3.12.13-gentoo root=/dev/mapper/vgssd-root ro crypt_home=/dev/sda2 dolvm
      echo   'Loading initial ramdisk ...'
      initrd   /boot/initramfs-genkernel-x86_64-3.12.13-gentoo
   }
   menuentry 'Gentoo GNU/Linux, with Linux 3.12.13-gentoo (recovery mode)' --class gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-3.12.13-gentoo-recovery-517b41ec-7cb4-4fcd-8755-b3e5226a7432' {
      load_video
      insmod gzio
      insmod part_gpt
      insmod cryptodisk
      insmod luks
      insmod gcry_rijndael
      insmod gcry_rijndael
      insmod gcry_sha1
      insmod gcry_sha256
      insmod lvm
      insmod ext2
      set root='lvm/vgssd-root'
      if [ x$feature_platform_search_hint = xy ]; then
        search --no-floppy --fs-uuid --set=root --hint='lvm/vgssd-root'  517b41ec-7cb4-4fcd-8755-b3e5226a7432
      else
        search --no-floppy --fs-uuid --set=root 517b41ec-7cb4-4fcd-8755-b3e5226a7432
      fi
      echo   'Loading Linux 3.12.13-gentoo ...'
      linux   /boot/kernel-3.12.13-gentoo root=/dev/mapper/vgssd-root ro single crypt_home=/dev/sda2 dolvm
      echo   'Loading initial ramdisk ...'
      initrd   /boot/initramfs-genkernel-x86_64-3.12.13-gentoo
   }
}

### END /etc/grub.d/10_linux ###

### BEGIN /etc/grub.d/20_linux_xen ###
### END /etc/grub.d/20_linux_xen ###

### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###

### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###

### BEGIN /etc/grub.d/41_custom ###
if [ -f  ${config_directory}/custom.cfg ]; then
  source ${config_directory}/custom.cfg
elif [ -z "${config_directory}" -a -f  $prefix/custom.cfg ]; then
  source $prefix/custom.cfg;
fi
### END /etc/grub.d/41_custom ###
I'm pretty sure I generated my initramfs with
Code:
genkernel --install --lvm --luks install

Thank you in advance for any assistance. I can upload more stuff as warranted.


Last edited by kwesadilo on Fri May 23, 2014 2:04 am; edited 1 time in total
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Tue Apr 22, 2014 8:54 am    Post subject: Reply with quote

kwesadilo ...

I have pretty much the same setup: EFI, lvm volumes within dm-crypt ... though no grub2 and I use better-initramfs (not genkernel).

Before making any suggestions a couple of question, how big is your ESP (EFI System Partition) and did you format this yourself (ie, is it vfat16 or vfat32)? The above sounds like a bug I've also encountered, the cause may be one of two things. The first is your EFI 'bios' and how it treats case (see srs5694's post here ... some do not treat upper/lower case as equivalent (which should be the case with vfat). The second is that the ESP is too small and/or some bios/vfat bug that causes files to go undetected (see srs5694's post above and his comment on my issue here ... though ignore the point about eboot.c which is no longer relevant).

Also having the initramfs go undetected I resorted to including it in kernel via CONFIG_INITRAMFS_SOURCE. As I remember the symptoms were identical to yours ... the kernel would try and load the initramfs but it would hang at that point as (I assume) it wasn't found.

So, you might try using INITRAMFS_SOURCE=/path/to/initramfs/ or /path/to/initramfs.cpio (un-compressed cpio archive) and select 'gzip' for "built-in initramfs compression mode".

Besides this (most likely issue) I can provide further details on using better-initramfs, rEFInd, etc, and further details on how my setup is configured should you want to try these rather than grub2 and genkernel ... but I think the above bug (the specifics of which are admittedly vague) is probably the cause.

best ... khay
Back to top
View user's profile Send private message
kwesadilo
n00b
n00b


Joined: 12 Jul 2010
Posts: 68
Location: United States

PostPosted: Wed Apr 23, 2014 1:54 am    Post subject: Reply with quote

Thanks for your response. It's good to have new stuff to try.

khayyam wrote:
Before making any suggestions a couple of question, how big is your ESP (EFI System Partition) and did you format this yourself (ie, is it vfat16 or vfat32)?

It is 127MB. I formatted it myself as vfat32. Here is how my live CD sees it:
Code:
ubuntu@ubuntu:~$ sudo parted
GNU Parted 2.3
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit MiB
(parted) print                                                         
Model: ATA Samsung SSD 840 (scsi)
Disk /dev/sda: 238475MiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start    End        Size       File system  Name  Flags
 1      1.00MiB  128MiB     127MiB     fat32        ESP   boot
 2      128MiB   238475MiB  238347MiB

(parted) quit                                                             
ubuntu@ubuntu:~$ cat /proc/mounts | grep sda1
/dev/sda1 /mnt/gentoo/boot/efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0
ubuntu@ubuntu:~$ ls -lRh /mnt/gentoo/boot/efi/
/mnt/gentoo/boot/efi/:
total 512
drwxr-xr-x 3 root root 512 Apr 19 05:25 EFI

/mnt/gentoo/boot/efi/EFI:
total 512
drwxr-xr-x 2 root root 512 Apr 20 05:11 gentoo

/mnt/gentoo/boot/efi/EFI/gentoo:
total 220K
-rwxr-xr-x 1 root root 220K Apr 20 05:11 grubx64.efi
As you can see, I seem to be doing OK for space on the ESP. I don't think I can show you that it's FAT32 from the command line, but gparted confirms it.

I labeled my ESP volume "ESP." I remember seeing a tutorial where somebody else labeled theirs "ESI." Is this significant?

khayyam wrote:
The first is your EFI 'bios' and how it treats case (see srs5694's post here ... some do not treat upper/lower case as equivalent (which should be the case with vfat). The second is that the ESP is too small and/or some bios/vfat bug that causes files to go undetected (see srs5694's post above and his comment on my issue here ... though ignore the point about eboot.c which is no longer relevant).

Based on the fact that GRUB is starting, I'm inclined to think that the firmware has at least some ability to play nice with my ESP's filesystem.

Regarding the posts you linked to, I should mention that I'm not using EFI stub or storing the kernel on the ESP. I don't know if you were under that impression.

khayyam wrote:
Also having the initramfs go undetected I resorted to including it in kernel via CONFIG_INITRAMFS_SOURCE. As I remember the symptoms were identical to yours ... the kernel would try and load the initramfs but it would hang at that point as (I assume) it wasn't found.

So, you might try using INITRAMFS_SOURCE=/path/to/initramfs/ or /path/to/initramfs.cpio (un-compressed cpio archive) and select 'gzip' for "built-in initramfs compression mode".

I tried pointing the kernel config at better-initramfs.cpio and adding better-initramfs' LVM/LUKs parameters to the kernel boot line. Booting in this way had no effect on the outcome.

It seems like it's probably not the initramfs, but it's hard to say. I'm not opposed to other bootloaders, although I am most familiar with GRUB. I'd like to have something that will let me encrypt /boot if possible.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Wed Apr 23, 2014 11:51 am    Post subject: Reply with quote

kwesadilo wrote:
Thanks for your response. It's good to have new stuff to try.

kwesadilo ... you're welcome. I'm really not sure what the issue might be but I'm inclined to think its grub, if only because from all accounts it doesn't seem to be finding/loading the kernel. I've never used an encrypted /boot (or grub2 for this purpose) so I'm not sure whats involved. That said, the most obvious thing that might go wrong is configuration and/or something in the kernel is missing that's required to provide grub access to /boot (and so load the kernel/initramfs).

kwesadilo wrote:
khayyam wrote:
Before making any suggestions a couple of question, how big is your ESP (EFI System Partition) and did you format this yourself (ie, is it vfat16 or vfat32)?

It is 127MB. I formatted it myself as vfat32.

OK, 127mb is enough for most purposes, and as you're not using the EFI to store the kernel/initramfs then the issue I'd previously suggested may be the cause probably isn't.

kwesadilo wrote:
Code:
Number  Start    End        Size       File system  Name  Flags
 1      1.00MiB  128MiB     127MiB     fat32        ESP   boot

parted doesn't provide the "code", for an ESP it should be "EF00" ...

Code:
# gdisk -l /dev/sda |awk '/^Num/{print} {if ($6 == "EF00") print}'
Number  Start (sector)    End (sector)  Size       Code  Name
   1              40          409639   200.0 MiB   EF00  EFI System Partition

... but given that grub is loaded this is probably correct.

kwesadilo wrote:
I labeled my ESP volume "ESP." I remember seeing a tutorial where somebody else labeled theirs "ESI." Is this significant?

No, it shouldn't matter, its the 'code' which designates it as an ESP.

kwesadilo wrote:
khayyam wrote:
The first is your EFI 'bios' and how it treats case (see srs5694's post here ... some do not treat upper/lower case as equivalent (which should be the case with vfat). The second is that the ESP is too small and/or some bios/vfat bug that causes files to go undetected (see srs5694's post above and his comment on my issue here [...]

Based on the fact that GRUB is starting, I'm inclined to think that the firmware has at least some ability to play nice with my ESP's filesystem.

Yes, but the specific bug linked to would effect grubs ability to find the kernel/initramfs ... however, as you're not storing anything except the bootloader on the ESP this is irrelevant.

kwesadilo wrote:
Regarding the posts you linked to, I should mention that I'm not using EFI stub or storing the kernel on the ESP. I don't know if you were under that impression.

Yes, I was. I don't think grub2 requires the kernel is an efi_stub, but the issue of where it looks (and what it finds) seems relevant here. You might try loading the kernel/initramfs from the ESP.

kwesadilo wrote:
It seems like it's probably not the initramfs, but it's hard to say. I'm not opposed to other bootloaders, although I am most familiar with GRUB. I'd like to have something that will let me encrypt /boot if possible.

I'm leaning toward thinking that grub is the issue, so I'd suggest not using the encrypted /boot but configuring grub to load the kernel and initramfs (or kernel with the initramfs builtin) from the ESP. Doing so (even if just once) would provide some clue as to what the issue is.

BTW, for better-initramfs I use the following parameters for luks/lvm ...

Code:
luks enc_root=/dev/sda2 lvm root=/dev/mapper/vg-root

You mentioned you'd provided these but didn't mention what, the order is of course important (because the lvm root is within the dm-crypt volume).

Again, I'm completely unfamiliar with grub2 and how it handles encryption, I don't even want to guess as I suspect there is some expectations involved about what the initramfs does. I gave up using (and supporting) grub after some very unhelpful (in fact, unbelievable) discussions with developers on #grub. Note however, encrypting /boot just shifts the infinite regress by one ... yes, the kernel/initramfs can't be tampered with or read, but the bootloader can, and so anyone with the resources to use this as leverage against your encrypted fs can do so using the bootloader ... so I'm not sure anything is gained by doing this.

best ... khay
Back to top
View user's profile Send private message
kwesadilo
n00b
n00b


Joined: 12 Jul 2010
Posts: 68
Location: United States

PostPosted: Thu Apr 24, 2014 11:43 pm    Post subject: Reply with quote

I'll try putting the kernel on my ESP and see what happens. I didn't want my kernel on the encrypted partition to avoid tampering so much as I didn't want to have an entire separate /boot partition just because the bootloader couldn't read the LUKS/LVM partition. I like to keep things simple. Or at least elegant. My setup is arguably somewhat more involved than the naive approach. From a security point of view, I am intrigued by secureboot, but I don't know much about that yet. I might try to get it working at some point, but right now I'm getting kind of sick of not having a computer.

On a unrelated note, I found this post that succinctly breaks down the differences in features/use cases among the different bootloaders available. I was hoping to find another bootloader that can read LUKS/LVM partitions, but apparently there isn't one. The post below that one claims that GRUB2 can't boot off of LUKS/LVM, which has been my experience. That may be the case, since the LVM/LUKS features are extremely under-documented for GRUB2. On the other hand, what is even the point of making the bootloader able to read LUKS/LVM partitions if it can't boot off of them? If that is actually the way it was designed, it feels like a big tease.

Anyway, I'll try putting my kernel on my ESP and let you know how that goes.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Fri Apr 25, 2014 12:20 pm    Post subject: Reply with quote

kwesadilo wrote:
I'll try putting the kernel on my ESP and see what happens. I didn't want my kernel on the encrypted partition to avoid tampering so much as I didn't want to have an entire separate /boot partition just because the bootloader couldn't read the LUKS/LVM partition. I like to keep things simple.

kwesadilo ... I see, but you could do without /boot as you can use, and mount, the ESP as /boot. I'd prefer not to have it vfat but as its a requirement of the EFI standard I may as well use it, and given the amount of disk space asigned, and the fact that the bootloader is only a few MBs, it seems a waste not to.

kwesadilo wrote:
On a unrelated note, I found this post that succinctly breaks down the differences in features/use cases among the different bootloaders available. I was hoping to find another bootloader that can read LUKS/LVM partitions, but apparently there isn't one.

As I mentioned I use rEFInd, and as was pointed out in the above link its technically possible that at some point rEFInd could support this (given that it can load a driver ... if one were written). I don't see any particular advantage though, because an initramfs would still be required to do all the setup, I imagine that combined with secureboot it would offer additional protection from tampering, but as my particular machine doesn't support secureboot its not something that I could impliment were it available.

kwesadilo wrote:
The post below that one claims that GRUB2 can't boot off of LUKS/LVM, which has been my experience. That may be the case, since the LVM/LUKS features are extremely under-documented for GRUB2. On the other hand, what is even the point of making the bootloader able to read LUKS/LVM partitions if it can't boot off of them? If that is actually the way it was designed, it feels like a big tease.

I couldn't really say if that were the case or not, but yeah, it seems odd to have such a feature and it not to be usable. You could ask on #grub (chat.freenode.net) but IME you're likely to be none the wiser.

best ... khay
Back to top
View user's profile Send private message
kwesadilo
n00b
n00b


Joined: 12 Jul 2010
Posts: 68
Location: United States

PostPosted: Sun Apr 27, 2014 1:11 am    Post subject: Reply with quote

I guess I could mount the ESP as /boot, although once I'm up and running I don't necessarily even need to mount /boot. Unfortunately, it seems like that's not going to work right now (see below).

I tried moving my kernel (initramfs included) into the root directory of my ESP and booting from there. It produced the same result. I became suspicious that I might have a bad kernel on my hands, so I downloaded a pre-compiled kernel from the Arch repository (here, I believe) and tried to boot that (specifying my gzipped better-initramfs as initrd in GRUB). Booting from my LUKS/LVM container, it produced the message
Code:
alloc magic is broken at 0xc44a5ee0: 831e5dbf0f440000
before prompting me to press a key to return to the UEFI boot menu. Trying to boot the Arch kernel from my ESP produced the same result.

On the advice of the grub-help mailing list, I tried setting debug=all before the boot command in GRUB. For my Gentoo kernel (in either location), this produced about 32 lines of output before hanging. Here are the last few lines:
Code:
script/script.c:50: malloc 0xc366e120
script/script.c:50: malloc 0xc366e0e0
script/lexer.c:321: token 0 text []
script/script.c:50: malloc 0xc366e260
script/script.c:50: malloc 0xc366e220
script/script.c:65: free 0xc366e220
script/script.c:65: free 0xc366e260
script/script.c:65: free 0xc366e0e0
script/script.c:65: free 0xc366e120
Everything that came before that is of the same form.

When I set debug=all for my Arch kernel (in either location), no additional output was produced.

I don't really have a clue at this point. :(

Edit: I also tried adding the debug and initcalls_debug parameters to my linux boot line in GRUB. In all four of the scenarios described above, this change did not result in any additional output.
Back to top
View user's profile Send private message
kwesadilo
n00b
n00b


Joined: 12 Jul 2010
Posts: 68
Location: United States

PostPosted: Sun May 04, 2014 3:35 am    Post subject: Some progress Reply with quote

OK, after a week of basically not working on this, I made some small amount of progress. I put the hard drive from my old computer in my new computer alongside my new storage devices. The old hard drive has GRUB installed in the MBR, a DOS partition table, and a plain old ext3 root directory (no LUKS or LVM) with a kernel from a few months ago. For whatever reason, my firmware decided this was going to be the new default boot device, so it tried to boot it instead of my LiveCD. It went through GRUB and got a little bit into the kernel before printing a panic message out on the screen. So I have evidence of at least one kernel at least partially booting on this computer. I assume this panic is due to the kernel not having the right drivers, or its built-in initramfs not being suited to my new hardware configuration or something of that nature.

I copied the old computer's kernel into my new computer's /boot and tried booting through my UEFI GRUB executable. I visibly entered the kernel (Penguin icons and console output) and then panicked at the same place I did from the old HDD. Progress! My initial reaction was that my GRUB and LUKS/LVM partition setup must be OK, and it's my kernel that is messed up.

However, out of curiosity, I tried booting my new kernel from the old computer's HDD, expecting that I would get no output as I do with my UEFI GRUB. Instead, the kernel visibly started, and I got a bunch of hardware discovery stuff on the console. Then, the output stopped, my console background changed from black to green, and the computer did not respond to any keyboard input. If I had run this test first, I would have assumed that my kernel was at least sort of OK, and it was my GRUB/LUKS/LVM setup that was broken. So I don't really know what to think now. The last line of console output I get before the crash in this case is
Code:
vgaarb: device added: PCI:0000:01:00.0 decoder=io+mem,owns=io+mem,locks=none

Perhaps it is possible that my old kernel/initramfs combo has some support built in for something related to my boot configuration that my new kernel is missing, even though my old kernel's firmware/partition setup was unlike this one. I may need to start comparing kernel configs, which would probably suggest a new thread, but I'll think about it a little more before I jump ship.

Incidentally, I ran a memory test this afternoon, and it checked out. So I don't think any of my boots are getting messed up by bad memory, although at this point it's hard to confidently rule anything out.
Back to top
View user's profile Send private message
frostschutz
Advocate
Advocate


Joined: 22 Feb 2005
Posts: 2977
Location: Germany

PostPosted: Sun May 04, 2014 5:41 pm    Post subject: Reply with quote

If you end up with a black screen and nothing else, no error messages, I'd say your issue is the kernel configuration / kernel build itself.

I have (almost) the same setup you have (SSD -> MD -> LUKS -> LVM -> root) with a Custom Initramfs. I don't use EFI, good old Grub with a <1MB GPT bios_grub partition.
Back to top
View user's profile Send private message
kwesadilo
n00b
n00b


Joined: 12 Jul 2010
Posts: 68
Location: United States

PostPosted: Mon May 05, 2014 1:40 am    Post subject: Reply with quote

frostschutz wrote:
If you end up with a black screen and nothing else, no error messages, I'd say your issue is the kernel configuration / kernel build itself.
The screen isn't entirely black. The mesages that GRUB prints out while it's running through its commands before boot stay on the screen. How do you go about troubleshooting a kernel config/build issue? Right now I'm looking at the diffs between my old kernel .config and my new kernel .config.

Incidentally, my old kernel (the one that partially boots) is 3.10.25. My new one (the one that hangs immediately) is 3.12.13.
Back to top
View user's profile Send private message
kwesadilo
n00b
n00b


Joined: 12 Jul 2010
Posts: 68
Location: United States

PostPosted: Wed May 07, 2014 2:26 am    Post subject: Reply with quote

Ugh, I'm nearly at my wit's end here. Here are some more things I tried that didn't work:
  • Set console=tty in the boot parameters. The boot parameter docs say that it should have a value in the form of ttyN where N is a number, but my initramfs (at least in its static form) only has /dev/tty. I believe I am using devtmpfs, but I don't know how that informs the setting of this parameter.
  • Set vga=ASK_VGA in the boot parameters, in case it was setting the mode wrong initially. At least I think that's what this does.
  • Do the last two items at the same time.
  • Make sure that the framebuffer console is enabled if the framebuffer driver is. CONFIG_FB is enabled. I also enabled every framebuffer device that I thought there was even a chance that I have. nVidia, nVidia Riva (whatever that is), UVESA, VESA, EFI (the one I think should be in use), and simple framebuffer.
  • Do a clean build of the kernel in case something got corrupted along the way. I didn't really expect this to work, and I wasn't surprised. In general, I'm pretty impressed with the kernel build system.

I'm almost out of bullets. I could try completely removing framebuffer and see if that has any effect. I could try booting my new kernel from my old HDD and debug that until I can get it to come up (or at least get to the initramfs) and then try that kernel on my new SSD again. This has been a pretty harrowing experience so far.
Back to top
View user's profile Send private message
Goverp
Veteran
Veteran


Joined: 07 Mar 2007
Posts: 1972

PostPosted: Wed May 07, 2014 10:28 am    Post subject: Reply with quote

This may be irrelevant, but some recent kernel introduced some new framebuffer support that, to be honest, I didn't understand. Maybe they're related to your problem:
Code:
CONFIG_X86_SYSFB
CONFIG_FB_SIMPLE

_________________
Greybeard
Back to top
View user's profile Send private message
kwesadilo
n00b
n00b


Joined: 12 Jul 2010
Posts: 68
Location: United States

PostPosted: Fri May 23, 2014 2:03 am    Post subject: It's aliiiiiive! Reply with quote

OK, I think I actually solved this back on the 11th, but I didn't get to post until now, because I was still setting stuff up and didn't have a browser installed. I actually still don't, but I booted back into the live CD to wrap this thread up.

I mentioned before that the screen would flicker right before everything went dead, so I figured something was trying do something with the screen, probably framebuffer. On my old BIOS computer, I didn't even need framebuffer to boot, so I figured I'd turn it off and see if that's what was crashing. When I built my kernel, I compiled in a bunch of framebuffer drivers including the EFI one, the X86 one, SimpleFB, VESA, UVESA, both nVidia drivers, and the Intel HD framebuffer driver (I have an onboard graphics adapter I don't plan to use).

So I turned all of those off as well as the framebuffer console. This resulted in no screen flicker but otherwise no change in behavior. I've read that, whereas BIOS has it's own text console without framebuffer, other platforms have no other console and need framebuffer. I would have thought that my x86 EFI would act like a BIOS in this regard, but I guess not. So I enabled just the framebuffer console and the EFI framebuffer driver, and behold, my computer booted!

I tried enabling the other drivers by themselves and alongside the EFI driver, and those experiments resulted in the same flicker and then nothing as before. I conclude that one of the other drivers was attaching to the framebuffer device before the EFI driver and then dying. I think it's kind of messed up that the kernel would choose the wrong driver when the right one was available. This seems a little buggy to me, but who am I to say?

Regarding FB_SIMPLE, the documentation for that variable says that it's a generic framebuffer driver intended to replace all of the platform-specific ones including the EFI one. I have not yet tried to determine whether it works when it is the only driver available. I may investigate at some point in the future.

In any case, I'm going to mark this as solved. Thank you all for your assistance. I wouldn't have been able to do it without you.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Installing Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum