Boot problems with custom kernel

[alexbw]

I've got this problem with a custom compiled kernel, something I never encountered before since my  use of linux since 1994. I am pretty sure I am overlooking something silly !

 

I have spent hours into coming up with that perfect lean kernel with support for my exotic hardware and removing all the unnecessary cruft. If I boot up a generic kernel, I do end up with a working system.

 

Kernel boots up, manages to mount the root filesystem read-only (mounts read-write if specify rw on kernel CL) and then OpenRC init kicks off but fails to mount filesystems from the /etc/fstab file and /dev/pts, /dev/mqueue etc. I am dropped to the login prompt, I can login and mount the filesystems manually, then it segfaults.

 

I have attached a screenshot that shows the OpenRC init sequence leading up to the login prompt. I am pretty sure, I will be asked for /etc/fstab and .config, but I was hoping if someone has encountered this already and know what could be missing from my .config. I am not on my linux comp right now, will have to do that tonight, if needed.

 

 

Thanks for any help.

[Oleg Vinichenko]

and yes, /etc/fstab, kernel config, partition layout, installation method (gpt, mbr), filesystem, initramfs etc, all details

[alexbw]

That was quick, thanks Oleg ! ;-)

 

OK, so the relevant partitions to my setup are as follows:

/dev/sda: 254G SDD -- GPT

/dev/sda1   EFI
/dev/sda2   Win 8.1


/dev/sdb: 4TB SATA III  -- GPT
/dev/sdb1   Funtoo /
/dev/sdb2   NTFS
/dev/sdb3   NTFS
/dev/sdb4   Funtoo Data
/dev/sdb5 NTFS
.
.   
 /dev/sdb10 NTFS

/dev/sdc: 1TB SATA II -- GPT         --> Holds NTFS Partitions

/etc/fstab contents as follows:

/dev/sdb1                  /                     ext4
/dev/sdb4                  /mnt/data       ext4
/mnt/data/vcache      /var/cache     none                   <---[bind mount]
/mnt/data/vdb            /var/db           none                   <---[bind mount]
/mnt/data/uportage    /usr/portage  none                   <---[bind mount]
/mnt/data/usrc           /usr/src         none                   <---[bind mount]
tmpfs                         /tmp               tmpfs   size=20G

I do not use initramfs, I have tried using better-initrams but to no avail.

 

I had saved a copy of .config on my androind, so I have attached it.

 

Hardware used:

Asus maximus V Extreme (Ivy Bridge MB)

CPU - i7 3770K

RAM - 32G  GSkill TridentX @2400MHz

GPU - GTX 660 Ti - 2xSLI

 

Need more info ? Please ask.

 

config-3.17.2.txt

[Oleg Vinichenko]

yes :) a bootloader used and it's configuration

[alexbw]

Booted using UEFI, rEFInd boot manager which in turn loads grubx64.efi, then on I manually specify the kernel CL as :

linux /boot/vmlinuz-3.17.2 root=/dev/sdb1 rw

Regardless of the boot method, it results in the same. I suspect that my .config is missing a CONFIG_ option that OpenRC depends on, will need a lof of time and effort to figure that out, unless I turn out lucky !

[sputnik]

It's not an absolute verbatim law, but I find often using /dev/sdx in fstab is a loser.  And most distros recommend trying to use uuid or labels.  There's another post on the forum where someone had the same issue and that solved it http://forums.funtoo.org/index.php?/topic/176-boot-update-issue/

[alexbw]

OK, I must confess, I do have UUIDs in my /etc/fstab, but since I am not on my linux comp at this time, I simply used the /dev/sdXnn nomenclature and for clarity.

 

Said that, /dev/sdXnn should work too, as long as your hardware setup doesn't change and you do not have a misbehaving BIOS, UEFI or the boot script/setup fails to cope with it. I do use /dev/sdXn in VirtualBox at work place and I do not have problems with it.

 

You would likely know if the problem is with using UUID/LABEL or /dev/sdXnn by looking at the boot logs.

 

Oh, btw I have double checked the UUIDs and they are correct.

[sputnik]

I don't disagree, it _should work with /dev/sdx, but I have seen it not and as evidenced by that post at least one other Funtoo person has as well.  Actually, I've seen others saying the same on the web, that's how I came to realize it.  Various distros.

I don't claim to know why, but there it is.

But now I read your OP again and see you don't use initramfs and generic kernels do boot, sorry for not paying more attention.  So obviously it's in the config, as you've noted.

Sounds like maybe some more hours making the perfect lean kernel  ;)   I guess you could diff the generic config vs. your new config, probably you've thought of that, but it might be easier to start with the generic, shave off a little at a time, until you are lean.

Seems likely to be something in device drivers>serial ATA and parallel ATA drivers doesn't it?  It's all a good learning experience  :lol: