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.
@elcore: I don't see a reason to worry in what you reported and think that your system would be more at risk using an unmaintained software, further if you are really worried you could isolate your machine from any network when booting. But that's just my opinion.
PS and if you are that worried, don't use a public source of electricity, as it can be an attack vector as well (OK, half kidding here, but still think power line communication and in many phones the same connector can be used to charge the unit or transfer files). But to be fully protected keep this machine isolated when running Slackware, using only well checked removable devices for information exchanges with the outside world.
If using GRUB 2 but not upgrading to 2.06 you'll miss the security fixes
This new requirement outweights those vulnerability fixes, since it makes the loader potentially vulnerable where it was just optionally vulnerable before.
Not worried about it at all, I'm not using the network boot and that system is always offline so the loader may as well be riddled with remote holes for all I care.
Quote:
Originally Posted by Didier Spaier
I don't see a reason to worry in what you reported and think that your system would be more at risk using an unmaintained software.
Where did I say I was worried anyway? It's those guys who use network boot who are worried, so I assume this shiny new requirement was not a mistake.
Probably just a call for more testers like, not enough eyes on this remote feature so fsck it let's just make it mandatory for everyone downstream.
Meanwhile, the "unmaintained" still has no new features, no new remote holes and no decisions upon decisions, it just is what it is.
It's nothing personal, we just disagree on some basic concepts of security, and to be honest I do still hope the whole thing's a honest mistake.
As for requests, well I don't really have any, but the OS was and still is usable without network so it'd be great if that stayed the same.
[97/109] Package slackpkg-15.0.5-noarch-1.txz is already in cache - not downloading
Upgrading => []:slackpkg-15.0.5-noarch-1...
Upgrading: slackpkg-15.0.5-noarch-1: Slackware package upgrade manager ............................................................ [ 410K]
slackpkg was upgraded - you will need start the upgrade process again...
If I'm not mistaken, in Slackware 14.2 slackpkg was used to be the first package upgraded when there was more than one on the list. Can we have this feature back (or implemented if I'm wrong )?
Thanks in advance.
Fellype
[EDIT] It still being the first package upgraded. However, it is upgraded immediately after its download is finished, and then the upgrade process stop. It would be better to put it at the end of the upgrade list in this case.
Last edited by Fellype; 06-10-2021 at 01:58 PM.
Reason: Correction in info
Would it be possible to add the Slackware installer to the root of the Slackware installation iso file?
Motivation: I would like to install Slackware from a running Linux system. I am imagining it as:
1) Insert an external HDD box.
2) Mount Slackware iso to /mnt/cdrom.
3) Run /mnt/cdrom/installer/setup
4) Point it to the external HDD
The installer may rely on some utilities not provided by the host system, but if the host system is Slackware this should not be a problem. Otherwise, the user may just add the necessary utilities from their distro.
Would it be possible to add the Slackware installer to the root of the Slackware installation iso file?
Motivation: I would like to install Slackware from a running Linux system. I am imagining it as:
1) Insert an external HDD box.
2) Mount Slackware iso to /mnt/cdrom.
3) Run /mnt/cdrom/installer/setup
4) Point it to the external HDD
The installer may rely on some utilities not provided by the host system, but if the host system is Slackware this should not be a problem. Otherwise, the user may just add the necessary utilities from their distro.
Shouldn't the installer have already all needed stuff on the slackware iso ?
Would it be possible to add the Slackware installer to the root of the Slackware installation iso file?
Motivation: I would like to install Slackware from a running Linux system.
It's rather easy to install Slackware to another disk from a running system by setting $ROOT point to the new disk and using installpkg. Then a bit of tuning and it's ready.
But if you are interested to make it work from the installer, I would not try to run the installer from the host system. Instead I would suggest extracting the installer image to a directory on the host ( unxz -c initrd.img |cpio -i ), making at least a bind mount to /proc (maybe more), and then chroot to that directory and run /usr/lib/setup/setup there. You would then run the busybox utilities etc, the tools of the install disk.
I'm sure the install wouldn't work now, but that could be a project for you to make it work.
Next time the etc package is updated, I think the haldaemon user/group can be removed, as nothing seems to use them anymore, even in -stable.
And maybe I miss something, but there is something weird in /etc/profile.d/libglib2.{c,}sh:
Code:
#!/bin/sh
#
# Description: This script sets the environment variables G_FILENAME_ENCODING
# and G_BROKEN_FILENAMES for the glib-2.0 library.
#
# G_FILENAME_ENCODING
# This environment variable can be set to a comma-separated list of
# character set names. GLib assumes that filenames are encoded in the
# first character set from that list rather than in UTF-8. The special
# token "@locale" can be used to specify the character set for the
# current locale.
# [...]
# If the LANG you have set contains any form of "UTF", we will guess you are
# using a UTF-8 locale. Hopefully we're correct.
if echo $LANG | grep -iq UTF ; then
export G_FILENAME_ENCODING="@locale"
fi
Isn't it meant to be "grep -viq": if we are not already using the default UTF-8 charset, we configure glib to match our non-UTF-8 locale? It is the same in -stable, but I can't see the point otherwise.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
)?
