Qt: Session management error; Error: /ioerror in --showpage--...

[eho]

Hello.

Since last update of slackware current I have problems
with PDF and ps files, when I try to open them,
I get the error message:

---------------------------------------------------\
Qt: Session management error: Authentication Rejected, reason : None of
the authentication protocols specified are supported and host-based
authentication failed
---------------------------------------------------/

both with okular and xpdf.

But the files open nonetheless. More serious is,
that I cannot convert ps to pdf or vice versa,
which I need, because I have som text files
which I can convert to ps using paps,
but ps is only usable on Linux...

Using pdf2ps or ps2pdf gives me:

---------------------------------------------------\

Error: /ioerror in --showpage--
Operand stack:
1 true
Execution stack:
%interp_exit .runexec2 --nostringval-- showpage --
nostringval-- 2 %stopped_push --nostringval-- showpage
showpage false 1 %stopped_push 1990 1 3 %oparray_pop
1989 1 3 %oparray_pop 1977 1 3 %oparray_pop 1978 1 3
%oparray_pop showpage showpage 2 1 25 showpage
%for_pos_int_continue 1981 1 7 %oparray_pop showpage showpage
1840 0 9 %oparray_pop showpage showpage
Dictionary stack:
--dict:759/1123(ro)(G)-- --dict:1/20(G)-- --dict:80/200(L)-- --
dict:80/200(L)-- --dict:134/256(ro)(G)-- --dict:324/325(ro)(G)-- --
dict:33/64(L)-- --dict:6/9(L)-- --dict:6/20(L)--
Current allocation mode is local
Last OS error: No space left on device
GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1
GPL Ghostscript 9.55.0: ERROR: ioerror (-12) on closing ps2write device.

---------------------------------------------------/

What I found in the net did not help.

TIA

Erich

[Lew Pitcher]

Allow me to highlight the relevant error message...

Post by eho
Hello.
Since last update of slackware current I have problems with PDF and ps
files, when I try to open them,
---------------------------------------------------\
Qt: Session management error: Authentication Rejected, reason : None of
the authentication protocols specified are supported and host-based
authentication failed
---------------------------------------------------/
both with okular and xpdf.
But the files open nonetheless. More serious is,
that I cannot convert ps to pdf or vice versa,
which I need, because I have som text files which I can convert to ps
using paps,
but ps is only usable on Linux...
---------------------------------------------------\
Error: /ioerror in --showpage--
1 true
%interp_exit .runexec2 --nostringval-- showpage --
nostringval-- 2 %stopped_push --nostringval-- showpage showpage
false 1 %stopped_push 1990 1 3 %oparray_pop 1989 1 3
%oparray_pop 1977 1 3 %oparray_pop 1978 1 3 %oparray_pop
showpage showpage 2 1 25 showpage %for_pos_int_continue 1981
1 7 %oparray_pop showpage showpage 1840 0 9 %oparray_pop
--dict:759/1123(ro)(G)-- --dict:1/20(G)-- --dict:80/200(L)-- --
dict:80/200(L)-- --dict:134/256(ro)(G)-- --dict:324/325(ro)(G)--
--
dict:33/64(L)-- --dict:6/9(L)-- --dict:6/20(L)--
Current allocation mode is local
Last OS error: No space left on device

=================+====================
\
This error

Post by eho
GPL Ghostscript 9.55.0: Unrecoverable error, exit code 1
GPL Ghostscript 9.55.0: ERROR: ioerror (-12) on closing ps2write device.

It appears that one of your filesystems is full (or at least, out of
user-writable space), causing file writes to fail.
(I'm guessing /tmp or /var/tmp, but there's not enough detail here
to be certain)

What does df(1) tell you about your disk space?

[Mike]

Post by Lew Pitcher

Post by eho
Current allocation mode is local
Last OS error: No space left on device

=================+====================
\
This error
It appears that one of your filesystems is full (or at least, out of
user-writable space), causing file writes to fail.

... or it is not full *right now*, but *becomes* full as a result of
whatever command you are running generating a hideous amount of
temporary data (been there, done that) ;)

Post by Lew Pitcher
What does df(1) tell you about your disk space?

