Milky <milky@milk.fi> wrote:
> I wrote about over year ago about the same proplem ? I have a Fujitsu
> Lifebook E744 with latest UEFI update (v.1.37 Phoenix). And it stucks
> when I boot Slackware64-current-DVD.iso from my USB stick (USB 3.0 16
> GB Transcend). I have tried both UEFI ja CMS mode and in both stucks
> to keybord selection ? And both kernel options in boot (GRUB) menu ?
> Don't have a DVD-drive in my computer that could try to boot from it.
> Also tried out older versions of Slackware with same effect. Can any-
> thing be done or should I forget Slackware ?

You can try with an USB stick from system rescue CD.

https://osdn.net/projects/systemrescuecd/storage/releases/5.3.2/systemrescuecd-x86-5.3.2.iso

From System Rescue CD you can do the partitioning yourself with
cfdisk, format it with mkfs.ext3 or mkfs.ext4 with and mount the
directory and copy the packages to that directory.

Slackware is so simple that it's possible to install it even without chrooting.
This does the installing from the shell instead of relying from the
slackware installation media.

It lacks the installation of lilo, but you can rely on SystemRescue CD
to boot a Slackware kernel, and retry the install of the bootloader later.

mkdir -p ${mounted_root_dir}
mount -t ext4 ${TARGET_root} ${mounted_root_dir}
mkdir -p ${mounted_root_dir}/boot
mount -t ext3 ${TARGET_boot} ${mounted_root_dir}/boot

slack_mirror="https://mirrors.slackware.com/slackware"
slack_arch=slackware64
slack_ver=15.0
slack_pkg_dir=/tmp/slack_download/pkgs
slack_kernel_dir=/tmp/slack_download/kernels

# Check again list of packages for 15.0. This is for 14.2
slack_pkgs="${slack_arch}/{a,ap,d,e,f,l,n,t,tcl,x,xap,y}
extra/bash-completion
extra/bittornado
extra/bittorrent
extra/dip-3.3.7p
extra/wicd
extra/xf86-video-fbdev
extra/getty-ps
extra/xv
extra/xfractint
pasture" # firefox, thunderbird, ampd
# kde,kdei,xfce, y (bsdgames), k (kernel src)

mkdir -p ${slack_pkg_dir}
pushd ${slack_pkg_dir}

for i in ${slack_pkgs}; do
wget -m --no-parent --no-host-directories \
${slack_mirror}/${slack_arch}-${slack_ver}/${i}
done
popd

mkdir -p ${slack_kernel_dir}
pushd ${slack_kernel_dir}
wget -m --no-parent \
${slack_mirror}/${slack_arch}-${slack_ver}/${slack_arch}/kernels
popd

cp ${slack_mirror}/${slack_arch}-${slack_ver}/${slack_arch}/kernels/huge.s/bzImage \
${mounted_root_dir}/boot/SLACK_HUGE_bzImage
cp ${slack_mirror}/${slack_arch}-${slack_ver}/${slack_arch}/kernels/huge.s/System.map.gz \
${mounted_root_dir}/boot/SLACK_HUGE_System.map.gz

pkgtools=$(find ${slack_pkg_dir} | grep 'pkgtools-.*z$')

# ${slack_mirror}/${slack_arch}-${slack_ver}/${slack_arch}/a/pkgtools-*.txz
grep -q 'txz$' <<< ${pkgtools_txz}
pushd ${slack_pkg_dir}
tar xJf ${pkgtools_txz}
# ${slack_pkg_dir}/sbin/installpkg
popd

find ${slack_pkg_dir} | grep 't.?z$' | xargs -n 1 \
${slack_pkg_dir}/sbin/installpkg --root ${mounted_root_dir}

On Sat, 15 May 2021 19:13:30 -0500, Javier wrote:

....

> mkdir -p ${slack_pkg_dir}
> pushd ${slack_pkg_dir}
>
> for i in ${slack_pkgs}; do
> wget -m --no-parent --no-host-directories \
> ${slack_mirror}/${slack_arch}-${slack_ver}/${i}
> done popd

....

> find ${slack_pkg_dir} | grep 't.?z$' | xargs -n 1 \
> ${slack_pkg_dir}/sbin/installpkg --root ${mounted_root_dir}

