LinuxQuestions.org - [SOLVED] Slackware64-14.1 multlib AM2 to X99 upgrade generic kernel + initrd fails to load

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Slackware64-14.1 multlib AM2 to X99 upgrade generic kernel + initrd fails to load (https://www.linuxquestions.org/questions/slackware-14/slackware64-14-1-multlib-am2-to-x99-upgrade-generic-kernel-initrd-fails-to-load-4175552092/)

Slackware64-14.1 multlib AM2 to X99 upgrade generic kernel + initrd fails to load

I recently swapped out my old AMD64 X2 AM2 motherboard for a shiny new i7-5820K MSI X99S system (new case, mobo, CPU, DDR4 memory), with drives and GPU recycled. After the swap, booting from the huge kernel works fine, but the initrd.gz for generic will not load:

This is slowly driving me nuts as I haven't had any initrd issues in years. This happens with the SATA controller set to IDE or AHCI. Essentially, all I've ever needed (AMD or intel, desktop, laptop) is just the file system of the /boot. All use standard BIOS (lilo), one laptop uses UEFI (elilo, secure boot off) , and this x99 mobo is set to LEGACY+UEFI (lilo, secure boot is off). Again, I am posting this from the new box after booting the huge-3.10.17 kernel. So, why doesn't kernel-generic work?

The only difference between this system and and 4 others (laptops, desktops with 14.1 and current) is that the bootable Slackware partition is on the second sata drive. Is there a module needed to mount /boot that I am missing? Both AHCI and PATA modules are compiled into the generic kernel as far as I can tell.

Code:

mkinitrd -c -k 3.10.17 -m ext4 -f ext4 -r /dev/sdb1

Code:

/dev/sda1        /win7            ntfs-3g    fmask=111,dmask=000 0  0

/dev/sda2        /video          ext4        defaults        1  2



/dev/sdb1        /                ext4        defaults        1  1

/dev/sdb2        /home            ext4        defaults        1  2

/dev/sdb3        /data            ext4        defaults        1  2

/dev/sdb4        swap            swap        defaults        0  0



/dev/sdc1        /data2          ext4        defaults        1  2

Code:

# Start LILO global section

boot = /dev/sda

lba32

#compact        # faster, but won't work on all systems.



  bitmap = /boot/slack.bmp

  bmp-colors = 255,0,255,0,255,0

  bmp-table = 60,6,1,16

  bmp-timer = 65,27,0,255



# Append any additional kernel parameters:



append=" vt.default_utf8=0 raid=noautodetect"

prompt

timeout = 50



#vga = normal

#vga = ask

vga=791

# ramdisk = 0    # paranoia setting

# End LILO global section



# Linux bootable partition config begins

image = /boot/vmlinuz-generic-3.10.17

  initrd = /boot/initrd.gz

  root = /dev/sdb1

  label = Slackware 

  read-only

image = /boot/vmlinuz

  root = /dev/sdb1

  label = Slackware_safe

  read-only

# Linux bootable partition config ends

# Windows bootable partition config begins

other = /dev/sda1

  label = Windows7

  table = /dev/sda

# Windows bootable partition config ends

I've surfed LQ and elsewhere, but the suggestions did not help, such as "raid=noautodetect" or "-m ahci:ext4", "rootdelay=10" and I have updated the MSi x99 mobo BIOS. Attached is a screenshot from an iPhone video the boot up process. Its a bit hard to see, but it shows the error just before the kernel panic

Code:

...

RAMDISK: Couldn't find valid RAM diskimage starting at 0

...

This is typical if one forgets to run lilo after creating or updating the initrd - which I do often, hence the "Slackware_safe" entry! So what do you suggest (besides just running kernel-huge which is not an option)? What paramters are missing in initrd? Do I need to use elilo? Upgrade to current (not really an option at this time)?

Thanks.

I am envious :)
According to 'man lilo.conf':

Quote:

On newer systems you need an unique ID for the boot device.