... and if nothing is banging on 99%/100% full, run the df command
repeatedly in a 2nd window while the failing command operates.

See if something is going up, up, up, up to 100% and then dropping
back as the temporary file(s) are deleted on exit.

[eho]

(...)

Post by Mike

Post by Lew Pitcher
It appears that one of your filesystems is full (or at least, out of
user-writable space), causing file writes to fail.

... or it is not full *right now*, but *becomes* full as a result of
whatever command you are running generating a hideous amount of
temporary data (been there, done that) ;)

Post by Lew Pitcher
What does df(1) tell you about your disk space?

... and if nothing is banging on 99%/100% full, run the df command
repeatedly in a 2nd window while the failing command operates.
See if something is going up, up, up, up to 100% and then dropping back
as the temporary file(s) are deleted on exit.

Reeally thanks to both of you!

It was the SBo tmp dir. Moved it from there, and the /tmp dropped
constantly to 22%. Ouf ! Good experience though, now I want to
learn more on the tmp dir, never expected that a program like
ps2pdf /pdf2ps uses it, but it makes sense!

And I should not panic when such an error message comes up,
but read it slowly and carefully... thanks again.

BTW the other error with the authentication problem when starting
okular has vanished as well...

Cheers Erich

[Henrik Carlqvist]

Post by eho
It was the SBo tmp dir. Moved it from there, and the /tmp dropped
constantly to 22%. Ouf ! Good experience though, now I want to learn
more on the tmp dir, never expected that a program like ps2pdf /pdf2ps
uses it, but it makes sense!
BTW the other error with the authentication problem when starting okular
has vanished as well...

I have seen people getting trouble to start X programs when their home
directory partition gets full. Could it be that /tmp and /home is on the
same partition? Otherwise, as you have seen, a full /tmp partition could
also give a lot of strange problems.

regards Henrik

[Aragorn]

Post by Henrik Carlqvist

Post by eho
It was the SBo tmp dir. Moved it from there, and the /tmp dropped
constantly to 22%. Ouf ! Good experience though, now I want to
learn more on the tmp dir, never expected that a program like
ps2pdf /pdf2ps uses it, but it makes sense!
BTW the other error with the authentication problem when starting
okular has vanished as well...

I have seen people getting trouble to start X programs when their
home directory partition gets full. Could it be that /tmp and /home
is on the same partition? Otherwise, as you have seen, a full /tmp
partition could also give a lot of strange problems.

I recommend always using a tmpfs for /tmp. I've been doing that for
ages already. There's nothing in /tmp that should be expected to
survive a reboot anyway.

Also, you can install tmpwatch, which periodically cleans out your /tmp
and /var/tmp based upon the atimes, which is useful on machines that
stay up 24/7. It runs from a cron job.

[eho]

Post by Aragorn

Post by Henrik Carlqvist
strange problems.

I recommend always using a tmpfs for /tmp. I've been doing that for
ages already. There's nothing in /tmp that should be expected to
survive a reboot anyway.

Well, now I know the origin of evil (the SBo tmp files),
I could clean /tmp manually, but ...

This is a bit new to me. Does tmpfs for /tmp mean
an entry in /etc/fstab?

I have

(...)
/dev/sda6 /tmp ext4 defaults 1 2
(...)

And should I now write

tmpfs /dev/sda6 tmpfs defaults 0 0

BTW can it be a problem to have too much partitions?

Post by Aragorn
Also, you can install tmpwatch, which periodically cleans out your /tmp
and /var/tmp based upon the atimes, which is useful on machines that
stay up 24/7. It runs from a cron job.

Good to know, but in my case perhaps too much, no 24/7 machine. Thanks!

Erich

[Aragorn]

Post by eho

Post by Aragorn

Post by Henrik Carlqvist
strange problems.

I recommend always using a tmpfs for /tmp. I've been doing that for
ages already. There's nothing in /tmp that should be expected to
survive a reboot anyway.

Well, now I know the origin of evil (the SBo tmp files),
I could clean /tmp manually, but ...
This is a bit new to me. Does tmpfs for /tmp mean
an entry in /etc/fstab?

