Requests for current-next (15.0-->15.1)

opty · 05-18-2022, 09:24 AM

It seems that I was looking at unpatched init and those unmatching timestamps won't help either. :-(

Didier Spaier · 05-18-2022, 10:13 AM

Quote:

Originally Posted by opty

It seems that I was looking at unpatched init and those unmatching timestamps won't help either. :-(

Well, I apply both patches in sequence as you can see in the SlackBuild here.

jostber · 05-18-2022, 11:05 AM

Get slackpkg to run lilo or eliloconfig after a Kernel Update so there will no be kernel panic if the laptop loses power or user forgetting to run it.

elcore · 05-18-2022, 11:27 AM

Quote:

Originally Posted by jostber

Get slackpkg to run lilo or eliloconfig after a Kernel Update so there will no be kernel panic if the laptop loses power or user forgetting to run it.

Before kernel upgrade, backup the running kernel and modules with a local script.
Afer kernel upgrade, overwrite vmlinuz* with vmlinuz, System.map* with System.map, and config* with config.

So your user won't have to run lilo, eliloconfig, or grub mkconfig, at all.
I've used for many years. Fully tested procedure.

Please consider, before asking package manager to run script which runs script that runs script to work around a non issue.

marav · 05-18-2022, 11:45 AM

BIND 9.18.3

Release notes:
https://downloads.isc.org/isc/bind9/...tml/notes.html

Code:

Security Fixes

* Previously, TLS socket objects could be destroyed prematurely, which triggered assertion failures in 
named instances serving DNS-over-HTTPS (DoH) clients. This has been fixed.

