LinuxQuestions.org
Help answer threads with 0 replies.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 11-04-2019, 02:34 AM   #46
lioh
Member
 
Registered: Aug 2019
Location: Switzerland
Distribution: Slackware
Posts: 70

Rep: Reputation: Disabled

@luvr. I am actually not sure what caused this situation but currently the following broken symlink has been created:

initrd-*-prev -> initrd-*-4.19.80*

I have used the script for the first time on a newly installed system and this link has been generated on the first kernel update. The 'old' initrd was named just initrd.gz, maybe that's the root cause.
 
Old 11-04-2019, 02:53 AM   #47
luvr
Member
 
Registered: May 2005
Location: Boom - The Home Town of Tomorrowland, Belgium
Distribution: Slackware, Debian, Xubuntu
Posts: 323
Blog Entries: 1

Rep: Reputation: 136Reputation: 136
Quote:
Originally Posted by lioh View Post
@luvr. I am actually not sure what caused this situation but currently the following broken symlink has been created:

initrd-*-prev -> initrd-*-4.19.80*

I have used the script for the first time on a newly installed system and this link has been generated on the first kernel update. The 'old' initrd was named just initrd.gz, maybe that's the root cause.
What a coincidence... I have just run into the same issue myself. It happens because one of the patterns to find existing initrds does not find any files and thus returns just the pattern unchanged.