In Slackware concretely, yes. In distributions based upon systemd as
PID 1 , systemd usually already sets that up by itself — SUSE/openSUSE
might be an exception, from what I've heard.

Post by eho
I have
(...)
/dev/sda6 /tmp ext4 defaults 1 2
(...)
And should I now write
tmpfs /dev/sda6 tmpfs defaults 0 0

That would work, yes. You can also tune the maximum amount of virtual
memory that the tmpfs in question can use. The default is half your
RAM. See... ↓


$ man mount

Post by eho
BTW can it be a problem to have too much partitions?

That depends on what you would consider "too many". I believe both the
MBR and GPT partition table formats support 128 partitions per physical
drive. So if you need anything more than that... :p

But anyway, here's the layout from my system. ↓


[nx-74205:/dev/pts/3][/home/aragorn]
[06:55:45][aragorn] > lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
├─sda2 8:2 0 512M 0 part /boot
├─sda3 8:3 0 1G 0 part /
├─sda4 8:4 0 22G 0 part /usr
├─sda5 8:5 0 512M 0 part /usr/local
├─sda6 8:6 0 2G 0 part /opt
├─sda7 8:7 0 1.5G 0 part
├─sda8 8:8 0 400G 0 part /srv
├─sda9 8:9 0 450G 0 part /home
├─sda10 8:10 0 10G 0 part
└─sda11 8:11 0 20G 0 part /var
sdb 8:16 0 698.6G 0 disk
├─sdb1 8:17 0 10G 0 part
└─sdb2 8:18 0 683.6G 0 part
sr0 11:0 1 1024M 0 rom


/dev/sda is an SATA3-connected SSD. /dev/sdb is an SATA2 HDD that
comes out of one of my previous computers.

My /tmp resides on a tmpfs. /dev/sda7 is unused because it's my old
/var, which proved too small. /dev/sda10 is my swap partition, but
I've disabled swap about two years ago and it hasn't caused me any
problems yet.

/dev/sdb1 is another swap partition — disabled as well — and /dev/sdb2
is the partition that I store my Timeshift backups on.

/boot/efi is vfat (FAT32), as prescribed by the UEFI specification.
/boot itself is ext4 because GRUB is picky about what it supports. All
other partitions — except for the swap partitions of course — are btrfs.

The system is working fine, and so I'm not going to change anything
about the partitioning. However, I've already decided that for my next
system, I'll be using btrfs subvolumes instead of dedicated partitions
— subvolumes have all the advantages of dedicated partitions, but the
free disk space is shared among all of them (unless you use quota, of
course).

For this system here — purchased and installed in April 2019 — I still
decided to go with dedicated partitions because it was my first
foray into using btrfs and I wasn't sure yet how stable it was, nor
about just how much you can do with it.

[Aragorn]

Post by Aragorn

Post by eho
And should I now write
tmpfs /dev/sda6 tmpfs defaults 0 0

That would work, yes.

Oops, no, it wouldn't — my apologies, I only just got up and it's still
early in the morning here.

More correct would be... ↓

none /tmp tmpfs defaults,nosuid,noexec 0 0

[Chris Vine]

On Fri, 26 Nov 2021 07:09:09 +0100

Post by Aragorn

Post by eho

Post by Aragorn

Post by Henrik Carlqvist
strange problems.

I recommend always using a tmpfs for /tmp. I've been doing that for
ages already. There's nothing in /tmp that should be expected to
survive a reboot anyway.

Well, now I know the origin of evil (the SBo tmp files),
I could clean /tmp manually, but ...
This is a bit new to me. Does tmpfs for /tmp mean
an entry in /etc/fstab?

In Slackware concretely, yes. In distributions based upon systemd as
PID 1 , systemd usually already sets that up by itself — SUSE/openSUSE
might be an exception, from what I've heard.

Post by eho
I have
(...)
/dev/sda6 /tmp ext4 defaults 1 2
(...)
And should I now write
tmpfs /dev/sda6 tmpfs defaults 0 0

That would work, yes. You can also tune the maximum amount of virtual
memory that the tmpfs in question can use. The default is half your
RAM. See... ↓
$ man mount

Post by eho
BTW can it be a problem to have too much partitions?

