Slackware-Current

[Zema Bus]

I have Slackware back! The installer kept selecting the wrong EFI partition, the one from Arch, and I didn't want it touching that so I did not let it install elilo. At the end of the installation I dropped back out to the console chrooted into /mnt (the new install root still mounted by the installer) and edited fstab, umounted /boot/efi then mounted the correct partition to /boot/efi, and then ran eliloconfig. That fixed it. It also shows up in the motherboard's UEFI menu. The last time I installed Slackware I had to manually format the EFI partition, and I had to do that again this time. I don't know why the installer kept insisting on using another drive's EFI partition. I have lots of work to do on it, including installing Grub. I did get my data drive mounted already.

[Grogan]

UEFI sure is a stupid way to boot. While it gets rid of some legacy limitations, it's a regression in other ways. Imagine, an operating system's boot loader can screw up EFI boot entries so bad you can't boot anything. Nope, no legit way to clear that data. A BIOS flash might erase that NVRAM. (CMOS clear jumper doesn't). That royally pissed me off, efibootmgr (grub uses that to write to NVRAM) corrupting my boot data. (I wonder if that's fixed after 3 years of bios updates... don't want to find out)

You SHOULD be able to use the same EFI partition and that would be the the correct thing to do, moreover, I would only want one boot loader installed. EXCEPT, that Arch symlinks the EFI partition to /boot in an EFI setup.

P.S. I meant to say, if you have your Arch booting with Grub, and you have your Slackware booting with elilo, I wouldn't install Grub in Slackware. Leave it alone. Moreover, Grub isn't very well supported in Slackware, elilo is the recommended boot loader for EFI.

[Grogan]

Here's another wonderful thing about UEFI bioses. They can be easily compromised. First of all, shit can be dumped in the EFI partition. One example is the boot logo image file, some biosen copy that there and it's read from there at boot time. Guess what? The image loaders use vulnerable code that can execute code to run in the UEFI bios. Unlike CIH of the 90's that simply corrupted the bootstrap routine, these UEFI bioses can run infected code. Format your hard drive until blue in the face, the BIOS has been altered. Oh, and Secure Boot doesn't check things like that (logo image) and has nothing to do with the BIOS itself.

BIOS doesn't store the image file in the EFI partition? No problem, another vector is the vendor's own BIOS flash updaters. You know, the kind that run in Windows or through Windows update. Guess what's not verified by checksum? That's right, the logo image, because it's vendor customizable

One would think that turning off the boot logo would fix it, but here's the thing about low level programming... it would be just as likely that it parses the data anyway and just doesn't display it. It'll be something probably read at the same time as other data, before the decision.

I don't see any mention of this fix in any of MSI's BIOS updates. Maybe they silently fixed it, or maybe not. It was common code (the image parsers).

