Bug 1394353 - New kernels won't boot on older IBM T30 laptop [NEEDINFO]
Summary: New kernels won't boot on older IBM T30 laptop
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 24
Hardware: i386
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-11 19:27 UTC by David A. De Graaf
Modified: 2017-04-28 17:24 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-04-28 17:24:59 UTC
Type: Bug
Embargoed:
jforbes: needinfo?


Attachments (Terms of Use)

Description David A. De Graaf 2016-11-11 19:27:04 UTC
Description of problem:
kernels newer than -4.7.7-200.fc24.i686 wont boot on IBM T30 laptop

Version-Release number of selected component (if applicable):
kernel-4.7.9-200.fc24.i686

How reproducible:
100%

Steps to Reproduce:
1.  dnf update

2.  get kernel-4.7.9-200.fc24.i686

3.  Try to reboot - fails.

Actual results:  Blinking cursor - forever


Expected results:  Boot new kernel correctly


Additional info:

My trusty old IBM T30 laptop will no longer boot with the latest 
    kernel-4.7.9-200.fc24.i686
    kernel-4.8.4-200.fc24.i686
    kernel-PAE-4.8.4-200.fc24.i686
It will still boot
    kernel-4.7.7-200.fc24.i686

The grub2 menu is displayed, and after selecting the 4.7.7-200 kernel
there's a 2-3 sec delay with blinking cursor, then I'm prompted for
the encryption passphrase for the /home filesystem.  Then the
voluminous messages (from removing the rhgb boot option) scroll forth
and bootup proceeds normally.

However, If I choose any of the newer kernels, the blinking cursor
remains forever; no prompt for the encryption passphrase occurs; the
keyboard is totally non-responsive.  Power cycling is required to
recover.  Obviously, there are no log files or other data...

Things I've tried:
- dnf remove <the "bad" kernel>, and reinstall it.
- Rebuild initramfs-4.8.4-200.fc24.i686.img with dracut.  The new file
  is only one byte bigger, probably due to a different date, and still
  won't boot.
- Added the secret 'dis_ucode_ldr' boot option, as revealed in
  https://www.reddit.com/r/Fedora/comments/4qrl1k/kernel_46_wont_boot_how_can_i_troubleshoot/
  but this seemed aimed at newer IBM laptops, and indeed, had no
  effect on my T30.
- Updated the BIOS.  The T30 has two components:  the BIOS and the EC
  (Embedded Controller).  My BIOS was up to date at version 2.10
  but the EC was v. 1.03, while v. 1.07 was available.
  Sadly, updating to EC v. 1.07 did not alleviate the problem.

Any thoughts, shared experience, commiserations, suggestions?

What can be so different about these newer kernels?

Comment 1 David A. De Graaf 2016-11-12 19:54:45 UTC
This problem has gone away as mysteriously as it arrived.

Today's weekly dnf update brought
   kernel-4.8.6-201.fc24.i686+PAE
   kernel-4.8.6-201.fc24.i686
Both, I am happy to say, boot correctly on my IBM T30 laptop,
unlike the previous -4.8.4-200.fc24.i688 versions.

My thanks to whomever found and fixed this bug.

Comment 2 Justin M. Forbes 2017-04-11 15:00:28 UTC
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 24 kernel bugs.

Fedora 25 has now been rebased to 4.10.9-100.fc24.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26.

If you experience different issues, please open a new bug report for those.

Comment 3 Justin M. Forbes 2017-04-28 17:24:59 UTC
*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the 
relevant data from the latest kernel you are running and any data that might have been requested previously.


Note You need to log in before you can comment on or make changes to this bug.