That depends on what you would consider "too many". I believe both the
MBR and GPT partition table formats support 128 partitions per physical
drive. So if you need anything more than that... :p
But anyway, here's the layout from my system. ↓
[nx-74205:/dev/pts/3][/home/aragorn]
[06:55:45][aragorn] > lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
├─sda2 8:2 0 512M 0 part /boot
├─sda3 8:3 0 1G 0 part /
├─sda4 8:4 0 22G 0 part /usr
├─sda5 8:5 0 512M 0 part /usr/local
├─sda6 8:6 0 2G 0 part /opt
├─sda7 8:7 0 1.5G 0 part
├─sda8 8:8 0 400G 0 part /srv
├─sda9 8:9 0 450G 0 part /home
├─sda10 8:10 0 10G 0 part
└─sda11 8:11 0 20G 0 part /var
sdb 8:16 0 698.6G 0 disk
├─sdb1 8:17 0 10G 0 part
└─sdb2 8:18 0 683.6G 0 part
sr0 11:0 1 1024M 0 rom
/dev/sda is an SATA3-connected SSD. /dev/sdb is an SATA2 HDD that
comes out of one of my previous computers.
My /tmp resides on a tmpfs. /dev/sda7 is unused because it's my old
/var, which proved too small. /dev/sda10 is my swap partition, but
I've disabled swap about two years ago and it hasn't caused me any
problems yet.
/dev/sdb1 is another swap partition — disabled as well — and /dev/sdb2
is the partition that I store my Timeshift backups on.
/boot/efi is vfat (FAT32), as prescribed by the UEFI specification.
/boot itself is ext4 because GRUB is picky about what it supports. All
other partitions — except for the swap partitions of course — are btrfs.
The system is working fine, and so I'm not going to change anything
about the partitioning. However, I've already decided that for my next
system, I'll be using btrfs subvolumes instead of dedicated partitions
— subvolumes have all the advantages of dedicated partitions, but the
free disk space is shared among all of them (unless you use quota, of
course).

Your directory layout above looks insane. What's the point of so many
partitions? To share free disk space around your file system, the best
thing is not to have so many. One partition as the EFI partition, one
for swap and one for / will do fine for most purposes, so everything
under / (apart from EFI) is shared. You might possibly want a separate
partition for /home so that your home directory survives reinstallation
or an upgrade, but that would be about it in my experience.

[K. Venken]

Post by Chris Vine
On Fri, 26 Nov 2021 07:09:09 +0100

Post by Aragorn

Post by eho

Post by Aragorn

Post by Henrik Carlqvist
strange problems.

I recommend always using a tmpfs for /tmp. I've been doing that for
ages already. There's nothing in /tmp that should be expected to
survive a reboot anyway.

Well, now I know the origin of evil (the SBo tmp files),
I could clean /tmp manually, but ...
This is a bit new to me. Does tmpfs for /tmp mean
an entry in /etc/fstab?

In Slackware concretely, yes. In distributions based upon systemd as
PID 1 , systemd usually already sets that up by itself — SUSE/openSUSE
might be an exception, from what I've heard.

Post by eho
I have
(...)
/dev/sda6 /tmp ext4 defaults 1 2
(...)
And should I now write
tmpfs /dev/sda6 tmpfs defaults 0 0

That would work, yes. You can also tune the maximum amount of virtual
memory that the tmpfs in question can use. The default is half your
RAM. See... ↓
$ man mount

Post by eho
BTW can it be a problem to have too much partitions?

