Install -current from within slack-stable

joenew · 01-02-2020, 06:16 PM

Hi all,
I’m trying to install slack64-current along 14.2.
Here my fdisk -l:

Code:

fdisk -l /dev/sda
Disk /dev/sda: 232,9 GiB, 250059350016 bytes, 488397168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A176F2CE-5FBF-4692-BD97-F692331CE7D3

Dispositivo     Start      Fine   Settori   Size Tipo
/dev/sda1        2048      4095      2048     1M BIOS boot
/dev/sda2        4096    413695    409600   200M EFI System
/dev/sda3      413696 210128895 209715200   100G Linux filesystem
/dev/sda4   210128896 480112639 269983744 128,8G Linux filesystem
/dev/sda5   480112640 488397134   8284495     4G Linux swap

Slackware64-14.2 is installed in sda3 partition.
I want to install slackware64-current on sda4.
I worked from a chroot environment, from the 14.2 system and using as target partition sda4 (ext4). As described in this link:
https://www.linuxquestions.org/linux...xisiting_linux

Now there must be something wrong with my grub2 understanding... because I obtain a sad kernel panic error at reboot after choosing “Slackware 14.2+” on grub menu.

Code:

# grub-mkconfig -o /boot/grub/grub.cfg
Creazione di grub.cfg...
Trovata immagine linux: /boot/vmlinuz-huge-4.4.190
Trovata immagine linux: /boot/vmlinuz-huge
Trovata immagine linux: /boot/vmlinuz-generic-4.4.190
Trovata immagine linux: /boot/vmlinuz-generic
Trovato Slackware Linux (Slackware 14.2) su /dev/sda3
Trovato Slackware Linux (Slackware 14.2+) su /dev/sda4
fatto

I’d like to install grub on /dev/sda and let it manage all 2 systems. So, not many grub installations, one per partitions superblock.
The guide linked above suggests also this command to support a filesystem not present in the kernel:

Code:

mkinitrd -c -k <kernel-version> -m ext4 -f ext4 -r /dev/sda8

Launched from within the chroot. I tried but It didn’t solve... still kernel panic...
Have you got any suggests? I haven’t learned grub2 behavior!

Thanks in advance!

bassmadrigal · 01-02-2020, 06:53 PM

I have basically no experience with grub, but it looks like it is only loading 4.4.x kernels from 14.2's /boot/. You'll need to have your -current partition mounted and reference those files in your grub (like /mnt/boot/vmlinux-huge-5.4.7 or wherever you have your /dev/sda4 mounted to).

If it's anything like lilo (and I think in this regard it is), all kernels and initrds need to be mounted and accessible and linked using their current absolute path before running lilo/grub.

In your 14.2 system, you'd need something like:

/dev/sda3 mounted to /
/dev/sda4 mounted to /mnt

grub pointing to 14.2 kernels in /boot/ and -current kernels in /mnt/boot/

Then if you want to be able to manage it on your -current install, you'd need to reverse it.

/dev/sda4 mounted to /
/dev/sda3 mounted to /mnt

Then grub would point to your -current kernels in /boot/ and 14.2 kernels in /mnt/boot/

Hopefully this makes sense... if not, feel free to ask me to clarify anything.

colorpurple21859 · 01-02-2020, 07:48 PM

Quote:

If it's anything like lilo (and I think in this regard it is), all kernels and initrds need to be mounted

No,the partitions don't have to be mounted for grub-mkconfig to pick up the kernels.
Post your grub.cfg file

Quote:

mkinitrd -c -k <kernel-version> -m ext4 -f ext4 -r /dev/sda8

If this is what you did, it is wrong, should be /dev/sda4. From within slackware-current run

Code:

sh /usr/share/mkinitrd/mkinitrd_command_generator.sh -k 5.4.7

to get a better idea of what you need to run for mkinitrd. This is assuming this is the correct kernel version.

joenew · 01-03-2020, 03:17 AM

This is what I did:

Code:

:~# mount /dev/sda4 /mnt/ssd
:~# mount -o bind /dev /mnt/ssd/dev
:~# mount -t sysfs /sys /mnt/ssd/sys
:~# mount -t proc /proc /mnt/ssd/proc
:~# mount -o remount,dev,exec /mnt/ssd
:~# chroot /mnt/ssd/ /bin/bash

:/# cat /etc/slackware-version
Slackware 14.2+
:/# ls /lib/modules/
5.4.7
:/# mkinitrd -c -k 5.4.7 -m ext4 -f ext4 -r /dev/sda4

I followed suggested procedure in the guide, just add the "remount" command, without it chroot returned an error.
Below the output of your suggested command mkinitrd_command_generator.sh

Code:

:/# sh /usr/share/mkinitrd/mkinitrd_command_generator.sh -k 5.4.7
#
# mkinitrd_command_generator.sh revision 1.45
#
# This script will now make a recommendation about the command to use
# in case you require an initrd image to boot a kernel that does not
# have support for your storage or root filesystem built in
# (such as the Slackware 'generic' kernels').
# A suitable 'mkinitrd' command will be:

