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.
However, I will give you an example: several months ago I bought a second-hand HP ProLiant ML350p Gen 8. What happens is that the RAID and the SSD device names get swapped after install (sda <--> sdb). I got this problem with CRUX and with Slackware's generic kernel. However, Slackware's huge kernel works as expected, so I just stick to it. Yes, I know I can set UUID and this is something I will do in the future. But when you have just installed the OS on new hardware it gets a bit frustrating when sth like this occurs.
Honestly, before to become (also) a Slackware user, I have been an Ubuntu and openSUSE user since long time.
Do you know how is seen Slackware by a Linux user using casually a major Linux distribution? It's shocking! It's a bunch of bad practices and bad decisions. It's kinda like "I can't believe that's the legendary Slackware!"
Even for me, as a beginner on Slackware, was shocking that I have to manage manually my initrds and bootloader configuration update. Was a true WTF? And even more shocking for me was that some people take a pride for doing a script job! And don't let me start about the Pure ALSAcians, about the PulseAudio hatters, about LinuxPAM hatters who was plenty here 12 years ago. For me was like seeing with the jaws dropped: I hate this, I hate that, I hate everything! And it wasn't even invented systemd!
BUT, another thing which was shocking for me was the encouragement to use the storage devices by their devices.
Man, the UUIDs usage is generally promoted not because there are sadist people making Linux distributions, BUT because today are many motherboards (or even addon cards) which changes their storage device names even by changing on BIOS: IDE -> AHCI.
I know, I know that 30 years ago when some people here started to use Slackware 3.0 this does happened, BUT today happens often and the general accepted solution is the usage of UUIDs.
Nope, I do not believe that it's your fault - the Slackware should have been used UUIDs from start. Because, you know... it's considerably more robust.
Last edited by LuckyCyborg; 06-24-2023 at 06:46 AM.
Let's STOP blaming the users for the mess on kernels management from Slackware! NOPE, I do not believe that's the user(s) fault.
Instead, how about Slackware to do properly its job on kernels management?
IF even I, who is a geologist, I can fix the kernels management from Slackware, I am quite sure that for our BDFL will be work for an evening.
It is not my intention to blame someone, if I did so, I'm sorry.
It was just a hint that this problem is well known, and I'm sure there are few people out there able to fix it in a way...
but I'm using Slackware, may be I like it that way? May be I don't want the bleeding edge...
Some things in Slackware seems to be odd on the first view, but after a closer look they may turn out as a real advantage!
There are plenty of "Full Featured" distros, why should Slackware be a copy of that?
It is not my intention to blame someone, if I did so, I'm sorry.
The subject of this thread is a kernel panic generated by booting a properly upgraded set of kernel packages, because the AMDGPU driver. What you wanted to say with the slackpkg quote?
That the user should have NOT upgraded the kernels on Slackware 15.0, but to stay on the stock 5.15.19 ignoring the security updates?
Quote:
Originally Posted by gp.d
It was just a hint that this problem is well known, and I'm sure there are few people out there able to fix it in a way...
Well, I agree with you that it's well know that a new kernel can behave erratic, even it's on 118 release of its series...
BUT, the question is: what counter-measures did Slackware for situations when a broken set of kernel packages are pushed as update of -stable Slackware 15.0 ? It's acceptable to install updates on Slackware 15.0 and to end with a broken system?
I for one, I believe that the Slackware first of all should offer the ability to boot, even with the previous working kernel, and this without manual intervention and Voodoo incantations.
I hope that you will agree that's a big difference between "OMG! The system is broken, where I find the old kernels on internet?" and pushing the reset button then on the bootloader menu to chose the previous kernel.
Quote:
Originally Posted by gp.d
but I'm using Slackware, may be I like it that way? May be I don't want the bleeding edge...
Interesting! So keeping working a Slackware installation is... bleeding edge?
Umm, considering that's Schrodinger's Linux we talk about, well... yeah! A successful booting of Slackware kinda seems bleeding edge.
Quote:
Originally Posted by gp.d
Some things in Slackware seems to be odd on the first view, but after a closer look they may turn out as a real advantage!
What "real advantage" is on seeing kernel panics after a 100% correct made upgrade on a stable release? And WHAT IF the user has the single available computer this one with the broken Slackware installation?
BTW, I remember that 10 years ago I have somehow "managed" to broke my Slackware installation from the laptop which I have ported with me in a job trip. I was unable to use that computer for more than 2 weeks, until I have returned home.
So, I should consider this event an "real advantage" of Slackware?
Quote:
Originally Posted by gp.d
There are plenty of "Full Featured" distros, why should Slackware be a copy of that?
Interesting! So, a successful boot after a well made upgrade on a stable release should be something reserved to "Full Featured" distributions? We should take pride on that Slackware fails to boot and we should rush for old kernels on Internet?
Last edited by LuckyCyborg; 06-24-2023 at 07:53 AM.
Even for me, as a beginner on Slackware, was shocking that I have to manage manually my initrds and bootloader configuration update.
Having to configure the bootloader didn't bother me at all. I was used to doing that with Crux (which used LILO in those days). I still prefer it to having this sort of thing done by automated GRUB scripts behind my back. In the days when I used to use Debian in a multi-boot setup with Crux and LFS, Debian's grub scripts always messed up. In fact those scripts are one of the main reasons why I came to hate GRUB.
Having to make my own initrd was a minor shock, but then I discovered Patrick's diagnostic script which did all the heavy lifting for me.
Quote:
BUT, another thing which was shocking for me was the encouragement to use the storage devices by their devices.
Man, the UUIDs usage is generally promoted not because there are sadist people making Linux distributions, BUT because today are many motherboards (or even addon cards) which changes their storage device names even by changing on BIOS: IDE -> AHCI.
UUIDs are another thing I hate and I'm sure I'm not the only one. I always hated the fact that Debian and its derivatives use them. All UUIDs look the same to me: random strings of rubbish. You look at your fstab file and it doesn't tell you anything about your setup, whereas device names tell you exactly where everything is.
If it is true that motherboards will stop supporting fixed device names, then user-defined labels are the way to go, not UUIDs.
The subject of this thread is a kernel panic generated by booting a properly upgraded set of kernel packages, because the AMDGPU driver.
It was no kernel panic. Only an oops. Post #2 showed the oops appeared when the system had been up for 19.5 minutes. I guess it worked ok before startx. Not a big deal to handle.
OR it can be modified to use kernels (and initrds) with their full versioned names.
I think some people would like to simply copy {vmlinuz,initrd.gz}{,.old} manually to /boot/efi/EFI/Slackware without running eliloconfig or editing /boot/efi/EFI/Slackware/elilo.conf.
It was no kernel panic. Only an oops. Post #2 showed the oops appeared when the system had been up for 19.5 minutes. I guess it worked ok before startx. Not a big deal to handle.
I apologize for misunderstanding!
But does matter? Isn't a broken kernel?
You can guarantee that the next kernel update will not bless (some of) us with an old school kernel panic in all its glory?
BUT, the question is: what counter-measures did Slackware for situations when a broken set of kernel packages are pushed as update of -stable Slackware 15.0 ? It's acceptable to install updates on Slackware 15.0 and to end with a broken system?
For me, this is a solved problem. Just maintain a local archive when running slackpkg.
In etc/slackpkg/slackpkg.conf I have:
Code:
TEMP=/var/cache/packages$(/usr/bin/date +%Y%m%d)
and
Code:
DELALL=off
Easy enough to revert problematic new packages.
For maintaining the local archive, I run this script after the usual slackpkg dance.
Code:
#!/bin/sh
# Script to clean up /var/cache/packages* archive
# Remove any old files
rm /tmp/list*
# Get a list of *.t?z archive files
find /var/cache -name "*.t?z" > /tmp/list1
# Get a list of package names without build, arch, version
cat /tmp/list1 | rev | cut -d"/" -f1 | cut -d"-" -f4- | rev > /tmp/list2
# Get a list of dates
cat /tmp/list1 | cut -d"/" -f4 | sed "s/packages//" > /tmp/list3
# Paste the lists together
paste /tmp/list1 /tmp/list2 /tmp/list3 > /tmp/list4
# Sort the list by package name then date(reverse order)
sort --key=2,3r /tmp/list4 > /tmp/list5
# Get a list of packages with 2 later versions
awk '++dups[$2] > 2' /tmp/list5 > /tmp/list6
# Cut the first column from the list
cut -f1 /tmp/list6 > /tmp/list7
# Delete the older files
while read line; do
rm "$line"{,.asc}
done < /tmp/list7
# Clean up empty directories
## From 'man bash'
# When the globstar shell option is enabled, and * is used in a pathname expansion context,
# two adjacent *s used as a single pattern will
# match all files and zero or more directories and subdirectories.
# If followed by a /, two adjacent *s will match only directories and subdirectories.
shopt -s globstar
for f in /var/cache/packages*/**/; do
# [ -z $(ls -A "$f") ] may be better
if (( $(ls -1 "$f" | wc -l) == 0 )); then
rmdir "$f"
fi
done
shopt -u globstar
Quote:
while wondering where is their rescue live system.
Sorted. Just boot from the appropriate LILO entry to the installer..
You can guarantee that the next kernel update will not bless (some of) us with an old school kernel panic in all its glory?
No, I can't. But I don't think buggy "stable" kernels are the biggest problem. More often people forget to rebuild initrd or forget to prepare the boot loader. There some kind of scripted backup kernel management would be very useful.
Having to configure the bootloader didn't bother me at all. I was used to doing that with Crux (which used LILO in those days). I still prefer it to having this sort of thing done by automated GRUB scripts behind my back. In the days when I used to use Debian in a multi-boot setup with Crux and LFS, Debian's grub scripts always messed up. In fact those scripts are one of the main reasons why I came to hate GRUB.
I have used GRUB since so many years that I do not remember the count. And it never failed for me, even doing multi-boot.
BUT, I have always kept the operating systems fully apart and I have never used OS probing. When doing multi-boot, I have used a master GRUB installation on MBR, configured to chainload also various other partitions having their own GRUB installations. For example, if I will had your distros, I will have used Debian's GRUB as master on MBR, then CRUX and LFS having each one the bootloader installed in the partition.
Booting an operating system with the bootloader from another one is in my humble opinion a huge mistake which I have tried to avoid at all costs. Always.
Quote:
Originally Posted by hazel
Having to make my own initrd was a minor shock, but then I discovered Patrick's diagnostic script which did all the heavy lifting for me.
Trust me that no Ubuntu user ever messes with initrd. Many does not even have an idea what's an initrd and if they really uses an initrd. All is done by packages management.
So, I apologize, but I do not understand the pleasure of making manually an initrd. For me, it's just a waste of time and supplemental complication. And worst than this, its a prone for errors complication.
Quote:
Originally Posted by hazel
UUIDs are another thing I hate and I'm sure I'm not the only one. I always hated the fact that Debian and its derivatives use them. All UUIDs look the same to me: random strings of rubbish. You look at your fstab file and it doesn't tell you anything about your setup, whereas device names tell you exactly where everything is.
If it is true that motherboards will stop supporting fixed device names, then user-defined labels are the way to go, not UUIDs.
Mrs. Hazel, the UUIDs aren't supposed to be readable for humans, but to be unique. And with all respect, the /etc/fstab is not a poem. And neither it's modified often.
I for one I am habituated with the UUIDs since beginning and I do not see them as a complication - on contrary I appreciated their uniqueness. True, I do use also the labels, but not for identifying the partitions for booting or mounting, but rather for identifying their purpose.
To match the UUIDs with their device names and purpose is very simple for me with blkid and/or cfdisk. Even for you is too - please look carefully at the attached screenshot and tell me for what is the currently selected partition.
It's very simple to use always UUIDs if you are willing to learn 5 minute and to find a workflow which you like.
Last edited by LuckyCyborg; 06-24-2023 at 09:20 AM.
More often people forget to rebuild initrd or forget to prepare the boot loader. There some kind of scripted backup kernel management would be very useful.
BUT, I have always kept the operating systems fully apart and I have never used OS probing. When doing multi-boot, I have used a master GRUB installation on MBR, configured to chainload also various other partitions having their own GRUB installations. For example, if I will had your distros, I will have used Debian's GRUB as master on MBR, then CRUX and LFS having each one the bootloader installed in the partition.
Yes, chainloading would have been a solution. But see how complicated that solution is conceptually. "One bootloader to rule them all, one bootloader to find them." is easier to understand. I could update LILO reliably from both Crux and LFS and it would then boot Debian too. LFS officially uses a simplified form of GRUB without automated scripts, but I preferred to build LILO from the Crux sources and use that. The fact that Debian preferred to use GRUB was a considerable nuisance to me. When it worked at all, the next boot would be done by GRUB and I then had to reinstall LILO from one of the other distros. Then at one point OS-prober started choking on my various lilo.conf files (what sort of crazy idea was it to make a script read those and draw conclusions from them???) so GRUB didn't get updated/installed any more. And that was fine by me.
Quote:
Trust me that no Ubuntu user ever messes with initrd. Many does not even have an idea what's an initrd and if they really uses an initrd. All is done by packages management.
That's what I don't like about distros like Ubuntu. You never get to learn anything about how your system actually works.
Quote:
Mrs. Hazel, the UUIDs aren't supposed to be readable for humans, but to be unique. And with all respect, the /etc/fstab is not a poem. And neither it's modified often.
I for one I am habituated with the UUIDs since beginning and I do not see them as a complication - on contrary I appreciated their uniqueness. True, I do use also the labels, but not for identifying the partitions for booting or mounting, but rather for identifying their purpose.
Unique IDs are important in a server farm where disks may be mounted in different places. It's not important on a home desktop.
Quote:
To match the UUIDs with their device names and purpose is very simple for me with blkid and/or cfdisk.
Yes, I know about those. But see what you did there? I have to use another command to clear up an obfuscation that wasn't necessary in the first place!
Quote:
Even for you is too - please look carefully at the attached screenshot and tell me for what is the currently selected partition.
If it's somebody else's machine, then neither UUIDs nor device names will tell you what purpose the partitions actually serve (although labels will if they are well-chosen). But I have a mental image of my own drive, which has 10 active partitions at the moment plus a lot of space at the end, and I know where everything is.
I thought it was always recommended practice to keep a working kernel, regardless of distro? (In the slackdocs on kernel administration, I believe.) Aren't the kernel packages blacklisted by default in slackpkg's configs? (Not that we haven't all made the same mistake as the OP at least once...or forgotten to run /sbin/lilo, grubconfig, or what have you.)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
