My apporach on how to keep Slackware-current upgraded
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Another feature request would be to add elilo / UEFI support, which could be a bit more difficult as the Kernel and the initrd have to be copied over to /boot/efi/EFI/Slackware/ and according symlinks have to be generated there.
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?
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.
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?
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?
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?
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.
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.
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:
Code:
ls -1 slackware64/{a,d,k}/kernel-*.t?z
grep '^PACKAGE NAME: *kernel-' PACKAGES.TXT
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.
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:
Code:
ls -l /var/log/packages/dialog-*
... 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?
-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.
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!
Yes I get the dialog when run ... please see screenshots attached.
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:
Code:
slackpkg info kernel-generic
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.