* ISC would like to thank Thomas Amgarten from arcade solutions ag for bringing this vulnerability to 
our attention. (CVE-2022-1183) [GL #3216]

bassmadrigal · 05-18-2022, 12:18 PM

Quote:

Originally Posted by elcore

Before kernel upgrade, backup the running kernel and modules with a local script.

...

Please consider, before asking package manager to run script which runs script that runs script to work around a non issue.

So, each user should create their own script to manage kernel upgrades? Why even have slackpkg or pkgtool in the system if users can create their own solutions to manage the system?

Note: this isn't to say that slackpkg should or should not change its process for kernel upgrades, but asking for a feature in Slackware shouldn't be shot back with "don't ask for that when you can create your own unique solution".

elcore · 05-18-2022, 12:52 PM

Quote:

Originally Posted by bassmadrigal

So, each user should create their own script to manage kernel upgrades? Why even have slackpkg or pkgtool in the system if users can create their own solutions to manage the system?

IMO, kernel upgrades are fine, without additional management features.

Quote:

Originally Posted by bassmadrigal

Note: this isn't to say that slackpkg should or should not change its process for kernel upgrades, but asking for a feature in Slackware shouldn't be shot back with "don't ask for that when you can create your own unique solution".

It's not an unique solution, and it's not package manager job to manage boot sectors.

biker_rat · 05-18-2022, 03:21 PM

MESA 22.1.0

bassmadrigal · 05-18-2022, 05:01 PM

Quote:

Originally Posted by elcore

IMO, kernel upgrades are fine, without additional management features.

As I said, I wasn't discussing the merits of adding that support to slackpkg, but instead your suggestion to build a custom solution for a problem when instead a standardized solution could exist for all of Slackware.

Quote:

Originally Posted by elcore

It's not an unique solution

It would be a unique solution to them. Each user would need to create their own "local script" to do this process. Each user would be reinventing the wheel when some other users already have one created. Is it a bad idea to consolidate the ideas into a script that is part of Slackware and possibly include that functionality into slackpkg?

Quote:

Originally Posted by elcore

it's not package manager job to manage boot sectors.

Some could argue that it is the package manager's job to ensure packages are installed properly for all the system to function. For some, that would include ensuring the system is able to boot after a kernel upgrade.

Personally, I don't care if the package manager supports that as I'm usually running my own kernel (I always blacklist all the kernel packages from slackpkg), but I can understand why some would want slackpkg to fully update the system and allow rebooting back into an updated system without any additional work on the user's end.

It seemed a little calloused to shut down the conversation and just tell the user to build their own custom solution.

marav · 05-18-2022, 06:36 PM

Quote:

Originally Posted by gmgf

System kinfocenter Graphics Wayland , not present and not work on 15.0 and current, it need 'wayland-utils'.

wayland-utils-1.0.0:

https://gitlab.freedesktop.org/wayland/wayland-utils

i have the SlackBuild if you want.

Still missing

opty · 05-19-2022, 01:52 AM

Quote:

Originally Posted by jostber

Get slackpkg to run lilo or eliloconfig after a Kernel Update so there will no be kernel panic if the laptop loses power or user forgetting to run it.

In /etc/slackpkg/blacklist, I use

Code:

#
# Automated upgrade of kernel packages may not be wanted in some situations;
# uncomment the lines below if that fits your circumstances, but note that
# kernel-headers should *not* be blacklisted:
#
kernel-generic.*
kernel-huge.*
kernel-modules.*
kernel-source

and just manually install new kernels. I haven't got to remove the old ones yet, though:

Code:

opty@vodopnik:~/tmp/backup/qeporkak/var/lib/pkgtools/packages$ ls -1 kernel-generic*
kernel-generic-5.10.11-x86_64-1
kernel-generic-5.10.24-x86_64-1
kernel-generic-5.10.32-x86_64-1
kernel-generic-5.12.12-x86_64-1
kernel-generic-5.12.14-x86_64-1
kernel-generic-5.14.12-x86_64-1
kernel-generic-5.15.12-x86_64-1
kernel-generic-5.15.27-x86_64-1
kernel-generic-5.15.38-x86_64-1

:-D

opty · 05-19-2022, 03:01 AM

Quote:

Originally Posted by Didier Spaier

patch used in Slint64-14.2.1.4 is attached. Maybe I had already posted it or linked to it, not sure about that.

I'd rather use

Code:

--- init        2022-04-26 21:27:02.000000000 +0200
+++ init.new    2022-05-19 09:32:34.110136466 +0200
@@ -198,17 +198,20 @@

     # Determine if we have to use a LUKS keyfile:
     if [ ! -z "$LUKSKEY" ]; then
-      mkdir  /mountkey
       KEYPART=$(echo $LUKSKEY |cut -f1 -d:)
-      KEYNAME=$(echo $KEYPART |cut -f2 -d=)
-      LUKSPATH="/mountkey$(echo $LUKSKEY |cut -f2 -d:)"
-      # Catch possible mount failure:
-      if blkid |grep "TYPE=\"vfat\"" |grep $KEYNAME 1>/dev/null 2>&1 ; then
-        MOUNTOPTS="-t vfat -o shortname=mixed"
-      else
-        MOUNTOPTS="-t auto"
+      LUKSPATH="$(echo $LUKSKEY |cut -f2 -d:)"
+      if [ ! -z "$KEYPART" ]; then
+        mkdir  /mountkey
+        KEYNAME=$(echo $KEYPART |cut -f2 -d=)
+        LUKSPATH="/mountkey$LUKSPATH"
+        # Catch possible mount failure:
+        if blkid |grep "TYPE=\"vfat\"" |grep $KEYNAME 1>/dev/null 2>&1 ; then
+          MOUNTOPTS="-t vfat -o shortname=mixed"
+        else
+          MOUNTOPTS="-t auto"
+        fi
+        mount $MOUNTOPTS $(findfs $KEYPART) /mountkey 2>/dev/null
       fi
-      mount $MOUNTOPTS $(findfs $KEYPART) /mountkey 2>/dev/null
       # Check if we can actually use this file:
       if [ ! -f $LUKSPATH ]; then
         LUKSKEY=""

More readable but don't use for patching:

Code:

opty@vodopnik:~/tmp$ diff -Naurb init init.new
--- init        2022-04-26 21:27:02.000000000 +0200
+++ init.new    2022-05-19 09:32:34.110136466 +0200
@@ -198,10 +198,12 @@

     # Determine if we have to use a LUKS keyfile:
     if [ ! -z "$LUKSKEY" ]; then
-      mkdir  /mountkey
       KEYPART=$(echo $LUKSKEY |cut -f1 -d:)
+      LUKSPATH="$(echo $LUKSKEY |cut -f2 -d:)"
+      if [ ! -z "$KEYPART" ]; then
+        mkdir  /mountkey
       KEYNAME=$(echo $KEYPART |cut -f2 -d=)
-      LUKSPATH="/mountkey$(echo $LUKSKEY |cut -f2 -d:)"
+        LUKSPATH="/mountkey$LUKSPATH"
       # Catch possible mount failure:
       if blkid |grep "TYPE=\"vfat\"" |grep $KEYNAME 1>/dev/null 2>&1 ; then
         MOUNTOPTS="-t vfat -o shortname=mixed"
@@ -209,6 +211,7 @@
         MOUNTOPTS="-t auto"
       fi
       mount $MOUNTOPTS $(findfs $KEYPART) /mountkey 2>/dev/null
+      fi
       # Check if we can actually use this file:
       if [ ! -f $LUKSPATH ]; then
         LUKSKEY=""

elcore · 05-19-2022, 03:05 AM

Quote:

Originally Posted by bassmadrigal

your suggestion to build a custom solution for a problem when instead a standardized solution could exist

It was not me who suggested change. I'm fine with how it works.
And I'm usually not the one who complains about scripts calling other scripts.
I just said that 1 script can do it easily, instead of package manager calling automatically a bunch of other scripts.
And that it should be considered before working around the issue which isn't really a software issue.

Quote:

Originally Posted by bassmadrigal

Each user would need to create their own "local script" to do this process.

Only the users who require this handholding process may want it, but that leaves each user with potential bugs.

Quote:

Originally Posted by bassmadrigal

Some could argue that it is the package manager's job to ensure packages are installed properly for all the system to function.

By that definition, it's also package manager job to handle BIOS.
Anyway, boot sectors aren't packages, and package distribution software should not tamper with them for security reasons.
So it'd have to be implemented just like in cfdisk and the installer, where the user input is required.
How does that solve issues which prompted the suggestion? It does not, it'd still require user input just like manual eliloconfig and others.

Suggestion, the way I see it, requires a slackpg function which fixes (1) a power outage and (2) the user. It's not something that's fixable.
Of course there's people like debian council who think it is, but it's offtopic here since Slackware generally does not hold users' hands.

Didier Spaier · 05-19-2022, 04:40 AM

Quote:

Originally Posted by opty

I'd rather use <snip>

Feel free to adapt/modify it for use in genuine Slackware. For me as long as no Slint user complains it's good enough as is.

opty · 05-19-2022, 04:46 AM

Quote:

Originally Posted by Didier Spaier

Feel free to adapt/modify it for use in genuine Slackware. For me as long as no Slint user complains it's good enough as is.

Well, I created that patch myself today against the newest Slackware mkinitrd package's init trying to do as few changes as possible, keeping the style. :-)