Thanks. Is it possible to build a slackware-current image, but substitute those into it instead? Any idea where I can find instructions?

Are you already running slackware-current?

Can't help with creating a current branch install medium, but:

You might try blacklisting the Kernel packages so the newer one you are about to install doesn't get overwritten.

Also, if you want to grab individual packages from another branch, just blacklist them as well, and retrieve them from a -current mirror.

You can edit /etc/slackpkg/mirrors and uncomment a -current mirror as well, but the next time you run slack update, it is going to try to grab every updated package from -current, which might not be ideal.

No, not running slackware-current, just 14.2. But, I just built a new current ISO.

I know it's not ideal, but I usually install a given slackware release, and then only update nvidia drivers and anything that I need updated. I know I *SHOULD* be following security patches (I got as far as setting up a crontab to download current patches), but I always get lazy somewhere along the way. So, I don't really need to blacklist anything..

I know, I keep telling myself THIS time is the time I'll get serious about installing updates.. :-)

It's super easy unless you are on a slow-ish connection. I'm sure you know this, but:

I just stick these in a shell script, and it takes about 2 minutes.

But of course, this is not Win32 land, and you can decide to skip all updates if you wanna.

As for blacklisting the kernel, this is from the original /etc/slackpkg/blacklist file:

With a stable release, you should never need to run slacpkg install-new. Pat doesn't add new programs to a stable release. It doesn't really hurt to do it, but it is unnecessary. You only need to worry about install-new when tracking -current or upgrading from one stable release to the next.

1 members found this post helpful.

I've just checked my notes, and if anyone is interested in the NVMe bootloader info, here you go:

1) Obtain GRUB 2.02b3.
I think slackware-current has this package right now, but didn't when I had to do this. Failing that; compile newest grub from source.

2) The "grub-install" script can have trouble with odd paths for NVMe drives, so i run "efibootmgr" manually:

- The grubx64.efi (or the appropriate one for your arch.) must be inside the EFI partition. "/boot/efi/EFI/Grub/" works.

3) Either edit /boot/grub/grub.cfg by hand, if you are familiar with the syntax, and skip this part,

*or*

3a) Edit /etc/default/grub

3b) Do this:
4) Caveats:

- You have to run efibootmgr *while in UEFI mode*. This means that you need to have logged onto your system. This is a bit of a problem when you can't boot in the first place. I do this either by the Slack install stick, or a fail-safe bootstick of my own making. You might also want to create en EFI partition on a USB stick, stick your favourite kernel in there, and install GRUB on it, for this eventuality. (UEFI updates of my motherboard erases the boot list, for instance).

- It's been about a year since I updated hardware and installed fresh Slackware, so if this doesn't work, let me know.

- It was extra frustrating fiddling with this, so I've decided to put this here for posterity. Good luck.

Good to know. Thanks. I think I found this info somewhere online. Maybe Slackdocs or such.

I feel like it has *maybe* installed something new at one point, but I'll defer to your experience. And I tend to do an incomplete install (some packages I never, ever use), so might be my own doing.

I guess I was wrong, although, I could only find two instances where it occurred, one in 13.1 and another in 13.37 (and I checked back to 12.0). Both happened because Ruby had a security update, but the newer version that fixed the CVE required a new dependency (libyaml). Both occurred in March of 2013 and no other versions of Slackware were affected.

Just goes to show you should always read the changelogs before you update your system

Ah I think I've used the 13 series, but probably wouldn't remember the instances you've mentioned. Like I said, I tend to fiddle with my config a lot, so it is likely a package I've either erased or haven't installed in the first place.

As long as we're on topic, I actually also make sure to have

at the top of that script. Maybe paranoid checking that every time, but the more I read about GPG keys and their purpose...

Fat_Elvis,

You should probably do a bit more reading on GPG keys. You do not want to be updating the gpg key. You should do that once when you setup a new system. If you update the key every time you use slackpkg, you are actually greatly reducing the security the key offers.

The key is used to verify the packages and meta data in the repository. It should not change but you need to get an initial copy of the public key to be able to check the signatures in the first place. If the key does change, without some announcement on the official pages etc, it would be time to start asking questions!