P.S. I just read that MSI boards were not vulnerable to this (it's called "LogoFail") because they don't allow the logo to be changed. It's part of the BIOS image. I always disable boot logos though, I hate them. Fast boot too, I hate that. I want it to initialize hardware properly on every boot (it does not actually cut any perceptible time on my rig anyway)

[Zema Bus]

Yeah I read about LogoFail a while back.

Looks like Pat is planning to move to Grub for Slackware 15.1:

slackware_grub.jpg (65.6 KiB) Viewed 116782 times

From Linuxquestions.org

[Grogan]

Ahh good then. It used to be "good luck with grub"

Grub is more practical. It evidently can be trouble though, on some EFI bios implementations (cough, cough) with its efibootmgr back end.

I personally see no benefit in booting through EFI. Enabling CSM mode doesn't change your whole bios or anything, it just allows booting using old school methods too. Because I'm going old school I kept the MBR partition tables, but I still could have still used GPT partitions (or use LVM) for most all of the disk and eliminated the need for extended partitions, but why mess about doing complicated things for mostly cosmetic reasons.

[Zema Bus]

I was looking at the Slackware-Current changelogs and noticed he switched from the LTS kernel to the latest mainline kernel, and from Firefox ESR to the regular release channel. I don't use either Slackware's kernel or Slackware's Firefox package so it doesn't affect me, but I'm curious why he switched those packages back. Seems like he did that before, around the time of Slackware 15's release.

[Grogan]

LTS stuff bites the weenie. In the kernel case, you don't get new drivers and you often get backported breakage anyway that has to be reverted in another point release. For Firefox, you don't get performance enhancements or new features.

[Zema Bus]

Slackware-Current is no longer using the huge kernel, so on a fresh install it will have an initrd by default. I don't use an initrd in Slackware.

Fri Sep 13 01:32:33 UTC 2024
a/kernel-firmware-20240912_b9daf8c-noarch-1.txz: Upgraded.
a/kernel-generic-6.10.10-x86_64-1.txz: Upgraded.
The kernel modules are now bundled into this package.
a/kernel-huge-6.10.9-x86_64-1.txz: Removed.
So long, we won't miss you.
If you were actually using kernel-huge with one of the SCSI/SAS drivers that
were built in, you'll need to use kernel-generic and an initrd that contains
the needed drivers. Otherwise, just switch to kernel-generic. It'll be fine.
If unsure, make an initrd with geninitrd and have your bootloader use it.
a/kernel-modules-6.10.9-x86_64-1.txz: Removed.
Kernel modules are now bundled with the kernel-generic package.

And he added Redhat's dracut:

a/dracut-103-x86_64-1.txz: Added.
This is Red Hat's tool to generate an initramfs (aka initrd). Around here,
we try not to suffer from Not Invented Here Syndrome (some might say the
less we invent, the better . It never hurts to have additional options,
and it even looks like our old friend David Cantrell is on the AUTHORS list.
I've had good luck here with:
dracut --hostonly --force /boot/initrd-6.10.11-generic.img
Thanks to Didier Spaier for convincing me to try it out.

[Grogan]

Slackware is no longer Slackware. R.I.P. as far as I'm concerned.

[Grogan]

By the way, I remember David Cantrell. That was back when WindRiver was paying these guys. I spoke with him on IRC a few times.

The problem with Slackware is that now it has so much junk to keep up with the jones's yet it's unmanageable apart from installing most of the distro and updating with slackpkg etc.

[Zema Bus]

I went to download the latest kernel via wget, but it wasn't responding. I finally gave up and used my browser to download it. Then when updating Slackware the mirror was hanging, so I tried multiple others and they all were hanging (at connecting to the mirror). Sometimes it times out and retries, but it's always very slow. Once connected it downloads the package OK, but then it has to reconnect for the next package, and takes forever again to reconnect or timeout. It's not my connectivity or the mirrors themselves, I can bring up those mirror paths instantly in Firefox. I don't think it's slackpkg either since I was having the same problem with wget.

[Grogan]

Well, slackpkg uses wget, it's just a bunch of scripts that automates downloading and the pkgtools operations

wget should be just like downloading it with a browser, but it's possible it's causing timeouts or something because it's not sending requests the same way. Or maybe it needs a recompile. Try compiling the .SlackBuild for it. (source/n/wget)

Actually I just had a bit of a pore over it and it looks like it will take a DOWNLOADER environment variable, so it's probably a setting in a configuration file somewhere. It looks like it can take either curl or wget. Or you could export it. This is from its core functions file:

Code: Select all

function system_setup() {

	# Create $WORKDIR just in case
	mkdir -p "${WORKDIR}"

	# Select the command to fetch files and packages from network sources
	if [ "$DOWNLOADER" = "curl" ]; then
		DOWNLOADER="curl ${CURLFLAGS} -o"
	else
               	DOWNLOADER="wget ${WGETFLAGS} -O"
	fi

	# Set LOCAL if mirror isn't through network 
	#
	MEDIA=${SOURCE%%:*}
	if [ "$MEDIA" = "cdrom" ] || [ "$MEDIA" = "file" ] || \
	   [ "$MEDIA" = "local" ]; then
		SOURCE=/${SOURCE#${MEDIA}://}
		LOCAL=1
	else
		LOCAL=0
	fi

e.g. export DOWNLOADER="curl" then run slackpkg from the same terminal, or probably even prepend it. DOWNLOADER="curl" slackpkg

[Zema Bus]

I didn't know that, thanks Grogan I'll give that a try

[Zema Bus]

I completed the updates using curl as the downloader. Then tried fixing wget - first I tried reinstalling it, which didn't change anything, then I recompiled it. It still times out. I didn't find much about this on the Slackware forum but I did find this recent thread about slackpkg timing out. I couldn't find a conf for slackpkg where the variable of $DOWNLOADER can be set, just what you found that specifies what flags to use depending on how it is set. I tried wget2 too, but it also times out. I wonder if I could just add the line $DOWNLOADER" = "curl" to the core functions file. Otherwise I can just continue to set it before running slackpkg.

[Grogan]

Sure you could, in core-functions.sh, replace this:

Code: Select all

# Select the command to fetch files and packages from network sources
	if [ "$DOWNLOADER" = "curl" ]; then
		DOWNLOADER="curl ${CURLFLAGS} -o"
	else
               	DOWNLOADER="wget ${WGETFLAGS} -O"
	fi

With simply this:

Code: Select all

DOWNLOADER="curl ${CURLFLAGS} -o"

[Grogan]

Or... you could simply export the variable in /etc/profile (or in one of the .sh files in /etc/profile.d) or anywhere you set shell variables, really. For example in root's .bash_profile
But in that case, you would want to do only: export DOWNLOADER="curl" as that's what the script is checking for.

That would be the legitimate way to do this. The other way, hacking the script, would get clobbered when slackpkg itself gets updated.

[Zema Bus]

I'll give that a go

[Zema Bus]

I added DOWNLOADER="curl" to a couple different locations including /etc/profile, but slackpkg still times out. Just to be sure, I tried exporting it from the terminal again before running slackpkg, and it STILL times out. That worked great earlier today. I have no clue what's going on.

[Grogan]

So it isn't just wget. The difference with the browser is that it could be keeping the connection open, with http keepalives or something.

[Zema Bus]

I compiled slapt-get, configured it with my mirror and blacklists, and did a sync. It seems to be working.

[Zema Bus]

I've played around with it a bit, tested updating and downloading a random package, it's pretty quick. I used slapt-get years ago in a Slackware based distro.

[Grogan]

As long as it downloads and installs the packages. Looking at the sources (it's a compiled program with libraries), it looks like it uses libcurl at the back end.

[Zema Bus]

Since I've been tired of the old and stale in Slackware-Current, particularly Plasma 5 after being used to Plasma 6 in other distros, I decided to try the Plasma 6 binaries maintained by LuckyCyborg in the Slackware forums. I followed all the steps and everything seemed to work as expected, until it came time for startx. I got the initial Plasma loading screen with the turning gears, but it stayed on that screen for much longer than normal. Finally that went away and then I was left with nothing but a blank screen with my mouse pointer. I tested it with root just in case it was just corruption in my user settings but I had the same result there.So, I got XFCE working. I had installed it previously but it wouldn't launch at that time. It was just missing some dependencies and launches now. The configuration needs a bit of work but at least I have that. It's the latest XFCE released last December.

[Grogan]

I guess he's not so lucky

Something might need a recompile (how current are they?) or it may be it's not being launched correctly. If you're just typing "startx" there would need to be a proper global xinitrc.kde with the proper command (e.g. launching it in a dbus session) and a symlink to it, xinitrc.

Maybe try making your own .xinitrc in your home directory, with the command:

Code: Select all

exec dbus-launch --exit-with-session startplasma-x11

[Zema Bus]

Thanks I'll give that a try. I used xwmconfig.

[Zema Bus]

Hey that worked! I commented out what was already in there and added the 'exec dbus-launch --exit-with-session startplasma-x11' line below it:

Code: Select all

# Start the window manager:
# if [ -z "$DESKTOP_SESSION" -a -x /usr/bin/ck-launch-session ]; then
#  ck-launch-session dbus-launch --sh-syntax --exit-with-session startplasma-x11
# else
#  dbus-launch --sh-syntax --exit-with-session startplasma-x11
# fi

exec dbus-launch --exit-with-session startplasma-x11

All my configurations from Plasma 5 carried over.

plasma6slackware.jpg (86.48 KiB) Viewed 17068 times

[Zema Bus]

I had a similar issue to the one mlangdn had with spectacle not launching, except in my case it was missing libopenblas.so.0, but that was easily resolved by installing openblas-0.3.29-x86_64-3.txz.

[Grogan]

So it's probably that Console Kit was installed, but not working correctly for you. (if DESKTOP_SESSION is not set, or empty... check. If ck-launch-session is a file and is executable... check. It then runs dbus-launch through console kit. (Umm, why?)

Secondly, the last command in xinitrc has to have exec. To my knowledge, it won't start the window manager because it's expecting more commands first. But it must work for somebody with startplasma-x11 otherwise it wouldn't be configured like that. I wouldn't do that.

Moreover, I don't use system wide xinitrc files, I always use my own. I hate session managers, so I made a login script to choose my environment, called from ~/.bash_profile (so this won't run when I pop open a VT)

Code: Select all

#! /bin/bash

cd $HOME

while true; do
read -p "Which desktop to start?
a) IceWM
b) Trinity Desktop
c) XFCE
d) Cosmic Desktop
e) console
---> " abcde
case $abcde in
        [aA]) echo "Starting IceWM...";
               ln -sf .xinitrc-icewm .xinitrc;
               startx;
               break;;
        [bB]) echo "Starting TDE...";
               ln -sf .xinitrc-tde .xinitrc;
               startx;
               break;;
        [cC]) echo "Starting XFCE...";
               ln -sf .xinitrc-xfce .xinitrc
               startx;
               break;;
        [dD]) echo "Starting Cosmic...";
               start-cosmic;
               break;;
        [eE]) echo "gimme a console...";
               break;;
           *) echo "He chose... poorly.";;