Have you tried using "boot = /dev/disk/by-id/..."?

Quote:

Originally Posted by allend (Post 5413024)

I am envious :)

I splurged...and got tired of waiting on AMD, as well as wanting a CPU without integrated GPU.

Quote:

According to 'man lilo.conf':

Have you tried using "boot = /dev/disk/by-id/..."?

No, I have not. However, that does not explain why the second stanza works to boot kernel-generic. LILO is obviously finding the correct boot device as well as root device, just not initrd=/boot/initrd.gz.

Have you rebuilt the initramfs image? Doesn't seem like you would need to, but if you haven't yet, it might be worth a try.

You should upgrade to -current since 14.1 predates X99 by about a year.

If the initrd problem remains, it is not difficult to compile a custom kernel that doesn't require an initrd. I do that on all of my machines.
Ed

Quote:

Originally Posted by j_v (Post 5413046)

Have you rebuilt the initramfs image? Doesn't seem like you would need to, but if you haven't yet, it might be worth a try.

Yes, numerous times, see OP.

Quote:

Originally Posted by EdGr (Post 5413053)

A newer chipset is not the reason. See OP. Both kernel-huge and generic-boot, there is just no RAMDISK despite mkinitrd an running lilo.

For other posters: I can't upgrade to current right now, only stable. I also no longer run custom kernels as there is no need. And BTW, how do you logically suppose building a new kernel will fix initrd?

Another thought is to try the 'large-memory' option in the global portion of your lilo.conf.

Quote:

Originally Posted by allend (Post 5413071)

Another thought is to try the 'large-memory' option in the global portion of your lilo.conf.

No good. BAH! this is driving me nuts. I could understand an error that a kernel module for the /boot file system was missing, but it looks as though the initrd is missing of bad. I unpacked and it looks fine (initrd.gz matches initrd-tree).

Oops confused your setup with my own but I have no windows partition on sda, so I shouldn't say. I overwrote my windows partition with Current x64 :).

Quote:

Originally Posted by kingbeowulf (Post 5413058)

A newer chipset is not the reason. See OP. Both kernel-huge and generic-boot, there is just no RAMDISK despite mkinitrd an running lilo.

I saw a similar problem with Slackware 14.1 on a very old PC. It appeared to be unique to a particular chipset/BIOS. http://www.linuxquestions.org/questi...1-a-4175486307

Quote:

Originally Posted by kingbeowulf (Post 5413058)

And BTW, how do you logically suppose building a new kernel will fix initrd?

Edit config-generic to build into the kernel the minimum modules that it needs to boot without an initrd. This is the filesystem (change CONFIG_EXT4_FS=m to CONFIG_EXT4_FS=y for example).

I think you will have better luck with -current. -current runs fine on my Asrock X99.
Ed

Quote:

Originally Posted by kingbeowulf (Post 5413056)

Yes, numerous times, see OP.

Apologies... I read it, but my ears must have let some of it leak out before it registered.
I hang my head in shame.

Well, I haven't been able to resolve this goofy issue on this motherboard. This is the first time in 10+ years that a CPU/motherboard swap did not quite result in Slackware booting as inspected. In the past I've also just swapped the boot hard drive between systems (even between Intel and AMD) and never had the generic/initrd fails while the huge kernel works fine. This isseu might also be due to the way UEFI+legacy is implemented on this particular motherboard.

I cleared some space and installed Slackware-Current (UEFI boot) and all's well, and can even transfer lilo on sdb for Slackware64-14.1 via the elilo menu. The Intel X99 chipset does like kernel-4.1.6 better.

Marking "solved" since Slackware-15 will be out "real soon now".

That's cool. I have been very happy with Slackware-current on my X99 (disclosure: I work for Intel).
Ed

Quote:

Originally Posted by kingbeowulf (Post 5417102)

Marking "solved" since Slackware-15 will be out "real soon now".

15 is still way too long :)