Setting up a chroot to make packages (Slackware 15)

wazoox · 04-20-2022, 04:45 PM

To build clean packages using sbopkg, I've made a chroot. Install into a folder, then mount -B /dev, /dev/pts, /sys, /proc and finally chroot in the folder.

It seems to work fine at first glance, but all sort of programs fail in weird ways:

Code:

# vi /etc/hosts
DB_CREATE must be specified to create databases.
DB_CREATE must be specified to create databases.
DB_CREATE must be specified to create databases.
DB_CREATE must be specified to create databases.
ex/vi: Error: /var/tmp/vi.recover: Value too large for defined data type
ex/vi: Modifications not recoverable if the session fails
ex/vi: Error: /etc/hosts: No such file or directory
ex/vi: Error: /var/tmp/vi.recover: Value too large for defined data type
ex/vi: Modifications not recoverable if the session fails
ex/vi: Error: /tmp/vi.B270ls: No such file or directory

"vim" or "elvis" work fine, though. Weird...

Then it gets weirder:

Code:

# slackpkg update

No 'which' command found, please install it if you want to
use slackpkg.

"which" is there, though, but then it gets crazy:

Code:

# which ls
/usr/bin/ls
# which which
which: no which in (/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/lib/libexec/kf5:/usr/lib/qt5/bin)

What's really incredibly bizarre is that "strace which which" shows which finding itself in /bin and /usr/bin, but falling through... What the heck is happening?

ozanbaba · 04-21-2022, 01:20 AM

I recommend you check the file permissions. It could be mixed up file permissions. For example, what is the permissions of which? Also how strace shows which fails to find which?

wazoox · 04-21-2022, 02:35 AM

Quote:

Originally Posted by ozanbaba

I recommend you check the file permissions. It could be mixed up file permissions. For example, what is the permissions of which? Also how strace shows which fails to find which?

I've thought about that, the permissions are fine:

Code:

$ ls -l /bin/which 
-rwxr-xr-x 1 root root 26132 févr. 14  2021 /bin/which*
$ ls -l chroot/bin/which 
-rwxr-xr-x 1 root root 26132 févr. 14  2021 chroot/bin/which*

I've also checked the permissions or chroot/, chroot/tmp, chroot/var/tmp...

Code:

$ ls -ld /
drwxr-xr-x 23 root root 4096 avril 15 16:01 //
$ ls -ld chroot/
drwxr-xr-x 20 root root 4096 janv. 25 00:20 chroot//
$ ls -ld chroot/tmp/
drwxrwxrwt 4 root root 61 avril 20 23:52 chroot/tmp//
$ ls -ld /tmp
drwxrwxrwt 412 root root 110592 avril 21 04:40 /tmp/

I've basically done everything as explained in https://docs.slackware.com/howtos:ge...ackware_chroot

That's really annoying!

Windu · 04-21-2022, 03:04 AM

The size and timestamp of those 'which' binaries are matching with a Slackware 15.0 32bit installation, right? I.e. your Slackware OS as well as the chroot installation are both 32bit?
What is the exact command you are using to enter your chroot?

wazoox · 04-21-2022, 03:11 AM

Quote:

Originally Posted by Windu

The size and timestamp of those 'which' binaries are matching with a Slackware 15.0 32bit installation, right? I.e. your Slackware OS as well as the chroot installation are both 32bit?

Yep, both 32 bits.

Quote:

What is the exact command you are using to enter your chroot?

Simple:

Code:

su
cd chroot/
for F in proc sys dev dev/pts; do mount -B /$F $F ; done
chroot .
su -

I use exactly the same method with a Debian chroot on a Debian machine and it works perfectly fine. The "su -" in the end is the best way to set up a proper env.

Gerard Lally · 04-21-2022, 03:19 AM

Why cd to chroot and then bind mount proc sys and dev? Doesn't that mean you are not mounting the system's proc, sys and dev in the chroot?

Leave out the cd /chroot , then bind mount the system's proc, sys and dev to /chroot/$F , and finally do chroot /chroot .

wazoox · 04-21-2022, 03:55 AM

Quote:

Originally Posted by Gerard Lally

Why cd to chroot and then bind mount proc sys and dev? Doesn't that mean you are not mounting the system's proc, sys and dev in the chroot?

Absolutely not, it works fine. That makes no difference at all to use absolute or relative mount points. I've made the test, and it's exactly the same.

Windu · 04-21-2022, 10:46 AM

Your chroot directory, it is perhaps not an actual directory in your Slackware filesystem but a loop-mounted container, or perhaps a network-mounted filesystem?

wazoox · 04-21-2022, 02:25 PM

Quote:

Originally Posted by Windu

Your chroot directory, it is perhaps not an actual directory in your Slackware filesystem but a loop-mounted container, or perhaps a network-mounted filesystem?

No, that's the most ordinary folder in an XFS filesystem.