The thought has just crossed my mind that the EFI system partition has a FAT-something file system (unless I'm mistaken). That doesn't support symlinks, does it?

No, it does not support EFI, but that's not the main reason one has to copy over the kernel/initrd on every update. The other partitions are not available at this time, so you could not link from /boot/efi to e.g. /boot which would make the situation a bit easier.

Sorry, I think you misunderstood, or I may not have expressed myself clearly enough.

The issue is not about where to make the symlinks point to (I get it that they cannot point outside the EFI partition).

The issue is about the inability to create the symlinks in the first place. To the best of my knowledge, the FAT-formatted EFI partition simply doesn't support the notion of symlinks, or does it?

No, it does not support symlinks.

I've been using upgrade-kernel.sh for some time now without issue but when I ran it yesterday, it sat for a couple of seconds and then returned to the prompt. Downloaded again from this thread and did a diff with no result so my script is per the source. Any ideas?

Regards, Robby

Well, the thought did cross my mind, some time ago, that the script is a bit wacky in how it checks for installed and available kernel versions. It's been a while since I last looked at it, so I can't remember the exact details of what I was thinking about (comes with age, you know... ); also, I haven't spent much time on Slackware lately (life happens, you know... ), but I do remember wanting to take a new look at the script once I'm up and running with Slackware 15 again, in order to make the script more robust.

In the mean time, could you tell me what version of Slackware you're running (14.2, 15, current)? Do you have any non-standard kernels installed (any kernel that did not come from the Slackware repository corresponding to the Slackware version you're running)?

One immediately obvious issue that I'm thinking of, will occur when you have not blacklisted all "kernel" packages. For instance, if kernel-headers is not blacklisted and you do a full system update before you run my script, I think it will get confused, and I don't think I included any code to gracefully handle such conditions. In fact, I have no idea how it will react in such a case, come to think of it.

Needs a bit of work, obviously. First, though, I'll have to get going with Slackware again.

Hi @luvr

I'm running -current updated to yesterday.

Primary kernel is:

5.19.15

Backup kernel is:

5.18.12

Both are from the distro repo(s) and there are no non-std kernels.

My slackpkg blacklist list:
I think that should include everything ...

Here are my lilo.conf entries:

Thank you very much for the script and I'll track here for any updates.

Regards, Robby

Yes, my script should be happy with this configuration.

One scenario that my script won't gracefully handle and that I have just thought of: If the online repository is in the middle of being updated when you sync your local copy, and you then attempt to run the script, I think it will silently fail.
If you haven't updated your local repository copy since you last ran the script, may I suggest you list the kernel packages that it holds, and then compare this to the contents of the package list file? Something like the following should do (while you're in the main directory of your local repository copy - i.e., the directory that contains the 'ChangeLog.txt' and 'PACKAGES.TXT' files and the 'slackware64' directory:
If these two commands don't show the exact same filenames, then you may want to try and resync your local copy and rerun the script. Otherwise, I will have to dig deeper to understand what may be going on here.

Thanks @luvr

I've just checked on this and everything matches:

ls -1 slackware64/{a,d,k}/kernel-*.t?z
slackware64-current/slackware64/a/kernel-firmware-20230117_7e4f0ed-noarch-1.txz
slackware64-current/slackware64/a/kernel-generic-6.1.7-x86_64-1.txz
slackware64-current/slackware64/a/kernel-huge-6.1.7-x86_64-1.txz
slackware64-current/slackware64/a/kernel-modules-6.1.7-x86_64-1.txz
slackware64-current/slackware64/d/kernel-headers-6.1.7-x86-1.txz
slackware64-current/slackware64/k/kernel-source-6.1.7-noarch-1.txz

grep '^PACKAGE NAME: *kernel-' slackware64/PACKAGES.TXT
PACKAGE NAME: kernel-firmware-20230117_7e4f0ed-noarch-1.txz
PACKAGE NAME: kernel-generic-6.1.7-x86_64-1.txz
PACKAGE NAME: kernel-headers-6.1.7-x86-1.txz
PACKAGE NAME: kernel-huge-6.1.7-x86_64-1.txz
PACKAGE NAME: kernel-modules-6.1.7-x86_64-1.txz
PACKAGE NAME: kernel-source-6.1.7-noarch-1.txz

Regards, Robby

Hmmm... To the best of my knowledge, my script should handle this just fine. Even so, there may still be some weird bug in the script, but I will have to dive into the code again to find out.

I am wondering, though, if this could be a dialog error. It's a wild guess, obviously, but could you check what dialog version is installed on your system (if you keep your system updated, on "-current", it should be dialog-1.3_20221229-x86_64-1, I believe) and when it was installed? Just do:
... and that should tell you the version as well as the date and time when it was installed. Could it be that this is the first time you're running my script since the latest dialog version got installed?

Here we go:

-rw-r--r-- 1 root root 6873 Jan 6 20:11 /var/log/packages/dialog-1.3_20221229-x86_64-1

Looks the same.

"Could it be that this is the first time you're running my script since the latest dialog version got installed?" - possible but I've tried it a number of times now and the same result - sits for about 2 seconds and then returns to the prompt.

Regards, Robby

Before I go on hunting the problem, would you mind trying the dialogtest script I attached here?
It should display mock-ups of the two dialogs that may get shown when there is a new kernel available.
If you just hit <ENTER> on each dialog, then it will show you the return code of the dialog command.

Let me know if the dialogs really do get shown, and what the return codes are.
Thanks in advance!

Attached Files

dialogtest.txt (3.3 KB, 8 views)

Hi @luvr,

Yes I get the dialog when run ... please see screenshots attached.

Thank you for continuing to assist,

Regards, Robby

Attached Thumbnails

       

Hmmm... The dialog command terminated with a return code of 1 instead of 0.
Did you just press <ENTER> on the dialogs, or did you do anything else to respond to them?

I'm beginning to think that there must be two updated kernel versions available in the repository, e.g., one in the regular location and one in, e.g., extras.
If you haven't yet updated your local repository mirror, I suggest you try something like:
If I remember correctly, that command should list the candidate versions to update the kernel-generic package. Should this command list more than one version, my script will consider that a fatal error and silently fail. (I think I considered this condition so improbable at the time, that I didn't bother to handle it in any way that might be deemed "elegant". I seem to remember considering the possibility some day, though, but I think that subsequently "life happened" before I got the chance to even begin to think it through.)

If this really is the problem, I guess I could come up with a quick fix (perhaps just have the script simply select the highest available version, irrespective of where it comes from in the repository); alternatively, you may want to update your local repository mirror and hope only a single kernel version remains.

In any case, I will be installing a Slackware64 '-current' on my laptop one of the next days and see what happens; it desperately needs a new install anyway.