That depends on what you would consider "too many". I believe both the
MBR and GPT partition table formats support 128 partitions per physical
drive. So if you need anything more than that... :p
But anyway, here's the layout from my system. ↓
[nx-74205:/dev/pts/3][/home/aragorn]
[06:55:45][aragorn] > lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 931.5G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
├─sda2 8:2 0 512M 0 part /boot
├─sda3 8:3 0 1G 0 part /
├─sda4 8:4 0 22G 0 part /usr
├─sda5 8:5 0 512M 0 part /usr/local
├─sda6 8:6 0 2G 0 part /opt
├─sda7 8:7 0 1.5G 0 part
├─sda8 8:8 0 400G 0 part /srv
├─sda9 8:9 0 450G 0 part /home
├─sda10 8:10 0 10G 0 part
└─sda11 8:11 0 20G 0 part /var
sdb 8:16 0 698.6G 0 disk
├─sdb1 8:17 0 10G 0 part
└─sdb2 8:18 0 683.6G 0 part
sr0 11:0 1 1024M 0 rom
/dev/sda is an SATA3-connected SSD. /dev/sdb is an SATA2 HDD that
comes out of one of my previous computers.
My /tmp resides on a tmpfs. /dev/sda7 is unused because it's my old
/var, which proved too small. /dev/sda10 is my swap partition, but
I've disabled swap about two years ago and it hasn't caused me any
problems yet.
/dev/sdb1 is another swap partition — disabled as well — and /dev/sdb2
is the partition that I store my Timeshift backups on.
/boot/efi is vfat (FAT32), as prescribed by the UEFI specification.
/boot itself is ext4 because GRUB is picky about what it supports. All
other partitions — except for the swap partitions of course — are btrfs.
The system is working fine, and so I'm not going to change anything
about the partitioning. However, I've already decided that for my next
system, I'll be using btrfs subvolumes instead of dedicated partitions
— subvolumes have all the advantages of dedicated partitions, but the
free disk space is shared among all of them (unless you use quota, of
course).

Your directory layout above looks insane. What's the point of so many
partitions? To share free disk space around your file system, the best
thing is not to have so many. One partition as the EFI partition, one
for swap and one for / will do fine for most purposes, so everything
under / (apart from EFI) is shared. You might possibly want a separate
partition for /home so that your home directory survives reinstallation
or an upgrade, but that would be about it in my experience.

I agree with /home on a separate partition as / and /tmp does. I would
however add /var on a separate partition as well. It contains dynamic
data which might be useful to recover when system breaks, if at all.

[Henrik Carlqvist]

Post by K. Venken

Post by Chris Vine
Your directory layout above looks insane. What's the point of so many
partitions?

I agree with /home on a separate partition as / and /tmp does. I would
however add /var on a separate partition as well. It contains dynamic
data which might be useful to recover when system breaks, if at all.

Aragorns partitions looks very much like the partitions on my system. The
point is to protect the / partition against failures in case of something
like a power outage. That is done by keeping the / partition small.

Usually most of your installation data lives below /usr and maybe also
some below /opt. Those partitions might be big, but are still rather safe
against failures as usually there is not much writing done to those
partitions.

Partitions which get a lot of writings are /var and /tmp, but those
partitions are not very big and do not contain very important data
(unless you run something like a mysql server).

As you understand it is for many reasons convenient to have /home on a
separate partition.

regards Henrik

[Aragorn]

Post by Henrik Carlqvist

Post by K. Venken

Post by Chris Vine
Your directory layout above looks insane. What's the point of so
many partitions?

I agree with /home on a separate partition as / and /tmp does. I
would however add /var on a separate partition as well. It contains
dynamic data which might be useful to recover when system breaks,
if at all.

Aragorns partitions looks very much like the partitions on my system.
The point is to protect the / partition against failures in case of
something like a power outage. That is done by keeping the /
partition small.
Usually most of your installation data lives below /usr and maybe
also some below /opt. Those partitions might be big, but are still
rather safe against failures as usually there is not much writing
done to those partitions.

/usr and /opt should both be completely read-only during normal
operation, because no process should ever write to them, apart from the
package manager during an update or when installing software, of course.

As such, I have also _mounted_ these two filesystems read-only on my
system, as well as /boot, and all three also have the "sync" mount
option for in case I am updating my system, as well as "nodev", which
I'm using on everything in `/etc/fstab — systemd takes care of mounting
/dev and /tmp, as well as /run. /tmp is also mounted "nosuid".

Another advantage of using separate partitions is that you are no
longer limited to one filesystem type. For instance, you may prefer
ext4 on one partition and maybe XFS, JFS or btrfs on another, depending
on the intended usage.

[Henrik Carlqvist]