mkinitrd -c -k 5.4.7 -f ext4 -r /dev/sda4 -m xhci-pci:ohci-pci:ehci-pci:xhci-hcd:uhci-hcd:ehci-hcd:hid:usbhid:i2c-hid:hid_generic:hid-asus:hid-cherry:hid-logitech:hid-logitech-dj:hid-logitech-hidpp:hid-lenovo:hid-microsoft:hid_multitouch:jbd2:mbcache:ext4 -u -o /boot/initrd.gz

Ok, If I well understood the grub.cfg within the chroot (the one in sda4 /boot dir) is not to be considered in this case. If I launch grub-makecfg from slack stable (/dev/sda3) it will install grub.cfg in boot dir of sda3 partition and since the part of grub installed in the bootloader partition the first of "sda" (see above fdisk -l) was installed from sda3 it looks at ${sda3}/boot/grub.cfg.
If I well understand grub-mkconfig doesn't reinstall the bootloader within "BIOS first partition". But It just rewrites grub config within the "target" directory ${sda3}/boot/grub.
Indeed as you can see, the attached grub.cfg contains the new kernels regularly referred to the right partition and directory.

One doubt about ${sda4}/boot/initrd.gz. Is it to be generated before or after the launch of grub-mkconfig?

joenew · 01-03-2020, 04:43 AM

The problem of kernel panic was related to missing initrd line in menuentry of "Slackware 14.2+", look at the bottom of attached grub.cfg file.
The question could be why grub-mkconfig omitted initrd.gz?
Anyway I manually edited grub.cfg, even if on top is stated "DON'T EDIT THIS FILE". Below you see the bold line of initrd added.

Code:

menuentry 'Slackware Linux (Slackware 14.2+)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-23e9d4e8-59a8
-43bc-ad4d-965cf51623de' {
        insmod part_gpt
        insmod ext2
        set root='hd0,gpt4'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt4 --hint-efi=hd0,gpt4 --hint-baremetal=ahci0,gpt4  23e9d4e8-59a8-43bc-ad4d-965
cf51623de
        else
          search --no-floppy --fs-uuid --set=root 23e9d4e8-59a8-43bc-ad4d-965cf51623de
        fi
        linux /boot/vmlinuz-generic-5.4.7 root=/dev/sda4
        initrd /boot/initrd.gz
}

In this way slackware current with "generic" kernel doesn't return kernel panic.
The same if I choose the other grub entry related to slackware 14.2+ with "huge" kernel: it doesn't need any initrd of course.

Now the question is: there is a clean way to obtain a more clean boot menu?
Why grub.cfg should not be edited by hands?

PS.
Unfortunately system doesn't boot anyway.
It returns an error about fsck.

Code:

sbin/e2fsck: Is a directory while trying to open /
...

The superblock could not be read or does not describe a valid ext2 / ext3 / ext4 filesystem
...
...

I'll looking for that error on google...

colorpurple21859 · 01-03-2020, 05:08 AM

Your are correct on how grub works, I suspect the problem is with your initrd.gz.
At the grub prompt highlight the current entry, hit e change the linux line to this

Code:

linux /boot/vmlinuz-huge-5.4.7 root=/dev/sda4

If it boots you need to run the mkinitrd_command_generator.sh as already suggested to get a good initrd.gz

joenew · 01-03-2020, 07:13 AM

Yes It seems I was right:

Problem 1: kernel panic
Solution A: missing "initrd /boot/initrd.gz" string, so adding it as shown above lets kernel-generic to boot (or actually should let it to boot, if there isn't any other different issue).
Solution B: choose kernel-huge menuentry, it doesn't need initrd so the system should boot

Problem 2: even if problem 1 should be solved, the system doesn't boot complaining about "superblock corruption".
Solution: missing "/etc/fstab"
I forgot to make it from the chroot installation during basic configure. The linked guide remember to edit that file... I just forgot, so the system can't boot regularly.

So, grub related, initrd related and fstab related issues are solved. But I'd like to understand a bit better grub mechanics to better control it (there was a cleaner way instead of grub.cfg direct editing?).

There is an other issue I noticed, it regards SSL certificate or something similar i think... When I launch

Code:

slackpkg update gpg

It returns an error:

Code:

WARNING: cannot verify mirrors.slackware.com's certificate, issued by 'CN=Let\'s Encrypt Authority X3,O=Let\'s Encrypt,C=US':
Unable to locally verify the issuer's authority.

I can solve it by replace that address https://mirror.slackware.com/... with an other in /etc/slackpkg/mirrors
But I think it should work, and likely something wrong on my system could cause certificate verify issue.

Any suggest?

colorpurple21859 · 01-03-2020, 07:25 AM

run the setup in pkgtool maybe.

joenew · 01-03-2020, 10:30 AM

Yess! it worked!

Running pkgtool, then choose Setup, and the "rebuild SSL certificate database".
I don't know what exactly it did, i suspect something like

Code:

update-ca-certificates --fresh

.. Or similar... Anyway now I can use the "secure" mirror:

Code:

slackpkg update gpg

2020-01-03 16:29:52 URL:https://mirrors.slackware.com/slackware/slackware64-current/GPG-KEY [1572/1572] -> "/tmp/slackpkg.RGytyK/gpgkey" [1]
pub  1024D/40102233 2003-02-26 Slackware Linux Project <security@slackware.com>
sub  1024g/4E523569 2003-02-26 [expires: 2038-01-19]