esac
done

exit 0

I have different commands in the ~/.xinitrc files for each desktop, for example I start icewm like this:

Code: Select all

export ICEAUTHORITY=/home/grogan/.ICEauthority
xrandr --rate 180
/home/grogan/.config/xsetoff
# xinput set-prop 10 "Coordinate Transformation Matrix" 2 0 0 0 2 0 0 0 1

exec icewm-session

I don't have Cosmic at this time, but I left it in as a placeholder because I will have it again when it's more stable.

P.S. That's very good that it migrates your Plasma 5 settings, because that's a bitch to find and remove everywhere it defecates in your home directory (It makes a shitting mess of ~/.config but other places too... I hunted and poked for all that stuff after removing Plasma in Manjaro. I still have the same /home/grogan/.config directory copied here, I don't want a mess in there. It's one of the reasons why I won't install Plasma again)

[Zema Bus]

I like your DE login script

[Zema Bus]

Well Slackware is no more. I've been using Slapt-get ever since slackpkg stopped working last November, and it has worked OK. I ran updates today and afterwards I had complete breakage. From some of the errors I was initially seeing I thought it was just that it failed to install glibc-solibs. I had read that slapt-get installs that properly though. So I got the latest Slackware-Current glibc-solibs package and booted with the Slackware install media to see if that would be enough to fix it. But it's far much worse than just that. I tried booting into it even though I knew I probably wouldn't get very far, and it quickly stopped at a kernel panic. Not worth wasting any more time on. It's time to launch gparted and shoot it in the head. I did backup my most recent kernel, modules, and kernel config before hand but I'm not sure what I'm going to do yet.