I havn't tried to install Slackware without using a more ore less
customized Slackware installation media myself. However, at the end of
the installation a number of configurations are done by running all
scripts in /var/log/setup

Some of the scripts in that directory are interactive, others simply do
what they need to do without any questions asked.

Examples of what those scripts do is to configure the boot loader and
network settings.

regards Henrik

On 5/16/21 12:01 PM, Henrik Carlqvist wrote:
> On Sat, 15 May 2021 19:13:30 -0500, Javier wrote:
>
> ...
>
>> mkdir -p ${slack_pkg_dir}
>> pushd ${slack_pkg_dir}
>>
>> for i in ${slack_pkgs}; do
>> wget -m --no-parent --no-host-directories \
>> ${slack_mirror}/${slack_arch}-${slack_ver}/${i}
>> done popd
>
> ...
>
>> find ${slack_pkg_dir} | grep 't.?z$' | xargs -n 1 \
>> ${slack_pkg_dir}/sbin/installpkg --root ${mounted_root_dir}
>
> I havn't tried to install Slackware without using a more ore less
> customized Slackware installation media myself. However, at the end of
> the installation a number of configurations are done by running all
> scripts in /var/log/setup
>
> Some of the scripts in that directory are interactive, others simply do
> what they need to do without any questions asked.
>
> Examples of what those scripts do is to configure the boot loader and
> network settings.
>
> regards Henrik

I found out I messed up a kernel upgrade early this morning, I
multi-boot so I booted mx-linux, it has a chroot gui app, ran it, it's
easy, choose the partition, sda7, click, cd boot and ran the complete
upgrade again, built the initrd, quit chroot, updated legacy grub and
booted the system like there never was a problem. I highly recommend
multi-booting.
--
Jimmy Johnson

Slackware64 Current - AMD A8-7600 - EXT4 at sda7
Registered Linux User #380263

Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
>
> I havn't tried to install Slackware without using a more ore less
> customized Slackware installation media myself. However, at the end of
> the installation a number of configurations are done by running all
> scripts in /var/log/setup
>
> Some of the scripts in that directory are interactive, others simply do
> what they need to do without any questions asked.
>
> Examples of what those scripts do is to configure the boot loader and
> network settings.

When I first looked at the internals of the slackware installer it was
hard to me to find the installation scripts.

/var/log/setup is not the most evident place to put some scripts.

hier(7) says:

/var This directory contains files which may change in size, such as
spool and log files.

/var/log
Miscellaneous log files.

I guess Pat put the scripts in /var/log/setup when Slackware began in
the 90s, and later didn't want to change the location for fear of
breaking things (which in most cases is the right thing to do).

Other distros also had those kind of errors that were never corrected.
In the case of Debian comes to my mind the horrible desing of run-parts(1)
or the fact that /tmp is not in RAM.

On Mon, 17 May 2021 14:35:41 -0500, Javier wrote:

> Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
>>
>> I havn't tried to install Slackware without using a more ore less
>> customized Slackware installation media myself. However, at the end of
>> the installation a number of configurations are done by running all
>> scripts in /var/log/setup
>>
>> Some of the scripts in that directory are interactive, others simply do
>> what they need to do without any questions asked.
>>
>> Examples of what those scripts do is to configure the boot loader and
>> network settings.
>
> When I first looked at the internals of the slackware installer it was
> hard to me to find the installation scripts.
>
> /var/log/setup is not the most evident place to put some scripts.
>
> hier(7) says:
>
> /var This directory contains files which may change in size, such as
> spool and log files.
>
> /var/log
> Miscellaneous log files.
>
> I guess Pat put the scripts in /var/log/setup when Slackware began in
> the 90s, and later didn't want to change the location for fear of
> breaking things (which in most cases is the right thing to do).

IIRC, the upcoming 15.0 release moves Pat's setup files to another
location

Ahhh... here it is