This is a bit new to me. Does tmpfs for /tmp mean an entry in
/etc/fstab?
I have
(...)
/dev/sda6 /tmp ext4 defaults 1 2 (...)
And should I now write
tmpfs /dev/sda6 tmpfs defaults 0 0

You should edit that to:

tmpfs /tmp tmpfs defaults 0 0

BTW can it be a problem to have too much partitions?

If I remember right it at least used to be a limit of 15 partitions, but
I don't know for sure if that limit still applies.

That limit of 16 partitions came from the device numbering, looking at
/dev/sda and /dev/sdb:

brw-r----- 1 root disk 8, 0 Apr 29 1995 /dev/sda
brw-r----- 1 root disk 8, 1 Apr 29 1995 /dev/sda1
brw-r----- 1 root disk 8, 10 Apr 29 1995 /dev/sda10
brw-r----- 1 root disk 8, 11 Apr 29 1995 /dev/sda11
brw-r----- 1 root disk 8, 12 Apr 29 1995 /dev/sda12
brw-r----- 1 root disk 8, 13 Apr 29 1995 /dev/sda13
brw-r----- 1 root disk 8, 14 Apr 29 1995 /dev/sda14
brw-r----- 1 root disk 8, 15 Apr 29 1995 /dev/sda15
brw-r----- 1 root disk 8, 2 Apr 29 1995 /dev/sda2
brw-r----- 1 root disk 8, 3 Apr 29 1995 /dev/sda3
brw-r----- 1 root disk 8, 4 Apr 29 1995 /dev/sda4
brw-r----- 1 root disk 8, 5 Apr 29 1995 /dev/sda5
brw-r----- 1 root disk 8, 6 Apr 29 1995 /dev/sda6
brw-r----- 1 root disk 8, 7 Apr 29 1995 /dev/sda7
brw-r----- 1 root disk 8, 8 Apr 29 1995 /dev/sda8
brw-r----- 1 root disk 8, 9 Apr 29 1995 /dev/sda9
brw-r----- 1 root disk 8, 16 Apr 29 1995 /dev/sdb
brw-r----- 1 root disk 8, 17 Apr 29 1995 /dev/sdb1
brw-r----- 1 root disk 8, 26 Apr 29 1995 /dev/sdb10
brw-r----- 1 root disk 8, 27 Apr 29 1995 /dev/sdb11
brw-r----- 1 root disk 8, 28 Apr 29 1995 /dev/sdb12
brw-r----- 1 root disk 8, 29 Apr 29 1995 /dev/sdb13
brw-r----- 1 root disk 8, 30 Apr 29 1995 /dev/sdb14
brw-r----- 1 root disk 8, 31 Apr 29 1995 /dev/sdb15
brw-r----- 1 root disk 8, 18 Apr 29 1995 /dev/sdb2
brw-r----- 1 root disk 8, 19 Apr 29 1995 /dev/sdb3
brw-r----- 1 root disk 8, 20 Apr 29 1995 /dev/sdb4
brw-r----- 1 root disk 8, 21 Apr 29 1995 /dev/sdb5
brw-r----- 1 root disk 8, 22 Apr 29 1995 /dev/sdb6
brw-r----- 1 root disk 8, 23 Apr 29 1995 /dev/sdb7
brw-r----- 1 root disk 8, 24 Apr 29 1995 /dev/sdb8
brw-r----- 1 root disk 8, 25 Apr 29 1995 /dev/sdb9

As you can see the disks /dev/sda and /dev/sdb both have the major number
8. Disk /dev/sda has minor number 0 and disk /dev/sdb has minor number
16. Partitions on /dev/sda have minor numbers 1-15 and partitions on /dev/
sdb have minor numbers 17-31. If I remember right it was possible to
change a kernel setting and recompile the kernel to increase this limit.
But this was back in the old days, maybe udev now somehow solves that
problem automagically.

regards Henrik

[eho]

(...)

Post by Henrik Carlqvist

Post by eho
BTW can it be a problem to have too much partitions?

If I remember right it at least used to be a limit of 15 partitions,
but I don't know for sure if that limit still applies.

Nope, that has already long been a thing of the past now. The limit is
now 128.
And if that's still not enough, then you can throw LVM on top and create
even more volumes. ;)

Oh, I should explain myself.

