Slackware from Scratch and X11

ZhaoLin1457 · 01-13-2019, 03:19 AM

What if I want to build Slackware (From Scratch) for i686 instead of i586?

I am curious about how behaves a "pure" i686 Slackware compared with the official one.

Then, my question: SFS permits me to slightly change the architecture?

nobodino · 01-13-2019, 04:35 AM

I think you may have to edit every single SlackBuild to change ARCH:
-----------
if [ -z "$ARCH" ]; then
case "$(uname -m)" in
i?86) ARCH=i586 ;;
arm*) readelf /usr/bin/file -A | egrep -q "Tag_CPU.*[4,5]" && ARCH=arm || ARCH=armv7hl ;;
# Unless $ARCH is already set, use uname -m for all other archs:
*) ARCH=$(uname -m) ;;
esac
export ARCH
fi
---------
ARCH=i586 to ARCH=i686
If you may do it by hand, with awk/sed it should be possible?

ponce · 01-13-2019, 04:44 AM

for this specific case (i586 -> i686) consider also this

https://www.linuxquestions.org/quest...9/#post5406886

nobodino · 01-19-2019, 05:58 AM

regression test up to "Fri Jan 18 04:39:25 UTC 2019": pb with liblastfm
---------------------------
liblastfm-1.0.9/demos/demo1.cpp
liblastfm-1.0.9/demos/demo3.cpp
liblastfm-1.0.9/demos/demo2.cpp
liblastfm-1.0.9/CMakeLists.txt
liblastfm-1.0.9/README.md
CMake Error: No source or binary directory provided
make: *** No targets specified and no makefile found. Stop.
make: *** No targets specified and no makefile found. Stop.
---------------------------
same problem on Slackware and SFS.

worsel · 01-19-2019, 07:11 PM

Is anyone else having troubles with "su" on Slackware-current?

Action in past (as superuser): su - username
Result: logged in as username

Slackware-current as of Friday, 20190118: su - username
Result: if called from terminal, requests password. If called from script stops dead in terminal used.

I can't find this problem on the net and have run out of places to look. Advice needed.

TIA

abga · 01-19-2019, 07:53 PM

@worsel

If PAM is involved, this might help:
https://www.linuxquestions.org/quest...ssword-560989/

I only run -current on ARM and need to update it, but first I need to change the SDCard on the test box. Will try to replicate this, although I don't have PAM.

worsel · 01-19-2019, 11:58 PM

@abga

Slackware doesn't use PAM. Thanks for replying.

nobodino · 01-20-2019, 01:23 AM

Worsel: have you seen my post #510?

abga · 01-20-2019, 02:04 AM

Quote:

Originally Posted by worsel

@abga

Slackware doesn't use PAM. Thanks for replying.

You're welcome. I know it doesn't that's why I put if in front of the question (not a statement).
Work on PAM has been done:
http://www.slackware.com/~vbatts/pam/
And is still ongoing, unofficially:
https://github.com/Dlackware/pam
I asked about PAM, because of the nature of this thread (development, testing, goofin' around) and unable to "find this problem on the net" myself, but only the link I provided, related to PAM.

Now, I did change the SDCard on my Raspberry Pi running Slackware ARM -current, the old card went read-only - complete failure, updated the system and was unable to replicate your reported issue, whatever I tried, neither in console, nor in a script. Which leads me to believe that you might have some issues on your system: /etc/passwd* or data corruption related.
Try switching the user by also providing the shell type:

Code:

/bin/su - username -s /bin/bash

and see if it works, if positive, check your /etc/passwd* for inconsistencies.

If negative, I'd suggest to start a new thread dedicated to this, authentication issues are serious issues and need further investigation.

P.S. To exclude bash, as nobodino has apparently found some issues with it, try:

Code:

/bin/su - username -s /bin/sh

Alien Bob · 01-20-2019, 04:31 AM

On a clean uptodate slackware-current I do not see this weird "su -" behaviour.

nobodino · 01-20-2019, 04:41 AM

neither "/bin/su - sfs -s /bin/bash"

nor "/bin/su - sfs -s /bin/sh",

nor the old command "su - sfs"

works. It's blocked nowhere (see enclosed screen capture).

root@drakstart64:~/scripts# more /etc/passwd | grep sfs
sfs:x:1000:1000::/home/sfs:/bin/bash

If I revert to bash-4.4.023, everything is ok.

nobodino · 01-20-2019, 08:16 AM

I modified the script prep-sfs-tools so that the operator enter 'su -f sfs' manualy.

nobodino · 01-20-2019, 11:30 AM

nota: liblastfm solved in -current

worsel · 01-20-2019, 03:10 PM

Quote:

Worsel: have you seen my post #510?

Yes, but somehow didn't relate it to this problem. Mea culpa!

Quote:

I modified the script prep-sfs-tools so that the operator enter 'su -f sfs' manualy.

I was looking into this, but hadn't got it to work. Will try it today.

abga · 01-20-2019, 06:46 PM

Quote:

Originally Posted by nobodino

neither "/bin/su - sfs -s /bin/bash"

nor "/bin/su - sfs -s /bin/sh",

nor the old command "su - sfs"

works. It's blocked nowhere (see enclosed screen capture).

root@drakstart64:~/scripts# more /etc/passwd | grep sfs
sfs:x:1000:1000::/home/sfs:/bin/bash

If I revert to bash-4.4.023, everything is ok.

My fault, to entirely exclude bash would have required to start as root with /bin/sh, because otherwise you'd be already using bash...

Code:

sfs-or-other-username$ /bin/su - -s /bin/sh
root# echo $SHELL
root# /bin/su - sfs -s /bin/sh
sfs$ echo $SHELL

Your /etc/password entry is valid and I'm happy you found out that bash 5.0 was causing the issue.

Don't know how could bash cause such an issue, by not passing the right arguments to su (which is part of the shadow package)?
Try running a strace as root under bash 5.0:

Code:

mkdir /tmp/trace && cd /tmp/trace
/usr/bin/strace -o bash-du-trace -ff su - sfs
exit
# and inspect the bash-du-trace.* files in /tmp/trace

and see if you can catch something. Prepare a second tty to be able to kill the strace as it might get the tty locked.