LinuxQuestions.org - Requests for -current (14.2-->15.0)

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

- - Requests for -current (14.2-->15.0) (https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/)

Quote:

Originally Posted by BrunoLafleur (Post 6259552)

I agree with this. I prefer huge kernels since a lot of time after I have decided to stop recompiling my kernels. It is far easier to switch to the latest with slackpkg or upgradepkg with elilo, grub, lilo, syslinux or refind.

PS : I use Slackware since nearly the first versions.

Come on! It's just the power of habit and your non willingness to learn new tricks! ;)

So, we should stop the progress because some old habits? Honestly, I consider that the huge kernel is as useful today like is the tail to humans.

Coming from an Ubuntu background - then being really habituated with the usage of an initrd, I have never used the huge kernel on an installed Slackware system since I started to use the Slackware, over the 10 years ago.

Yeah, it's still a bit tricky on Slackware to keep the initrd in sync, compared with other distributions - both Ubuntu and/or openSUSE are light years away on initrd (self-)management.

BUT, there are solutions, like what the Slackware ARM do: they ship an initrd in a kernel package, then it's customized on fly with the help of a tool named /usr/sbin/os-initrd-mgr and some configuration and script files put on /boot/local

I believe that something like this we badly need also us, on Slackware(64)

Quote:

Yeah, it's still a bit tricky on Slackware to keep the initrd in sync, compared with other distributions

How hard is it to 'cat /boot/initrd-tree/command_line' to get a command (provided you have not messed by creating a /etc/mkinitrd.conf) that only needs to be adjusted for the new kernel version?

In general I use kernel-generic for all of my installs, with the exception of the clean installs, be they on in a virtual machine or hardware. Those I use kernel-huge, simply because it's easier than, setting up for kernel-generic. Since the order of install during a full install or the upgrade order with slackpkg is alphabetical kernel-huge will be installed/upgraded after kernel-generic, so kernel-huge is the "default" kernel. I run a stock blacklist on clean machines. If I need to do some testing on a clean machine I make sure it's up to date, then snapshot it or image it.

As for the kernel-generic machines I use a /etc/mkinitrd.conf file for each computer. So it as simple as mkinitrd -F -k 5.12.10 to create the new initrd.gz and initrd-tree/.

Quote:

So it as simple as mkinitrd -F -k 5.12.10 to create the new initrd.gz and initrd-tree/.

Precisely why I do not like it. Too prone to fat finger errors and the need to remember the syntax. The -F also gets recorded in the /boot/initrd-tree/command_line, which requires additional checks in an automated scripting solution.

Quote:

Originally Posted by allend (Post 6259588)

How hard is it to 'cat /boot/initrd-tree/command_line' to get a command (provided you have not messed by creating a /etc/mkinitrd.conf) that only needs to be adjusted for the new kernel version?

Well, is not enough to generate an initrd, but also there should be done various other operations to complete the new kernel setup for an initrd. I for one, I use a script, like this

Code:

#!/bin/sh



KVERSION=`ls /boot/vmlinuz-generic-5.12.* | cut -d- -f3`



BOOTDISK=$(mount | grep 'on / ' | cut -d' ' -f1 | tr -d '[:digit:]')



#

KMODULES="bfq:uas: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"



ROOTDEV="UUID=cfdac110-c3cc-4c19-bcac-ac20aed57ea1"

ROOTFS="ext4"



SWAPDEV="UUID=ad3032e7-cd3a-460d-b386-621d34454a59"





# Create the initrd.

mkinitrd -c -k "$KVERSION" -r "$ROOTDEV" -f "$ROOTFS" -m "$KMODULES" -h "$SWAPDEV" -u -M -s /boot/initrd-generic-${KVERSION} -o /boot/initrd-generic-${KVERSION}.gz



# Create the symlink for initrd.

(cd /boot; ln -sf initrd-generic-${KVERSION}.img initrd-generic.img)



# Mount the EFI partition.

mount /boot/efi



# Update the kernel and initrd on EFI partitition.

cp -f /boot/vmlinuz-generic-${KVERSION} /boot/efi/EFI/Slackware/vmlinuz-generic

