Not really a bug, but looking at the root of Slackware File Trees as well as that of installation DVD ISOs, one can see that the file FAQ.TXT is included in the 32-bit editions but not in the 64-bit ones.

I'm not requesting a "fix" (this file is slightly outdated anyway), just wondering why this difference exists.

Admittedly I could have noticed that earlier, as this has been the case since the first release of a 64-bit edition, i.e. Slackware64 13.0. My excuse is that I just came across that difference looking at what files I should ship in the "full" (read: including the Slackware packages) Slint installers.

PS Maybe we could organize next year, instead of (or in addition to) the Easter Eggs Hunt, an Old Slackware Bugs Hunt, whose first prize would be, if he agrees, a Slackware DVD autographed by Patrick J. Volkerding.

Of course we would need a Jury and Regulations for such a contest.

One very tiny detail: in /isolinux/README.TXT we are advised to use the following command to process an ISO image, to make it bootable when written to an USB stick:
But some BIOSes aren't able to boot a device with more than 1024 cylinders. So the following command would be safer for instance:

where X is the number of default geometry sectors and Y the number of default geometry heads, computed with a sector length of 512 bytes, in such a way that:S being the size in bytes of the ISO image.

Knowing that the maximum number of sectors is 63, X could be set to 63. Then Y should be greater than:
S / 63 * 512 *1024
or:
S / 33030144

As an example,the size of slackware-14.1-install-dvd.iso is 2502936576 bytes and (roughly) 2502936576 / 33030144 = 75.7, so to be safe one could write:
Not sure it's worthwhile to mention that in README.TXT, but then with a less convoluted explanation

This happened to me, but just once and I didn't pay any attention to it.... Redoing the setup worked (for some reason)... Just be careful, neither Lilo nor Grub can be installed without a separate /boot (on a different file system) on btrfs (at least it didn't work for me when I tried it), which in turn will require a generic kernel... And busybox's findfs (used in the init script of initrd) won't find a partition by UUID for btrfs (which is the default way to install in case you want to go with grub)..

WHERE did you get that???

Perhaps here:
http://slackware.org.uk/people/alien...urrent/4.14.1/


ediot:
Scratch that, I read something wrong.

I don't know if there is a difference between KDE 14.14.0 and 14.14.1 on that respect, but as anyway none of them is shipped in Slackware-current at time of writing, maybe lem's report would better be sent to Alien Bob, unless that behavior be reproducible using a desktop or windows manager shipped in Slackware-current.

Found a problem with dosfstools-3.0.22-x64_64-1
When you run fsck.fat and ask for it to prompt before repair it appears to do nothing.
When run in auto mode it functions as expected.

I recently had the dirty bit get set on my EFI/BOOT partition and efibootmgr quite correctly would not write to bios nvram with details of a 'bad' boot location.

Maybe build a package for dosfstools-3.0.26 available here and see if you observe the same behavior?

PS And maybe you could adopt it as it's orphaned?

PPS There seems to be a fork, but for OSX.