[SOLVED] What's up with Slackware?

Richard Cranium · 06-10-2019, 12:53 AM

Quote:

Originally Posted by ceh383

Ok, I'll take your word for it.

But, I am puzzled as to why I got the exact same errors when trying to install -current as I did with 14.2 with the /usr partition.

Please enlighten me.

The -current aaa_elflibs package nonetheless puts those libraries in /usr/lib[64].

I've fiddled around with this in my initrd's init script...

Code:

  # Switch to real root partition:
  /sbin/udevadm settle --timeout=10
  echo 0x0100 > /proc/sys/kernel/real-root-dev
  mount -o ro -t $ROOTFS $ROOTDEV /mnt
  
  if [ ! -r /mnt/sbin/init ]; then
    echo "ERROR:  No /sbin/init found on rootdev (or not mounted).  Trouble ahead."
    echo "        You can try to fix it. Type 'exit' when things are done." 
    echo
    /bin/sh
  else
      # see if fstab has a /usr entry; if so, attempt to mount it.
      USRLINE=$( /bin/grep -E "^/[^[:space:]]+\s+/usr\s+.*" /mnt/etc/fstab )
      if [ "${USRLINE}" ]; then
          read USRDEV USRMP USRFS DK1 DK2 DK3<<EOF
${USRLINE}
EOF
          mount -o ro -t ${USRFS} ${USRDEV} /mnt/usr
      fi
  fi

...but I've pretty much given up having a separate /usr partition on most of my servers.

ehartman · 06-10-2019, 02:58 AM

Quote:

Originally Posted by Richard Cranium

The -current aaa_elflibs package nonetheless puts those libraries in /usr/lib[64].

Thanks for that addition, I wasn't sure about that.
I did see once some library being moved from /usr/lib to /lib because of some startup
error, but Pat did say that he wasn't going out of the way to keep /usr mountable.
Anyway, none of my systems DO have a separate /usr filesystem.

ehartman · 06-10-2019, 10:38 AM

Quote:

Originally Posted by ehartman

I did see once some library being moved from /usr/lib to /lib because of some startup error, but Pat did say that he wasn't going out of the way to keep /usr mountable.

I've found the reference in -current's ChangeLog:

Quote:

Entry for Fri Dec 28 00:23:43 UTC 2018
Moved shared library into /lib{,64} to avoid problems when /usr is on a separate partition. Thanks to TommyC7.
But please note: that has never been a recommended configuration (it was always a bad idea prone to corner-case bugs), and with basically everyone else moving everything into /usr, no upstream is developing with this scenario in mind these days. Some of the problems caused by separate /usr are simply not possible to fix in a straightforward fashion. Consider it a completely unsupported configuration choice. While it's not my style to make the installer refuse to allow it, I won't be bending over backwards to try to fix bugs related to this in the future. If I recall properly, the original rationale was to make it possible for /usr to reside on a shared network partition, which might have made sense back when 40MB was a typical hard drive size. I can think of no good rationale now (and no, I don't think making /usr read-only helps security in any tangible way).

So essentially having /usr on a separate, mountable partition is not really supported in Slackware.

BTW: with current disk sizes the whole split of /bin vs /usr/bin, /lib vs /usr/lib and /sbin vs /usr/sbin is outdated, some distributions have already done away with it.

ceh383 · 06-10-2019, 09:45 PM

Quote:

Originally Posted by ehartman

I've found the reference in -current's ChangeLog:

Quote:

Entry for Fri Dec 28 00:23:43 UTC 2018
Moved shared library into /lib{,64} to avoid problems when /usr is on a separate partition. Thanks to TommyC7.
But please note: that has never been a recommended configuration (it was always a bad idea prone to corner-case bugs), and with basically everyone else moving everything into /usr, no upstream is developing with this scenario in mind these days. Some of the problems caused by separate /usr are simply not possible to fix in a straightforward fashion. Consider it a completely unsupported configuration choice. While it's not my style to make the installer refuse to allow it, I won't be bending over backwards to try to fix bugs related to this in the future. If I recall properly, the original rationale was to make it possible for /usr to reside on a shared network partition, which might have made sense back when 40MB was a typical hard drive size. I can think of no good rationale now (and no, I don't think making /usr read-only helps security in any tangible way).

Quote:

Originally Posted by ehartman

So essentially having /usr on a separate, mountable partition is not really supported in Slackware.

BTW: with current disk sizes the whole split of /bin vs /usr/bin, /lib vs /usr/lib and /sbin vs /usr/sbin is outdated, some distributions have already done away with it.

Thanks all for the information, this is good stuff.
While I now know this is an unsupported/unwise partition scheme at this point in time, it did work well with 13.37.
Given the years of rock solid performance I got from 13.37 I did not see any reason to change the scheme.
Well, live and learn...

Thanks again.

bassmadrigal · 06-15-2019, 01:30 PM

Quote:

Originally Posted by enorbet

While some will argue that there is some value in employing a separate partition for "/home" and there certainly are even better arguments for a separate "/boot" partition

With UEFI requiring its own partition, a separate partition for /boot probably only makes sense on legacy booting systems.

Didier Spaier · 06-16-2019, 07:53 AM

Quote:

Originally Posted by enorbet

there certainly are even better arguments for a separate "/boot" partition

Which arguments? I ask, because I never had one and don't seem to miss one. Maybe for specific use cases?

LuckyCyborg · 06-16-2019, 08:01 AM

Quote:

Originally Posted by Didier Spaier

Which arguments? I ask, because I never had one and don't seem to miss one. Maybe for specific use cases?

You need a separate boot partition (or device) at least when your root filesystem is hosted either on an encrypted partition, or it is on a device using an RAID design other than RAID1, like: RAID0, RAID10, RAID5 or RAID6

LuckyCyborg · 06-16-2019, 08:06 AM

Quote:

Originally Posted by bassmadrigal

With UEFI requiring its own partition, a separate partition for /boot probably only makes sense on legacy booting systems.

BUT, that UEFI partition counts as a separate boot partition anyways...

bassmadrigal · 06-16-2019, 02:23 PM

Quote:

Originally Posted by LuckyCyborg

BUT, that UEFI partition counts as a separate boot partition anyways...

That's not what I said though. I never said anything about a separate boot partition, rather I said a separate partition for /boot doesn't make sense. UEFI partitions aren't mounted on /boot, but /boot/efi

Prior to UEFI, I never had a separate partition for /boot

Drakeo · 06-16-2019, 02:38 PM

Ask the Trump like leader Pat. seems we are all lost looking at his change log Richard

ZhaoLin1457 · 06-16-2019, 03:25 PM

Quote:

Originally Posted by bassmadrigal

I said a separate partition for /boot doesn't make sense.

Just because you do not use a particular feature, that does not transform it in non-sense. Contrary, maybe your own use case could be just "a corner case" .

Permit me to give an example which cannot be superseded by UEFI partition: a system with redundancy.

A friend of mine, who seems to care much for his data (and explained me what he did) uses 4 hard drives, with 4 partitions (one on each one) assembled in a RAID1 and other 4 partitions assembled in a partitioned RAID5 device for system and data.

Usually, that computer boots from /dev/sda1 (which is part of the /boot raid) but IF the first drive fails and it is not recognized anymore by the motherboard, the second drive takes over, booting the system, which survives well with its RAIDs in degraded mode.

From what I understand, those RAID assemblies are heavily used at least on servers and/or businesses for redundancy. Then I do not think that's just "a corner case" .

bassmadrigal · 06-16-2019, 04:39 PM

Quote:

Originally Posted by ZhaoLin1457

Just because you do not use a particular feature, that does not transform it in non-sense. Contrary, maybe your own use case could be just "a corner case" .

Permit me to give an example which cannot be superseded by UEFI partition: a system with redundancy.

A friend of mine, who seems to care much for his data (and explained me what he did) uses 4 hard drives, with 4 partitions (one on each one) assembled in a RAID1 and other 4 partitions assembled in a partitioned RAID5 device for system and data.

Usually, that computer boots from /dev/sda1 (which is part of the /boot raid) but IF the first drive fails and it is not recognized anymore by the motherboard, the second drive takes over, booting the system, which survives well with its RAIDs in degraded mode.

From what I understand, those RAID assemblies are heavily used at least on servers and/or businesses for redundancy. Then I do not think that's just "a corner case" .

Great, you explained the benefits of RAID and mirroring data on multiple drives, but what does this have to do with having /boot as a separate partition on a UEFI-based system? You can have your UEFI partition mirrored across multiple drives for redundancy, and have each partition bootable in the UEFI firmware, but on a UEFI system, having /boot as a separate partition seems unneeded.

Just in case you were unclear, I said a separate /boot partition probably only makes sense on legacy booting systems, in which case, it will depend on the circumstances of that system on whether or not it's worth it.

enorbet · 06-17-2019, 02:47 PM

All this may beg the question what the hell the value is of UEFI to a Linux SOHO system? Cost/Benefit please. I don't see any major value to me at the cost of a lot of extra work.

TheRealGrogan · 06-17-2019, 04:28 PM

Sorry, I posted to the wrong thread.

bassmadrigal · 06-17-2019, 09:25 PM

Quote:

Originally Posted by enorbet

All this may beg the question what the hell the value is of UEFI to a Linux SOHO system? Cost/Benefit please.

There really isn't a huge benefit that I'm aware of[1] in using UEFI other than the fact that BIOS is pretty much already gone and legacy or CSM (Compatibility Support Module) will eventually go away...

Quote:

Originally Posted by enorbet

I don't see any major value to me at the cost of a lot of extra work.

By no means am I suggesting people switch to UEFI. In my systems, I solely chose that because I knew it was going to happen at some point, so I figured why not now (which was actually like 2-3 years ago)? (And it ended up being a very simple transition for me and my usage.) My posts were strictly to say that on UEFI systems, there is probably little to no need to run a separate /boot partition. On MBR or legacy booting, there are still reasons for it, depending on how you use your system.

[1] Some BIOS-based systems or systems using legacy/CSM booting might have a limitation on not supporting 3TB drives for booting. Strictly speaking, this is an MBR limitation and requires using GPT for the partitioning, and GPT is not officially supported for booting by BIOS. Some BIOSes and bootloaders have been able to work around this limitation, but not all.