-2

I'm not able to see ANY logs on console (even not the "Decompressing Linux... " message).

  1. I enabled any Early Boot prints under Kernel config, at least which I know (see below Kernel configuration)
  2. Tried stopping the Kernel with KDB - by adding kgdbwait at the end of kernel command line arguments in grub
  3. I tried to boot the kernel manually from grub
  4. I tried to add panic() or logs at the function: asmlinkage void __init start_kernel(void) (init/main.c)
  5. Added / Changed / Removed the loglevel=verbose Kernel command line argument (in GRUB)
  6. Remove "quiet" from Kernel command line argument (in GRUB)
  7. Add crashkernel to Kernel command line argument (in GRUB)

My Questions:

1) Is there other thing I can do to get early boot logs ?

2) Is there any additional code I need to add to Kernel debug it ?

3) Is there any other methodology to debug it ?

Binutils: 2.26.1 binutils-2.26.1-1.fc25.src.rpm

GCC: 6.4.1 gcc-6.4.1-1.fc25.src.rpm

Kernel: 3.10.0-514.21.1

GRUB configuration

default=0
timeout=3
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal --timeout=34 serial console

title XIV-System
        root (hd0,0)
        kernel /boot/vmlinuz init=/system/my_init console=tty0 mce=0 i8042.noaux idle=poll scsi_mod.inq_timeout=2 selinux=0 nohpet console=ttyS0,115200 earlyprintk=ttyS0,115200 kgdboc=ttyS0,115200 ro crashkernel=auto

Kernel configuration

- For verbos boot message

CONFIG_X86_VERBOSE_BOOTUP=y

 - For early printk

CONFIG_EARLY_PRINTK=y

CONFIG_EARLY_PRINTK_DBGP=y

 - For KGDB

CONFIG_KGDB_LOW_LEVEL_TRAP=y

CONFIG_KGDB_KDB=y

CONFIG_SERIAL_KGDB_NMI=y

CONFIG_HAVE_ARCH_KGDB=y

CONFIG_KGDB=y

CONFIG_KGDB_SERIAL_CONSOLE=y

CONFIG_KGDB_TESTS=y

 - For KDB

CONFIG_KDB_KEYBOARD=y

CONFIG_KDB_CONTINUE_CATASTROPHIC=0
Dude
  • 17
  • 2
  • Did you try 'cat /var/log/boot.log'? – Tamim Mar 06 '18 at 01:24
  • I can't get the bash prompt, it just freezes. Note: when the machine boots with the kernel (compiled with the old GCC) there is no /var/log/boot.log file under my machine – Dude Mar 06 '18 at 06:58

1 Answers1

0

I was manage to solve the problem only after debug kernel with gdb (the early boot stage), basically I found out that the kernel fails on:

(gdb) bt
#0  early_idt_handler () at arch/x86/kernel/head_64.S:407
#1  0xffff9fffffffffff in ?? ()
#2  0xffffff07ffffffff in ?? ()
#3  0xffffe0ffffffffff in ?? ()
#4  0x00000e0000000000 in ?? ()
#5  0xffffffff81bee8a0 in ?? ()
#6  0xffff880000014560 in ?? ()
#7  0xffffffff819c0120 in early_idt_handler () at arch/x86/kernel/head_64.S:374
#8  0x0000000000000400 in irq_stack_union ()
#9  0xffffffff81bee8a0 in ?? ()
#10 0x000000000000000f in irq_stack_union ()
#11 0x0000000000000000 in ?? ()

from them I looked into the Kernel source tree (for patch related to head_64.S) and applied it. you can find the patch and it's related on:

commit 5f020130d5360e8266e369dc2b5f4e32ec5b05f4 (HEAD -> my_commit)
Author: Andy Lutomirski <luto@kernel.org>
Date:   Fri May 22 16:15:47 2015 -0700
Dude
  • 17
  • 2