The disk geometry here is like this:

I have 2 Slackwares running, one working, one for backup and occasional
testing.
My own files, configuration files, Programs have a partition on their own,
and
I link them into the /home directories of the OSes, and up to now the /tmp
dirs
had their own partitions.

Now because I sometimes mess things up, I have another Slackware
running, very
small without X, with the purpose to run lilo (and perhaps go into the
working
OSes to repair a messed up configuration file). Ah, there is still
another one,
even smaller, to save FatDog configuration files.

Thus, all that remains in the single-digit area :-)


Thanks Erich







-

c·o·m·p·e·l·l·e·i·n·t·r·a·r·e·at·p·o·s·t·e·o·.·m·e

[Henrik Carlqvist]

Post by Henrik Carlqvist
If I remember right it at least used to be a limit of 15 partitions,
but I don't know for sure if that limit still applies.

Nope, that has already long been a thing of the past now. The limit is
now 128.

Are you sure? I tried to insert an USB stick in my Slackware 14.2 system

cat /etc/slackware-version

Slackware 14.2

uname -r

4.4.75

ls -al /dev/sd*

brw-rw---- 1 root disk 8, 0 May 9 2021 /dev/sda
brw-rw---- 1 root disk 8, 1 May 9 2021 /dev/sda1
brw-rw---- 1 root disk 8, 10 May 9 2021 /dev/sda10
brw-rw---- 1 root disk 8, 11 May 9 2021 /dev/sda11
brw-rw---- 1 root disk 8, 12 May 9 2021 /dev/sda12
brw-rw---- 1 root disk 8, 2 May 9 2021 /dev/sda2
brw-rw---- 1 root disk 8, 3 May 9 2021 /dev/sda3
brw-rw---- 1 root disk 8, 5 May 9 2021 /dev/sda5
brw-rw---- 1 root disk 8, 6 May 9 2021 /dev/sda6
brw-rw---- 1 root disk 8, 7 May 9 2021 /dev/sda7
brw-rw---- 1 root disk 8, 8 May 9 2021 /dev/sda8
brw-rw---- 1 root disk 8, 9 May 9 2021 /dev/sda9
brw-rw-rw- 1 root plugdev 8, 16 Nov 26 22:29 /dev/sdb
brw-rw-rw- 1 root plugdev 8, 32 Nov 27 12:15 /dev/sdc
brw-rw-rw- 1 root plugdev 8, 33 Nov 27 12:15 /dev/sdc1

As sda*, sdb* and sdc* share the same major number 8, sdb starts with
minor number 16 and sdc starts with minor number 32 it still seems as if
there are onnly 15 minor numbers left for partitions on each drive. Or
will /dev/sda16 get a major or minor number outside these series?

Looking at https://www.kernel.org/doc/Documentation/admin-guide/
devices.txt it seems as there is some kind of support for more partitions
with major number 259 but the file also says that scsi inferfaces like
/dev/sda has a limit of 15 partitions.

regards Henrik

[Henrik Carlqvist]

You appear to have an MBR-partitioned drive.

Yes, that is correct. I still boot using good old lilo.

GPT-partitioned drives either way do support 128 distinct partitions —
SCSI or not.

But does the device numbering with major and minor numbers depend upon
the type of partition?

regards Henrik

[Aragorn]

Post by Henrik Carlqvist

You appear to have an MBR-partitioned drive.

Yes, that is correct. I still boot using good old lilo.

GPT-partitioned drives either way do support 128 distinct
partitions — SCSI or not.

But does the device numbering with major and minor numbers depend
upon the type of partition?

I don't think so, no. I don't know how GPT handles partition device
numbers above 16, but I know it does support up to 128 partitions, and
that the Linux kernel can certainly handle it.

[eho]

Post by Henrik Carlqvist
I have seen people getting trouble to start X programs when their home
directory partition gets full. Could it be that /tmp and /home is on the
same partition? Otherwise, as you have seen, a full /tmp partition could
also give a lot of strange problems.
regards Henrik

No, I have /tmp on its own partition with 50G.
But I forgot, that SBo stores its files there,
and over the time it just grew. I could have
known...now I do...

Thanks erich