If someone compromised the repo and wanted to push malicious package content they will be mostly unable to do so because they won't have the private key and won't be able to sign packages correctly. What they could do is generate a new key pair and replace the public key in the repo as well, that would allow them to push packages to new users or people who are doing what I think you might be doing and updating the key every time. You'd get the new (evil) key and your system would than trust the package content.

This is supposed to work kinda like the SSH host key model. You sort of take it on faith the first time you connect you are really talking to the intended system. If someone does something along the way and the host key changes it might be that your network, or the remote system has been compromised or replaced with something different.

TLDR: Do as a the man page says:

before attempting to upgrade, install, or search for packages. If you need to update Slackware's GPG key run,
# slackpkg update gpg
The GPG key doesn't change. This should be a "one time" command - run it once and forget it...

4 members found this post helpful.

Thank you for the excellent info.

My rationale was to keep up if the GPG key changed without my knowledge.

I have been researching some stuff about general security, and have been diligently verifying signatures of sources and executables I download. I obviously lack any meaningful knowledge in cryptography. It's something I would love to study at some point.

I was able to compile the latest kernel (4.9.something, at the time) with the kernel provided in slackware64-current. I think the recommendation is to disable SMT (Simultaneous Multi-Threading) in the UEFI, which will give you 8 physical CPU cores to use, compile & install the new kernel, then re-enable SMT to get the full 16 SMT cores.

JFYI - you don't need GRUB to boot from NVMe with Slackware64-current. It includes elilo and an updated setup utility, which can set up and boot Slackware from a NVMe devices.
It now works "out of the box". You might need some additional configuration on Slackware 14.2.

Glad to hear. I wasn't able to make elilo work correctly on 14.2.

Ok, so what are the steps to update the kernel with 14.2-current and UEFI?

I got a bootable "current" with the 4.9.37 kernel. Then I grabbed dusk's 4.12.2 kernel packages, installpkg'ed them, updated /boot and /boot/efi/EFI/Slackware (both with a new copy of vmlinuz and a new config), and then what? I tried re-running eliloconfig and that overwrote everything (I had two entries in the config file - "boot 4.9.37 or 4.12.2" - but didn't get a choice at boot-time). I think it tried to boot 4.12.2 but that kernel panicked when trying to boot.

I didn't see /sbin/elilo or similar. If I'm UPDATING my EFI config, but not installing for the first time, do I still use eliloconfig? What options? I just picked "install" and "overwrite", assuming that was the correct thing, but it doesn't appear to be. With regular lilo, I'd just run /sbin/lilo to update the bootloader..

What's the "disable SMT" option called in the bios, usually?

I guess I'll see if I can do a full "legacy" boot and just stick with old fashioned lilo.. Tried googling it, but very little documentation on elilo. Or, compile 4.12.2 myself..

Or do I need to look at efibootmgr?

Edit: Ok, I think I found out how to do a legacy-style boot. Much more straightforward now.

1. As root type:
   Code:

   ln -sf /boot/vmlinuz-<newkernel> /boot/vmlinuz
   ln -sf /boot/<newinitrd> /boot.initrd.gz # If you need an intrd, else re(move) any existing symlink /boot/initrd.gz

2. As root type
   Code:

   eliloconfig

The step 1. is necessary because eliconfig copies /boot/vmlinuz (and /boot/initrd.gz if it exists) in the directory /boot/efi/Slackware and writes the config file /boot/efi/Slackware/elilo.conf accordingly.

eliloconfig also copies in /boot/efi/Slackware /boot-elilo-x86_64 renamed elilo.efi. This file which will serve as a bootloader, so there is no need to write a boot sector as does lilo.

In case you wonder, the bootloader elilo.efi needs to have all needed files (elilo.conf, kernel, initrd) in the directory where it is installed, which should be inside an EFI System Partition aka ESP, equipped with a FAT file system.

Have a look at /usr/sbin/elilconfig and the documents in /usr/doc/elilo* to know more.