[SOLVED] Slackware64-current (Mon Jun 18 06:19:23 UTC 2018) installer Kernel panic

Skaendo · 06-18-2018, 07:23 AM

ISO created with Eric's mirror-slackware-current script,
written to USB with:

Code:

dd if=slackware64-current-install-dvd.iso of=/dev/sdb bs=4M status=progress && sync

It gets to Loading initrd, then:

Code:

vfs_read+0x89/0x130
? set_debug_rodata+0x11/0x11
SyS_read+0x42/0x90
change_floppy+0x108/0x149
? rd_load_image+0x51e/0x530
? do_onlinkat+0xbe/0x2e0
mount_root+0x4e/0xaf
prepare_namespace+0x165/0x19b
kernel_init_freeable+0x1de/0x1eb
ret_from_fork+0x35/0x40
Code: 48 98 c3 90 90 90 90 90 90 90 90 90 90 90 90 90 66 66 66 66 90 65 48 8b 04 25 40 4d 01 00 f6 40 26 20 74 11 48 8b 80 e0 04 00 00 <48> 8b 00 48 d1 e8 83 e0 01 c3 0f 0b eb eb 0f 1f 80 00 00 00 00
RIP: kthread_should_stop+0x1b/0x30 RSP: ffffa6c900017be0
CR2: 0000000000000000
---[ end trace a1014ab248cd55f0 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009

Kernel Offset: 0x21000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009

This is all I'm seeing on my screen.

No clue what I can do except report it here.

RandomTroll · 06-18-2018, 08:51 AM

Don't you want sdb1, not sdb ?

Didier Spaier · 06-18-2018, 08:59 AM

Quote:

Originally Posted by RandomTroll

Don't you want sdb1, not sdb ?

No, the ISO has to be written on a disk, not a partition.

AlleyTrotter · 06-18-2018, 09:17 AM

same thing happens from the install dvd

Kernel Panic

Cheers
john

Alien Bob · 06-18-2018, 05:43 PM

It may be related, but Pat has updates scheduled that regenerate the installer initrd. He switched to XZ compression in the "Mon Jun 18 06:19:23 UTC 2018" update but this requires an additional "--check=crc32" parameter to the xz command because the Linux kernel can't compe with CRC64 (the default) and then panics when trying to unpack that XZ-compressed initrd.

Unfortunately OSUOSL is closed for maintenance at the moment so Pat can not push the update. Our fellow Slacker alphageek published that unreleased update on his own server if you need that fixed initrd right now: http://alphageek.slackware.nl/mirror...are64-current/

Skaendo · 06-18-2018, 05:48 PM

Quote:

Originally Posted by Alien Bob

It may be related, but Pat has updates scheduled that regenerate the installer initrd. He switched to XZ compression in the "Mon Jun 18 06:19:23 UTC 2018" update but this requires an additional "--check=crc32" parameter to the xz command because the Linux kernel can't compe with CRC64 (the default) and then panics when trying to unpack that XZ-compressed initrd.

Unfortunately OSUOSL is closed for maintenance at the moment so Pat can not push the update. Our fellow Slacker alphageek published that unreleased update on his own server if you need that fixed initrd right now: http://alphageek.slackware.nl/mirror...are64-current/

Thanks for the heads up Eric.
I can wait for Pat to be able to update.

Skaendo · 06-18-2018, 08:40 PM

Thanks for the quick fix Pat!

AlleyTrotter · 06-19-2018, 08:48 AM

Quote:

Originally Posted by Alien Bob

It may be related, but Pat has updates scheduled that regenerate the installer initrd. He switched to XZ compression in the "Mon Jun 18 06:19:23 UTC 2018" update but this requires an additional "--check=crc32" parameter to the xz command because the Linux kernel can't compe with CRC64 (the default) and then panics when trying to unpack that XZ-compressed initrd.

Unfortunately OSUOSL is closed for maintenance at the moment so Pat can not push the update. Our fellow Slacker alphageek published that unreleased update on his own server if you need that fixed initrd right now: http://alphageek.slackware.nl/mirror...are64-current/

Still having issues here. This is a copy of my email to Pat this morning concerning current dated Tue Jun 19 05:47:22 UTC 2018
...
Greetings Pat
The installer kernel boots, installs, and writes a efivars entry.

Code:

efibootmgr -v
Timeout: 1 seconds
BootOrder: 0000,0007,0005,0001,0002,0003,0008
Boot0000* Slackware HD(1,800,200000,1602cc83-edc0-6e4b-af45-941189067048)File(\EFI\Slackware\elilo.efi)
Boot0001* Hard Drive....

But will not boot from the uefi boot menu.
blkid says the UUID's match ie the uefibootmgr UUID and blkid UUID
It boots from the bootstick
It boots from a stanza in elilo.conf from any other uefi bootable device

One strange thing I noticed is when booting from the bootstick it says
"Loading Kernel /vmlinuz...."
I never noticed there being a slash before the kernel name before.

Thanks for listening to my issues.
Cheers
AlleyTrotter

Maybe this should be a separate thread?
J

Didier Spaier · 06-19-2018, 10:54 AM

@AlleyTrotter: not sure this be the cause of your issue, but I think that you don't have efibootmgr-16, now in Slackware-current.

Output of efibootmgr -v (version 5.4(*) in Slackware-14.2):

Code:

Boot000B* Slackware    HD(1,800,64000,6645816d-6641-4cc3-aa3e-0e8e5b1b7438)File(\EFI\Slackware\elilo.efi)

Output of efibootmgr -v (version 16 to be shipped in Slint-14.2.1.2):

Code:

Boot000B* Slint    HD(1,GPT,4b8ad322-3e25-11e8-ba71-080027dce0fe,0x28,0x32000)/File(\EFI\Slint\elilo.efi)

This is in the same VirtualBox VM.

Similarly on bare metal (still efibootmgr version 16):

Code:

Boot001A* EFI Boot menu    HD(1,MBR,0x91ca468c,0x800,0x46000)/File(\EFI\efibootmenu\BOOTx64.EFI)

all these boot entries work. In the third case the hard disk has a DOS partition table (not a GPT) and efibootmgr is run by EFI3M, but this doesn't matter.

So, please upgrade efibootmgr and see what happens.

@Pat: efibootmgr-16 works with efivar-36 on my VM, but not in bare metal (that has a relatively old firmware). Downgrading to efivar-35 fixed that. Thanks for the clue!

I got some warnings:

Code:

This entry has been added to the firmware's boot menu:
GUID Partition Table Header signature is wrong: 139e8811bbe5652 != 5452415020494645
GUID Partition Table Header signature is wrong: fffffffffffffffc != 5452415020494645
GUID Partition Table Header signature is wrong: 139e8811bbe5652 != 5452415020494645
GUID Partition Table Header signature is wrong: fffffffffffffffc != 5452415020494645
GUID Partition Table Header signature is wrong: 139e8811bbe5652 != 5452415020494645
GUID Partition Table Header signature is wrong: fffffffffffffffc != 5452415020494645
Boot001A* EFI Boot menu    HD(1,MBR,0x91ca468c,0x800,0x46000)/File(\EFI\efibootmenu\BOOTx64.EFI)

Nevertheless I can boot this entry from the firmware menu.

(*) I know that efibootmgr has been upgraded to version 6.0 in Slackware 14.2, but I don't need to upgrade all the systems in this VM, that I only use for testing purposes.

Skaendo · 06-19-2018, 02:17 PM

Quote:

Originally Posted by AlleyTrotter

But will not boot from the uefi boot menu.
blkid says the UUID's match ie the uefibootmgr UUID and blkid UUID
It boots from the bootstick
It boots from a stanza in elilo.conf from any other uefi bootable device

J

I did notice in the changelog:

Code:

+--------------------------+
Mon Jun 18 18:33:23 UTC 2018
isolinux/initrd.img:  Rebuilt.
  Use -C crc32 when compressing the initrd/modules with xz.
usb-and-pxe-installers/usbboot.img:  Rebuilt.
  Use -C crc32 when compressing the initrd/modules with xz.
+--------------------------+

It looks like Pat didn't remake the EFI initrd. I wonder why?

volkerdi · 06-19-2018, 02:26 PM

Quote:

Originally Posted by Skaendo

I did notice in the changelog:

Code:

+--------------------------+
Mon Jun 18 18:33:23 UTC 2018
isolinux/initrd.img:  Rebuilt.
  Use -C crc32 when compressing the initrd/modules with xz.
usb-and-pxe-installers/usbboot.img:  Rebuilt.
  Use -C crc32 when compressing the initrd/modules with xz.
+--------------------------+

It looks like Pat didn't remake the EFI initrd. I wonder why?

The efiboot.img just boots the other initrd.img, so it didn't need rebuilding.

AlleyTrotter · 06-19-2018, 03:20 PM

@Dider The version in current is 16. I just did the printout from my daily driver

@Pat: efibootmgr-16 works with efivar-36 on my VM, but not in bare metal.(from Dider's reply)

This is a bare metal install on a SSD plugged in on /dev/sda. I was first trying the install in my usually no problem qemu VM, starting having problems with current dated Wed Jun 13 05:43:00 UTC 2018 so I started trying to do the bare metal install
Still after several changes and adds of efi libraries by Pat no cigar. Current refuses to boot from the firmware menu. However it boots from a bootstick and/or by adding an elilo.config stanza on a separate efi partition ie. a hard disk as device sdb1 or on a nvme as device nvme0n1p1

Current install is already using efivar-35-x86_64-1

I seem to catch all the corners

AlleyTrotter