cp -f /boot/initrd-generic-${KVERSION}.img /boot/efi/EFI/Slackware/initrd-generic.img



# Run the LILO.

lilo -P ignore -b ${BOOTDISK}

Like you notice, I have a setup with both EFI (for ELILO) and LILO, because my processor (from this particular box) has no support for some instructions required for Android x86 on 64bit, then I should launch Android x86 32bit via the CSM way. For convenience, even there I like to have a boot menu.

BUT, excluding this particular dual bootloader setup, still are some things to do, which this /boot/mkinitrd-generic.sh script do. When I launch it manually.

So, compare this this with Ubuntu or openSUSE, or Fedora, where to setup your initrd (when you update the kernel) you have to do exactly NOTHING, because everything is handled automatically.

Quote:

Originally Posted by LuckyCyborg (Post 6259609)

So, compare this this with Ubuntu or openSUSE, or Fedora, where to setup your initrd (when you update the kernel) you have to do exactly NOTHING, because everything is handled automatically.

Or with Slint as illustrated in attached files. install.txt is run during installation in 'auto' mode, update.txt when an update is available.

Quote:

Originally Posted by Didier Spaier (Post 6259613)

Or with Slint as illustrated in attached files. install.txt is run during installation in 'auto' mode, update.txt when an update is available.

OR with Slint.

Like I said already, there are solutions to improve the initrd management. Yours, the one invented by Dr. Mozes, probably many others.

BUT, instead of improving the initrd handling, what we do us? We do the huge kernel eulogies...

Speaking of kernel upgrades:
https://github.com/fire-h0und/tool_c...nel-upgrade.sh

HTH :hattip:

Just arrived in my inbox.

NetworkManager-1.32.0
https://download.gnome.org/sources/N...-1.32.0.tar.xz

Skanlite not working properly (-current)

Hello all, I've finally updated to -current, and skanlite-2.2.0-i586-3 doesn't work properly. Xsane works just fine with my scanner; but Skanlite preview windows doesn't: the selected part of the image in the preview isn't the part that is actually scanned; the scanned part of the image is about 5% shifted down and also elongated. Similarly, when scanning an A4 page, selecting "A4" as the scan area size works fine in the output, but the preview is incorrect, the displayed selection is about 15% short.

Using auto-selection has the same problem: the selected part of the image in the preview isn't the part actually scanned in the final output, either. Any ideas?

KDE Connect seems to be crashing on the latest Plasma, opening the KDE Connect panel in system settings causes the daemon to crash.

Quote:

Originally Posted by drgibbon (Post 6259747)

KDE Connect seems to be crashing on the latest Plasma, opening the KDE Connect panel in system settings causes the daemon to crash.

Scratch that, it crashes on first login to the desktop.

Quote:

Originally Posted by LuckyCyborg (Post 6259562)

Out of curiosity, what "progress" has been made by using initrds?

I had been using an initrd for about 5 years. It started when I switched my lilo and fstab to persistent naming. When I build my new computer back in 2017, I switched my main drive to an NVMe, and it is the sole NVMe device on my computer. Because of that, I have no need to do persistent naming with elilo, so I didn't use it in there. I continued using initrds for a few years after. However, when I was compiling recent kernels (using Pat's generic config with some minor tweaking), I decided to just include ext4 in the kernel and stopped using an initrd.

I've not noticed any difference (other than it being slightly simpler to update my kernel.

I do realize that there are situations that require an initrd (like using UUIDs during boot, luks/lvm, etc), but for other systems, what is the benefit of using an initrd? There's less than 100 modules difference between the huge and generic kernels...

You already pointed out that an initrd is required in some cases: volume UUIDs, luks, lvm.
Let me add to the list raid (/etc/mdadm.conf), hibernation (/resumedev), use of non-english keyboards on boot (keymap), microcode updates.
You can just have a read at mkinitrd's source code and see what it does.

I read someone before saying that making an initrd is difficult, and nobody replied with /usr/share/mkinitrd/mkinitrd_command_generator.sh yet.