Tue Jun 19 22:35:25 UTC 2018
testing/packages/pkgtools-15.0-noarch-20.txz: Rebuilt.
This update is a bit scarier than usual, so we're going to test it here
first and then move it into the main tree in a couple of days if there
are no serious bug reports. It's well-tested here, and works with the
slackpkg that's in -current now, but I don't know about slackpkg+ so that's
another reason to let it cool down here first. The purpose of this update
is to migrate the package database and directories from /var/log to
/var/lib/pkgtools. /var/log was never a good place for this data, as it is
considered by many to be a directory that could be wiped to free up some
space. Originally the package database was in /var/adm, but the FSSTND
(later FHS) group decided that directory should be a symlink to /var/log,
and I went along with that since it was years ago and I was a n00b and didn't
know any better. /var/lib/pkgtools will be a better and safer location.
The removed_packages and removed_scripts directories are really just logs
that aren't actually used for anything - those will remain under /var/log,
but moved into /var/log/pkgtools. Everything under /var/log will be
considered potentially non-permanent by the pkgtools - if any directories or
symlinks disappear from there, the pkgtools will automatically recreate them
as needed. In fact, the migration process will create symlinks from all the
old directory locations to the new ones, so anything that expects the old
locations (including slackpkg, for now) should continue to work. Once this
moves into the main tree, the plan is to fix other packages to use the new
installer script directory (/var/lib/pkgtools/setup) and change the installer
and slackpkg to use the new native locations for everything. When slackpkg
is changed over to use the new native locations, I'll also make sure to float
that in testing/ for a few days before moving it to the main tree to avoid
more unintentional disruption to slackpkg+ users.
Be aware that the package database migration is a one-way operation, but even
so if you later downgrade to an older version of the pkgtools it will still
work through the compatibility symlinks.

and

Thu Jun 21 22:58:42 UTC 2018
a/pkgtools-15.0-noarch-20.txz: Rebuilt.
Move pkgtools database to /var/lib/pkgtools/.
Move removed logs to /var/log/pkgtools/.

> Other distros also had those kind of errors that were never corrected.
> In the case of Debian comes to my mind the horrible desing of run-parts(1)
> or the fact that /tmp is not in RAM.

--
Lew Pitcher
"In Skills, We Trust"

Javier <invalid@invalid.invalid> wrote:
> or the fact that /tmp is not in RAM.

I'll have you know I have files over 5 years old in /tmp,
and I like it that way :-)

#Paul

On Mon, 07 Jun 2021 18:56:35 +0100, #Paul wrote:
> I'll have you know I have files over 5 years old in /tmp,
> and I like it that way :-)

I have added a custom cron script to remove files in /tmp older than 37
days and empty directories not touched in 37 days:

-8<---------------------------------

cat /etc/cron.daily/tmp-clean
#!/bin/sh
# Cleanup /tmp however, do not remove sockets for X

# No lost+found with reiserfs, but ext* has it...
find /tmp/lost+found -exec /bin/touch {} \;
find /tmp -type s -exec /bin/touch {} \;
find /tmp -type d -empty -mtime +37 -exec /bin/rmdir {} \;
find /tmp -atime +37 -exec /bin/rm {} \;

-8<---------------------------------

As the comment says in the script X might crash if sockets like
/tmp/.X11-unix/X0 is removed so the script starts by touching all sockets
to make sure that they are not removed.

regards Henrik

On 6/7/21 1:57 PM, Henrik Carlqvist wrote:
> -8<---------------------------------
> #!/bin/sh
> # Cleanup /tmp however, do not remove sockets for X
>
> # No lost+found with reiserfs, but ext* has it...
> find /tmp/lost+found -exec /bin/touch {} \;
> find /tmp -type s -exec /bin/touch {} \;
> find /tmp -type d -empty -mtime +37 -exec /bin/rmdir {} \;
> find /tmp -atime +37 -exec /bin/rm {} \;
> -8<---------------------------------

Drive by comment: Be careful with filenames with spaces in them. I'd
suggest putting double quotes around the {} in the find -exec statements.

--
Grant. . . .
unix || die

On Tue, 08 Jun 2021 16:37:35 -0600, Grant Taylor wrote:

> On 6/7/21 1:57 PM, Henrik Carlqvist wrote:
>> -8<---------------------------------
>> #!/bin/sh
>> # Cleanup /tmp however, do not remove sockets for X
>>
>> # No lost+found with reiserfs, but ext* has it...
>> find /tmp/lost+found -exec /bin/touch {} \;
>> find /tmp -type s -exec /bin/touch {} \;
>> find /tmp -type d -empty -mtime +37 -exec /bin/rmdir {} \;
>> find /tmp -atime +37 -exec /bin/rm {} \;
>> -8<---------------------------------
>
> Drive by comment: Be careful with filenames with spaces in them. I'd
> suggest putting double quotes around the {} in the find -exec statements.

GNU find(1) extends POSIX find(1) with a "-delete" action that does not
require exposing filenames to the shell. As such, it offers an alternative
to the OP's
find /tmp -atime +37 -exec /bin/rm {} \;
in
find /tmp -atime +37 -delete

For added security, I would rephrase the command to:
find /tmp -atime +37 -print -delete
to keep a record of files and directories deleted.

--
Lew Pitcher
"In Skills, We Trust"

Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> On Tue, 08 Jun 2021 16:37:35 -0600, Grant Taylor wrote:
>
>> On 6/7/21 1:57 PM, Henrik Carlqvist wrote:
>>> -8<---------------------------------
>>> #!/bin/sh
>>> # Cleanup /tmp however, do not remove sockets for X
>>>
>>> # No lost+found with reiserfs, but ext* has it...
>>> find /tmp/lost+found -exec /bin/touch {} \;
>>> find /tmp -type s -exec /bin/touch {} \;
>>> find /tmp -type d -empty -mtime +37 -exec /bin/rmdir {} \;
>>> find /tmp -atime +37 -exec /bin/rm {} \;
>>> -8<---------------------------------
>>
>> Drive by comment: Be careful with filenames with spaces in them. I'd
>> suggest putting double quotes around the {} in the find -exec statements.
>
> GNU find(1) extends POSIX find(1) with a "-delete" action that does not
> require exposing filenames to the shell. As such, it offers an alternative
> to the OP's
> find /tmp -atime +37 -exec /bin/rm {} \;
> in
> find /tmp -atime +37 -delete
>
> For added security, I would rephrase the command to:
> find /tmp -atime +37 -print -delete
> to keep a record of files and directories deleted.

The -exec option to find, using the ; terminator, also forks and
executes the command specified ones per filename found. That can be
avoided by using the + terminator "-exec /bin/rm {} +" instead, but I
prefer to pipe through xargs instead:

find /tmp -atime +37 -print0 | xargs -0 /bin/rm

With either the "+" or the xargs variant, only enough fork()/exec()'s
to delete all the found filenames are executed, instead of one for each
individual file.

Also, depending on disk seek performance (i.e., ssd vs mechanical disk)
the find pipe to xargs could very well run in parallel. The
fork()/exec() variant is either finding files, or deleting them, but
not both at the same time.

I think both Lew's and Rich's comments are on target and very good.

--
Grant. . . .
unix || die

Grant Taylor <gtaylor@tnetconsulting.net> writes:
> On 6/7/21 1:57 PM, Henrik Carlqvist wrote:
>> -8<---------------------------------
>> #!/bin/sh
>> # Cleanup /tmp however, do not remove sockets for X
>>
>> # No lost+found with reiserfs, but ext* has it...
>> find /tmp/lost+found -exec /bin/touch {} \;
>> find /tmp -type s -exec /bin/touch {} \;
>> find /tmp -type d -empty -mtime +37 -exec /bin/rmdir {} \;
>> find /tmp -atime +37 -exec /bin/rm {} \;
>> -8<---------------------------------
>
> Drive by comment: Be careful with filenames with spaces in them. I'd
> suggest putting double quotes around the {} in the find -exec
> statements.

That’s not how shell quoting or find -exec work.

The real problem with these commands is that they contain a well-known
vulnerability. For details see:

https://www.gnu.org/software/findutils/manual/html_node/find_html/Race-Conditions-with-_002dexec.html

--
https://www.greenend.org.uk/rjk/

On 6/9/21 2:55 AM, Richard Kettlewell wrote:
> That’s not how shell quoting or find -exec work.

Please elaborate.

> The real problem with these commands is that they contain a well-known
> vulnerability. For details see:

I completely agree that there is a timing component (race condition)
that can be a problem. But that's not the component I was speaking to.

--
Grant. . . .
unix || die

Grant Taylor <gtaylor@tnetconsulting.net> writes:
> On 6/9/21 2:55 AM, Richard Kettlewell wrote:
>> That’s not how shell quoting or find -exec work.
>
> Please elaborate.

I have too much RSI to repeat shell-quoting rules and the semantics of
find -exec. You will have to look them up.

--
https://www.greenend.org.uk/rjk/

In alt.os.linux.slackware, Richard Kettlewell <invalid@invalid.invalid> wrote:
> Grant Taylor <gtaylor@tnetconsulting.net> writes:
>> Drive by comment: Be careful with filenames with spaces in them. I'd
>> suggest putting double quotes around the {} in the find -exec
>> statements.
> That's not how shell quoting or find -exec work.

Agreed. Note that I'm using ksh and have PS2 set to <TAB> here:

$ cd /var/tmp
$ mkdir 'I
U+2665
trouble' && cd I*trouble
$ mkdir '`echo nana`'
$ touch '`echo nana`'/'
yikes
'
$ cd ..
$ find . -size 0 -type f -exec ls -ld {} +
-rw-rw-r-- 1 username username 0 Jun 9 11:35 './I'$'\n''U+2665'$'\n''trouble/`echo nana`/'$'\n''yikes'$'\n'
$

Since I'm using ksh, {} is not special to shell, and does not need
quoting. Since {} is safely replaced by find, whitespace and shell
metas in names is not an issue.

Elijah
------
did not actually include the unicode, just the U+codepoint

On Tue, 08 Jun 2021 23:06:09 +0000, Lew Pitcher wrote:

> On Tue, 08 Jun 2021 16:37:35 -0600, Grant Taylor wrote:
>
>> On 6/7/21 1:57 PM, Henrik Carlqvist wrote:
>>> -8<---------------------------------
>>> #!/bin/sh
>>> # Cleanup /tmp however, do not remove sockets for X
>>>
>>> # No lost+found with reiserfs, but ext* has it...
>>> find /tmp/lost+found -exec /bin/touch {} \;
>>> find /tmp -type s -exec /bin/touch {} \;
>>> find /tmp -type d -empty -mtime +37 -exec /bin/rmdir {} \;
>>> find /tmp -atime +37 -exec /bin/rm {} \;
>>> -8<---------------------------------

> For added security, I would rephrase the command to:
> find /tmp -atime +37 -print -delete
> to keep a record of files and directories deleted.

Thanks for all comments!

I will try:

find /tmp/lost+found -exec /bin/touch {} \;
find /tmp -type s -exec /bin/touch {} \;
find /tmp -type d -empty -mtime +37 -print -delete
find /tmp -atime +37 -print -delete

The record of deleted files will end up in emails to me. As this cron job
is being run on 50+ machines it will probably mean 50+ emails every
night. I might remove the -print if it gets too much to read...

regards Henrik

On 6/9/21 2:52 PM, Henrik Carlqvist wrote:
> The record of deleted files will end up in emails to me. As this cron
> job is being run on 50+ machines it will probably mean 50+ emails
> every night. I might remove the -print if it gets too much to read...

(Pro)Tip: Have one string of text for success and another string of
text for failure. Then configure email client filtering to mark success
messages as read (and file them away). That way you can easily look at
the folder and see that the cron job is running like it should be. If
there ever is a failure, it will remain unread (maybe filed away, maybe
not) so that it will garner your attention to investigate the failure.

I've learned that it's really difficult to tell from afar if a
completely silent script is always succeeding or simply not running. I
dislike that.

--
Grant. . . .
unix || die

On Wed, 09 Jun 2021 18:19:37 -0600, Grant Taylor wrote:
> I've learned that it's really difficult to tell from afar if a
> completely silent script is always succeeding or simply not running. I
> dislike that.

Thanks, yes, I share that experience. During the years it has happened
that the crond daemon has died completely. Fortunately all those machines
are also monitored by software which will tell if some important deamon
has died and/or if some partition is getting more than 90% full. I have
/tmp on a separate partition.

regards Henrik