Can't boot up with samus 4.8.1 kernel

[unsaved]

For reasons I won't waste your time with, I rebuilt my Pixel. It worked great with the samus kernel that was current on 2016-09-19. I can't get it to boot with the 4.8.1

I've just spent 8 hours repeating builds, trying all sorts of different options (mostly console and video settings), and different sequences, with no success. I can boot on standard Archlinux kernel no problem. But if I choose either the fallback or or primary samus kernel, my system locks up before the first screen fills with boot log messages. Specifically, it freezes with this as the last line displayed: "fb: switching to inteldrmfb from VESA VGA". From demesg when I boot up successfully with non-samus kernel, I see that the next lines should probably be "intel_idle: MWAIT substates: 0x11142120".

I have tried multiple times both with and without the intel-ucode package installed. No difference.

I wanted to try with the samus kernel from back on 9/19, but I don't have it any more. I figured I'd check out your repository and do a checkout operation to go back to the desired commit, but I see no log history for origin/master, nor any other relevant branch that would cover this time. Please advise.

[raphael]

Your best bet to try an older version is to install an older release https://github.com/raphael/linux-samus/releases I'm not sure why you are having these issues, here is are the relevant outputs from dmesg:

❯ dmesg | grep VESA -A3
[    0.424010] fb0: VESA VGA frame buffer device
[    0.424019] intel_idle: MWAIT substates: 0x11142120
[    0.424020] intel_idle: v0.4.1 model 0x3D
[    0.424158] intel_idle: lapic_timer_reliable_states 0xffffffff
--
[    0.424811] fb: switching to inteldrmfb from VESA VGA
[    0.424823] Console: switching to colour dummy device 80x25
[    0.424856] [drm] Replacing VGA console driver
[    0.424926] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).

[unsaved]

Thanks. I'm able to boot with 4.7.6 (source tar labeled 4.7-5?) now. Haven't yet tried any of the samus-specific features yet, but this is progress.

Memory lane. I've avoided building kernels for several years now.

[byxorna]

I also see this exact same behavior. Reverting to 4.7-5 fixes the problem.

[unsaved]

Yes. Everything else works great with 4.7-5 too.

[stefanwiegmann]

same here, i have an encrypted disk and don't get to unlock it. last thing i see is "Loading initial ramdisk"

[DictatorBob]

I was avoiding posting a "me too" since I haven't had time to do any useful debugging but... "me too". I'm using the Arch AUR 4.7.5 package (which is actually kernel 4.7.6-5ph, for whatever reason), and it works flawlessly. The 4.8.1 freezes after loading initial ramdisk. I'll update if I'm able to do a bit of debugging.

[raphael]

Are you using encryption on your boot partition? anything else that may be "special"? it is possible that a flag needs to be enabled but it's hard to guess in the absolute (obviously 4.8 boots fine for me).

[unsaved]

I'm using no encryption. Non-EFI with bios_grub partition (to support GPT btrfs root). Everything else vanilla.

On Mon, Oct 10, 2016 at 12:30 PM, Raphaël Simon notifications@github.com wrote:

Are you using encryption on your boot partition? anything else that may be "special"? it is possible that a flag needs to be enabled but it's hard to guess in the absolute (obviously 4.8 boots fine for me).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/raphael/linux-samus/issues/163#issuecomment-252672091, or mute the thread https://github.com/notifications/unsubscribe-auth/AAgbEgQeSQXcZJj3o6Yeox6LYYTOyrYlks5qymgMgaJpZM4KRns4 .

[byxorna]

I am using encryption on root, but not boot. Root is f2fs with LUKS, boot is ext4.

@raphael what would help narrow down the differences in configurations? Grub entries?

[stefanwiegmann]

don't have my pixel in reach here at work, but I encrypted all, incl. /boot. how can we actually debug? there would be no logs written anywhere, as no disk is present, correct?

[raphael]

One experiment that would help would be to take the config used to build the 4.7 kernel and simply "port it" to 4.8 (via make oldconfig). Rebuild the kernel with that config and see if that works. If it does then it's definitely something I removed that is needed with your configuration. Doing a diff of the configs may point us in the right direction (although I expect a lot of "noise" so it may not be as simple as it sounds).

[nsparks86]

Just tried the latest, and still having the same problems as 4.8. I get up to the splash screen, it loads, then it goes black and I can't switch to TTY1 or any of them. Just a black screen and that's it.

[victrcodes]

I am having the same issue with vanilla Ubuntu encrypted. Stuck on "Loading initial ramdisk". My humble opinion-guess would also be something amiss in the configs, have no idea what, however.

[chrisrossx]

I did a new (disclaimer: first time) install of arch yesterday. No user setup yet, no encryption. Only packages installed was grub, package-query and yaourt.

Right after grub I would get a black screen with a none blinking cursor in top left.

Grub was using graphics mode. I also tried adding the i915 module in mkinitcpio.conf.

I was able to manually install 4.7.6 and get it running.

On Oct 15, 2016 11:52, "V" notifications@github.com wrote:

I am having the same issue with vanilla Ubuntu encrypted. My humble opinion-guess would also be something amiss in the configs, have no idea what, however.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/raphael/linux-samus/issues/163#issuecomment-254003654, or mute the thread https://github.com/notifications/unsubscribe-auth/AHS_LyykXektTxaFW8OCmsaHIq0pA7tyks5q0SDogaJpZM4KRns4 .

[ehegnes]

Like many others, 4.8 won't even load the framebuffer for me -- not with any configuration file I have been able to produce. The display doesn't even flicker as it would when display control is passed from the BIOS/bootloader to the kernel. Not only will it not load the framebuffer, I can not "blindly" log-in and start X11. Perhaps there is a kernel panic before framebuffer loading, perhaps there is some other issue. This problem is difficult to debug without a log of any sort.

@raphael, it may make sense to select a few people for testing new releases and rollback the repo to something stable for general use.

[raphael]

It seems the issue was that the KMS framebuffer helper wasn't compiled in the kernel. The latest release v4.8-3 includes it, please give it a shot.

[chrisrossx]

v4.8-3 works for me, thanks @raphael

[victrcodes]

Thanks. Latest version works for me too, except of headphones, I have raised a new issue about that.

[raphael]

OK I'll close this issue, thanks all for confirming!