LinuxQuestions.org - Setting up a chroot to make packages (Slackware 15)

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Setting up a chroot to make packages (Slackware 15) (https://www.linuxquestions.org/questions/slackware-14/setting-up-a-chroot-to-make-packages-slackware-15-a-4175711043/)

Setting up a chroot to make packages (Slackware 15)

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?

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?

Quote:

Originally Posted by ozanbaba (Post 6347645)

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!

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?

Quote:

Originally Posted by Windu (Post 6347660)

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.

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 .

Quote:

Originally Posted by Gerard Lally (Post 6347664)

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.

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?

Quote:

Originally Posted by Windu (Post 6347738)

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.