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.
More of a question than a suggestion, but i've noticed a few times over the months, many projects require openssl 1.1.x to compile.
Slackware -current ships with openssl 1.0.2o.
Each time i've opened an issue on any relevant projects to mention compiling issues related to openssl, the authors usually state 1.0.2o is outdated, citing that 1.1.x has even made it to Debian stable and it's time to move on.
Is there any specific reason why Slackware still has openssl 1.0.2o?
Maybe because 1.0.2o is, as stated on openssl website, the LTS release :
Quote:
Note: The latest stable version is the 1.1.0 series. The 1.0.2 series is our Long Term Support (LTS) release, supported until 31st December 2019. The 0.9.8, 1.0.0 and 1.0.1 versions are now out of support and should not be used.
--- SeTEFI 2018-05-01 21:23:44.655398066 +0200
+++ SeTEFI.new 2018-05-01 21:25:30.158403785 +0200
@@ -8,19 +8,15 @@
touch $TMP/SeTefipartitions
# Scan for EFI partitions:
-# We accept at most 10 NVMe controllers, each controlling at most 4 SSDs
-for drive in sda sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl sdm sdn sdo sdp \
- mmcblk0 mmcblk1 mmcblk2 mmcblk3 mmcblk4 mmcblk5 mmcblk6 mmcblk7 mmcblk8 mmcblk9 \
- nvme0n1 nvme1n1 nvme2n1 nvme3n1 nvme4n1 nvme5n1 nvme6n1 nvme7n1 nvme8n1 nvme9n1 \
- nvme0n2 nvme1n2 nvme2n2 nvme3n2 nvme4n2 nvme5n2 nvme6n2 nvme7n2 nvme8n2 nvme9n2 \
- nvme0n3 nvme1n3 nvme2n3 nvme3n3 nvme4n3 nvme5n3 nvme6n3 nvme7n3 nvme8n3 nvme9n3 \
- nvme0n4 nvme1n4 nvme2n4 nvme3n4 nvme4n4 nvme5n4 nvme6n4 nvme7n4 nvme8n4 nvme9n4 ; do
- gdisk -l /dev/$drive 2> /dev/null | grep -w EF00 | while read efisp ; do
- p=""
- echo $drive| grep -q nvme && p="p"
- echo /dev/$drive$p$(expr $(echo "$efisp" | cut -b 1-4)) >> $TMP/SeTefipartitions
- done
-done
+# The UEFI specification states that an EFI System partition should have
+# a GUID of C12A7328-F81F-11D2-BA4B-00A0C93EC93B for a GPT disk layout.
+# In case of a MBR disk layout instead, an ESP should have an OS type of
+# 0xEF. lsblk writes these values in the same field: PARTTYPE.
+ESPGUID=C12A7328-F81F-11D2-BA4B-00A0C93EC93B
+OSTYPE=0xEF
+lsblk -l -o parttype,name|\
+grep -i -F -e "$ESPGUID" -e "$OSTYPE"|\
+sed "s,[^ ]* ,/dev/," > $TMP/SeTefipartitions
if [ "$(cat $TMP/SeTefipartitions)" = "" ]; then # No EFI partitions
rm -f $TMP/SeTefipartitions
PS The (unmodified by the patch) test could be replaced by:
Code:
if [ ! -s $TMP/SeTefipartitions ]; then # No EFI partitions
rm -f $TMP/SeTefipartitions
exit
fi
But the BDFL like the cats
PPS Oh, and testing made me discover the really great script build_installer.sh. Congrats!
As an aside, I will post other patches if I find other scripts in the installer that could make use of lsblk, which really provides a lot of information.
Last edited by Didier Spaier; 05-01-2018 at 02:35 PM.
Reason: Useless line manually removed from the script broke the diff, now rebuilt.
Please have a look at this KDE bug report which does not affect Slackware itself but may affect 3rd party KDE Plasma5 packages if a kernel >= 4.14 is installed: "MTP doesn't work in KDE with Linux 4.14"
I got into that issue while i was trying to connect my mobile phone using -current and Plasma5. According to the bug report that seem to be an issue with eudev and a patch was provided. Unsure if that patch will find its way upstream but it would be nice if Slackware will take care about it. At least the patch applies to eudev-3.2.5/-current. I will do some more testing but maybe others can confirm that.
Yes but for Slint only, as the modification to handle eMMC devices is not applied in Slackware-current at time of writing (and will not be needed if the patch is applied as the new detection routine can handle all kinds of devices). The next Slint ISO (14.2.1.2) will have the relevant patch applied.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.