I now have an updated version of the script available, which I will upload later. (I don't have my Slackware system handy at the moment, but the solution is as simple as inserting an appropriate "shopt" command near the top of the script.)

Thanks for reporting this issue. It reminds me to upload the new version.

Last edited by luvr; 11-04-2019 at 04:03 AM.
 
Old 11-04-2019, 03:36 AM   #48
lioh
Member
 
Registered: Aug 2019
Location: Switzerland
Distribution: Slackware
Posts: 70

Rep: Reputation: Disabled
Thanks for the reply. I will wait for the updated version. As far as I understood this can only happen on the first run/migration to your script.
 
Old 11-04-2019, 04:04 AM   #49
luvr
Member
 
Registered: May 2005
Location: Boom - The Home Town of Tomorrowland, Belgium
Distribution: Slackware, Debian, Xubuntu
Posts: 323
Blog Entries: 1

Rep: Reputation: 136Reputation: 136
Quote:
Originally Posted by lioh View Post
Thanks for the reply. I will wait for the updated version. As far as I understood this can only happen on the first run/migration to your script.
Yes, that's correct.
 
Old 11-04-2019, 09:49 AM   #50
luvr
Member
 
Registered: May 2005
Location: Boom - The Home Town of Tomorrowland, Belgium
Distribution: Slackware, Debian, Xubuntu
Posts: 323
Blog Entries: 1

Rep: Reputation: 136Reputation: 136
UPDATE to my 'upgrade-kernel.sh' script: BUG FIX.

Attached to this post is the next update to my ‘upgrade-kernel.sh’ script. It fixes a bug where, the first time that it is run on a freshly installed Slackware system, it will create a broken symlink, such as:
Code:
initrd-*-prev -> initrd-*-4.19.81*
(where the version string, ‘4.19.81’, will be replaced by the actual kernel version, of course.)

To fix this bug, the script now sets the ‘nullglob’ shell option when it begins execution:
Code:
shopt -s nullglob
(Previously, this option got set in one of the functions defined in the script, but the function was called too late to prevent the broken symlink.) As the bash man page explains, the ‘nullglob’ shell option allows patterns that do not match any files to expand to a null string, rather than themselves.

As before, only the main script, ‘upgrade-kernel.sh’, is required.

Helper scripts ‘fix-kernel-symlinks.sh’ and ‘rebuild-kernel-initrd.sh’ let you recreate the symbolic links to the installed kernel files and rebuild the initrd, respectively, just in case.
Attached Files
File Type: txt upgrade-kernel.txt (94.2 KB, 4 views)
File Type: txt fix-kernel-symlinks.txt (13.1 KB, 1 views)
File Type: txt rebuild-kernel-initrd.txt (14.7 KB, 2 views)
 
Old 11-05-2019, 06:07 AM   #51
lioh
Member
 
Registered: Aug 2019
Location: Switzerland
Distribution: Slackware
Posts: 70

Rep: Reputation: Disabled
Thanks for the update. I am still thinking if there is a better way to handle System.map files. I have opened another thread to clarify this topic https://www.linuxquestions.org/quest...53#post6054053

Right now you are creating symlinks System.map-generic, System.map-generic-prev, System.map-huge and System.map-huge-prev. None of them will be used e.g. by klogd. It is okay to manually create a symlink System.map pointing to the correct version if debugging is necessary, but maybe a convenient default could be added. E.g. if a default kernel is set in lilo.conf an according System.map symlink could be created.

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.
 
1 members found this post helpful.
Old 11-05-2019, 09:16 AM   #52
luvr
Member
 
Registered: May 2005
Location: Boom - The Home Town of Tomorrowland, Belgium
Distribution: Slackware, Debian, Xubuntu
Posts: 323
Blog Entries: 1

Rep: Reputation: 136Reputation: 136
Quote:
Originally Posted by lioh View Post
Thanks for the update. I am still thinking if there is a better way to handle System.map files. I have opened another thread to clarify this topic https://www.linuxquestions.org/quest...53#post6054053

Right now you are creating symlinks System.map-generic, System.map-generic-prev, System.map-huge and System.map-huge-prev. None of them will be used e.g. by klogd. It is okay to manually create a symlink System.map pointing to the correct version if debugging is necessary, but maybe a convenient default could be added. E.g. if a default kernel is set in lilo.conf an according System.map symlink could be created.
Hmmm... I don’t think I would have my script look into the ‘lilo.conf’ file, if only because I don’t use it. (Furthermore, when you run ‘/sbin/lilo’, you can specify a different configuration file, so, I cannot even be sure that ‘/etc/lilo.conf’ will be the right place to look.)

Having said that, creating a ‘System.map’ link does sound like a good idea that I may want to look into—perhaps by looking at the type of kernel that is currently running and using that to determine the target for the link?

Quote:
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.
Sorry, but for now, that is something that I won’t implement, because all my computers run Legacy BIOS. The only UEFI computer that I’m supporting currently, is my dad's laptop, which dual-boots Ubuntu and Windows 10 (although he appears to be using Windows 10 less and less; I think he needs it only to update his TomTom GPS these days).
 
Old 11-06-2019, 04:22 AM   #53
lioh
Member
 
Registered: Aug 2019
Location: Switzerland
Distribution: Slackware
Posts: 70

Rep: Reputation: Disabled
Quote:
Originally Posted by luvr View Post
Sorry, but for now, that is something that I won’t implement, because all my computers run Legacy BIOS. The only UEFI computer that I’m supporting currently, is my dad's laptop, which dual-boots Ubuntu and Windows 10 (although he appears to be using Windows 10 less and less; I think he needs it only to update his TomTom GPS these days).
Fair enough, I just got some deviced which do not support Legacy Boot anymore (UEFI-only). Currently I use a custom kernel on that so it's not so relevant to me.
 
Old 11-07-2019, 01:06 PM   #54
denydias
Member
 
Registered: Dec 2013
Distribution: Slackware
Posts: 149

Original Poster
Rep: Reputation: Disabled
Now that Linux kernel 5.4-rc6 has arrived in -current testing, there is a new case where my upgrade script failed. I have managed to correct it. The corrected revision is here.
 
1 members found this post helpful.
Old 11-07-2019, 01:20 PM   #55
lioh
Member
 
Registered: Aug 2019
Location: Switzerland
Distribution: Slackware
Posts: 70

Rep: Reputation: Disabled
@luvr I have one question on how you handle the -prev Kernels. E.g I had both 4.19.80 and 4.19.81 installed. After the upgrade to the 4.19.82 Kernel from today, the -prev links has been set up to point to 4.19.80. Is there a reason why they did not point to 4.19.81?
 
1 members found this post helpful.
Old 11-07-2019, 01:29 PM   #56
luvr
Member
 
Registered: May 2005
Location: Boom - The Home Town of Tomorrowland, Belgium
Distribution: Slackware, Debian, Xubuntu
Posts: 323
Blog Entries: 1

Rep: Reputation: 136Reputation: 136
Quote:
Originally Posted by lioh View Post
I had both 4.19.80 and 4.19.81 installed. After the upgrade to the 4.19.82 Kernel from today, the -prev links has been set up to point to 4.19.80. Is there a reason why they did not point to 4.19.81?
Unless there's a bug in the script, you must have been running 4.19.80 at the time you ran the update. I reasoned that the "-prev" links should point to a kernel version that is known to work, so the currently running one looked like the most appropriate candidate to me.
 
Old 11-07-2019, 01:31 PM   #57
lioh
Member
 
Registered: Aug 2019
Location: Switzerland
Distribution: Slackware
Posts: 70

Rep: Reputation: Disabled
Quote:
Originally Posted by luvr View Post
Unless there's a bug in the script, you must have been running 4.19.80 at the time you ran the update. I reasoned that the "-prev" links should point to a kernel version that is known to work, so the currently running one looked like the most appropriate candidate to me.
Ah, think I was running a custom kernel while doing the upgrade. I think I have to monitor it a bit more.
 
Old 11-08-2019, 02:44 AM   #58
pr0xibus
Member
 
Registered: Apr 2004
Location: Montrose, Scotland
Distribution: Slackware
Posts: 161

Rep: Reputation: 24
Just out of curiosity whilst their is talk of updating.

I assume its perfectly normal / acceptable to have different versions of an application from 64 + multilib?


[ Status ] [ Repository ] [ Package ]
installed multilib mariadb-compat32-10.4.8-x86_64-1compat32
installed slackware64 mariadb-10.4.9-x86_64-1


On kernel talk

I assume (Again) best practice to keep the previous version + the new one so its easy to switch? Now apart from installing Slackware I don't have much knowledge on Kernels etc

On a new install I usually switch to a generic kernel / create an initrd and update elilo.conf.

If I upgraded to a newer kernel

[ Status ] [ Repository ] [ Package ]
upgrade slackware64 kernel-generic-4.19.81-x86_64-1 --> kernel-generic-4.19.82-x86_64-1

Do I need to create a new initrd based on the new generic kernel? If so how do I keep the old one for the older kernel?
If I dont need to create a new initrd I assume just copy over the kernel to /boot/efi/EFI/slackware and update elilo with the new details whilst keeping the old one?

Apologies if I have hijacked the thread, My previous thread contains my delight in gaming on slackware, and right now the whole slackware is in a nice state of play
 
Old 11-08-2019, 02:56 AM   #59
lioh
Member
 
Registered: Aug 2019
Location: Switzerland
Distribution: Slackware
Posts: 70

Rep: Reputation: Disabled
It would be better to open a new thread on this but in general you have to upgrade the initrd on every kernel update. The script luvr provided does support this scenario for lilo, not elilo. If you want to keep different Ramdisks in place you have to name them accordingly: initrd-generic-4.19.81.gz initrd-generic-4.19.82.gz and refer to them in your elilo.conf. If you don't care about keeping the old kernel and just want to make sure that the initrd is automatically created and copied over to the EFI partition, you might want to take a look at zerounos approach for slackpkg: https://www.linuxquestions.org/quest...0/#post5849061 (read the 1st post as well).
 
1 members found this post helpful.
Old 11-08-2019, 03:05 AM   #60
luvr
Member
 
Registered: May 2005
Location: Boom - The Home Town of Tomorrowland, Belgium
Distribution: Slackware, Debian, Xubuntu
Posts: 323
Blog Entries: 1

Rep: Reputation: 136Reputation: 136
Quote:
Originally Posted by pr0xibus View Post
Do I need to create a new initrd based on the new generic kernel?
Yes, you do.

Quote:
If so how do I keep the old one for the older kernel?
Just make sure you name it differently. For instance, use the kernel version as part of the name, or rename the old one to something like 'initrd-old' or some such.

Last edited by luvr; 11-08-2019 at 03:06 AM. Reason: Oops... I see lioh beat me to it.
 
  


Reply

Tags
kernel, lilo, slackware -current, sysadmin, upgrade


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Upgraded distro which upgraded perl and modules from old version not transferred to new. systemlordanubis Linux - Software 1 03-25-2018 04:37 AM
[SOLVED] slackpkg+: how to keep one package in slackware being upgraded by a 3rd party repos? michaelslack Slackware 9 12-15-2014 07:28 AM
[SOLVED] keyboard stopped working in X when I upgraded udev from 1.75 to 1.82After I upgraded RandomTroll Slackware 3 07-26-2012 03:48 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 07:50 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration