SliTaz Forum
You are not logged in.
Greetings, all.
I am running Slitaz rolling 32-bit as a full HD install, cohabiting with other OS booting from Grub4DOS.
System is an old 1.7Ghz Pentium III with 1G of mem, and lots of disk space.
I have a recurrent problem with users becoming invalid - now the only user that can log in is "root". When this happened before, I usually had to re-install Slitaz, but I'd rather know how to fix it without a re-install. Once only, I was able to get things working again by deleting and then recreating all users. That did not work this time.
I have never been able to be sure what triggers this - tho this time it happened when I updated 285 packages at once after a couple of months of not logging on to this OS.
Also right after that large update, I cannot now update any more. Packages download and install (as root), but disappear on reboot. I repeat, this is a full HD install, not a Live system.
I assume they are related problems because they occurred at once.
Any ideas how to fix this?
Slizzard
Offline
Hi Slizzard,
please check if the ownership of home directories triggers the problem.
You could login as root and:
1) cd /home
2) chown -R tux.users tux
(other users respectively)
Offline
Filou;
Thanks for responding.
I am as much interested in understanding the issue as I am in merely fixing it. If I understand that command, it would set the ownership of all files in the 'tux' home directory recursively to 'tux' in the group 'users'.
But using the PCManFM context-menu to check ownership of the HOME directories, owner and group are shown as already correct for the various user HOME dirs and all their subdirs. Under these existing conditions, can chown accomplish anything?
Slizzard
Offline
Hello Slizzard,
in the (longer) past I had several occasions when I stumbled across a similar or the same problem. While I did not deeply search for the issue (I suspect some script copying X-relevant config files into the home directories), re-setting the ownership most often was a quick solution.
Maybe you could try for one user and if this works, search in another user directory for the misconfigured files?
Another try may be so search for files owned by (?) root (?) in your user directory:
[c]find /home/[user] -user root[/c]
Offline
Greetings again, FIlou,
and thanks for your continuing interest.
I tried the search for root-owned files in all the other user's home directories, but found none.
I also tried chowning one of the users homes as a test, and verified afterward that ownership & groupship were (still) correct, but I still could not log in as that user.
I have also tried creating brand-new users, but I can't log in as them either. I suspect this malfunction of a brand-new user, in the same manner, argues against accidental inclusion of any disruptive file as the cause?
The other problem mentioned in the opening post may be related, they both did occur at same time, so I will mention it again. I looked further back into the TazPkg log and found that the 7 files that perpetually demand upgrade, were included in the 285-file blomf. All other packages in that blomf are properly recognised as up-to-date. Only the 7 oddballs perseverate & continue to be unrecognised as already up-to-date. I checked the file specs of the 7 before and after an update, and they are indeed the same before and after. So its a systemic recognition problem of some sort, as apparently is the user issue. What do these two issues depend on in common that could explain this?
If you think this is a totally unrelated issue we can henceforth ignore it while exploring the user log-in issue only.
Slizzard
Offline
Hi Slizzard,
what puzzles me is the fact, that root can still login while the users cannot, which seems to point at a permission problem rather than anything else.
... maybe another way ...
Could you
1.) login via tty (press Ctrl+Alt+1 from slim login) as root
2.) [c]killall slim[/c] to free up X-server
3.) login as a user (maybe from tty2)
4.) [c]startx &> login.log[/c]
The contens of login.log may give a hint why X fails to start for the user, pointing us in the right direction of the problem... (search for (EE) entries in the log).
Offline
@ Slizzard,
Concerning "the 7 files that perpetually demand upgrade", maybe these packages are provided by another one. ie:
[c]gcc83-lib-base[/c] provides [c]gcc-lib-base[/c]; if [c]gcc83-lib-base[/c] was installed after [c]gcc-lib-base[/c] and a new build for [c]gcc-lib-base[/c] is available on the mirror, Tazpkg will install... [c]gcc83-lib-base[/c]and next time you run [c]tazpkg update[/c], Tazpkg will tell you that you need to update [c]gcc-lib-base[/c]. That's a no-end story.
To avoid this, remove the provided packages; but to do this you have first to remove the packages that provide them. For the example above:
[c]tazpkg -r gcc83-lib-base
tazpkg -r gcc-lib-base
tazpkg -gi gcc83-lib-base[/c]
Offline
Greetings again, Filou...
You wrote:
Could you
1.) login via tty (press Ctrl+Alt+1 from slim login) as root
I wish I could!
Is 'slim' (Simple Log In Manager) the normal (snow-scene) login manager? If so, it does not respond to a Ctrl-Alt-1 key sequence. It ignores the control keys and enters the '1' in the active field. If slim is NOT the regular login manager, then how do I access slim from the normal login manager?
Ctrl-Alt-Bkspc out of the regular login-manager does not give me much time to try anything else before re-starting login again. I can barely do Ctrl-Alt-Del fast enough to get a reboot reliably, and could not get things to halt using Ctrl-C to stop the startup script. PAUSE key seems to be ignored by the system - or I can't hit it fast enough.
Assuming 'slim' is another login manger altogether, I opened a terminal and typed 'slim'. No Joy.
Please clarify how to access 'SLIM'.
I tried to use PCManFM's FIND function to look for any existing boot log files, but PCmanFM's FIND function appears to be a bit crippled - it seems incapable of searching for files by extension, only by main name or by content. Sheesh.
Thanks for persisting...
Slizzard
Offline
I don't know the reasons, but during testing I got the same error...
The cause is the invalid home/tux (0 bytes)
The remedy: login as root, open terminal and then
rm -rf /home/tux
/etc/init.d/bootopts.sh
logout session and login tux
everything seems to work normally.
I traced the problem back to the boot error
cp: can't stat '/home/tux/skel': Not a directory
Offline
Greetings Ceel;
Thanks for your response.
regarding "the 7 files that perpetually demand upgrade"...
You wrote, " ... That's a no-end story."
They look like mostly essential system files to me...
busybox
dropbear
libcap
partimage
ppp
slim
udev
"slim" being in the list may help to explain why login is not working correctly (the simultaneously-occuring issue), but I don't know enough to decide on that.
I also don't know how to query which dependencies are shared, and which will screw me if I -r them. It seems pretty risky to just go ahead and tazpkg -r busybox, for instance.
Isn't there supposed to be safeguards against such circular dependency cycles? If they are not working in this case, isn't this a bug? Should I file a bug report on this?
Since I did not initiate the installation of any of these files (they were installed automatically during a regular update) I don't know which other programs/packages/dependencies they are associated with. I'd need to query that somehow, but I don't know how. And even then, deleting system files is not the kind of thing I do very lightly. Or at all, much.
Slizzard
Offline
Greetings, gibor,
Thanks for chipping in on this.
You wrote:
The cause is the invalid home/tux (0 bytes)
On my problem system, the /home/tux directory is not invalid. All of the contents are readable and editable. Ownership and group are also correct.
You wrote:
open terminal and then
rm -rf /home/tux
/etc/init.d/bootopts.sh
That (delete, forcibly and recursively) would destroy all my files, customizations, and settings, which I am loath to do. I have had to restore them too often already because of this bug and others in SliTaz. Restoring files to my home directory in SliTaz also often results in improperly owned files (another bug, in my opinion) that have to be chowned back to me. I especially don't want to do all this work if it won't fix the problem, as I believe it won't because the /home/tux directory is not invalid.
I have already tried deleting all users and restoring them using the GUI (instead of the CLI), which has worked before, but it did not work this time. Isn't that doing the same thing?
Please correct any misunderstandings I have about this.
I cannot really understand what the commands in /etc/init.d/bootopts.sh do, but they do NOT seem to recreate the deleted /home/tux directory (they do check if there is one, but after that I can't decipher), so unless I recreated the user TUX before loggiing out, I wouldn't be able to log in again as tux, would I?
Re:the error source you mentioned,
cp: can't stat '/home/tux/skel': Not a directory
I am not sure that applies to my system. Certainly there is no /home/tux/skel directory on my system (hidden or otherwise) but there isn't supposed to be, either. None of the Live-USB's have this dir, and they log in correctly.
I believe there are some boot-up error messages for DIRs not found, that may be related to uninstallation of ClamAV. Would it be at all helpful to record those and post them?
Slizzard
Offline
A freshly executed installation has no customizations. moreover if the user "tux" is not loggable.
However I also wrote that I don't know the cause of the error, although it seems to be a remnant of the installer running on the first reboot.
The error was " failed to login command"
By logging in as root I access the root home "/root" and do not change any customization of the user "tux".
In any case you can always rename the folder "/home/tux" to "/home/tuxold" and run the command /etc/init.d/bootopts.sh
This recreates by taking the source from /etc/skel and populates the "home/tux" folder by assigning the necessary permissions.
Have a nice day.
Offline
@ Slizzard
Seeing the packages concerned, it cannot be what I suggested.
Please could you
[*]change in [c]/var/lib/tazpkg[/c];
[*]verify for each file inside that permissions [c]Owner[/c] is [c]root[/c] and [c]Change content[/c] is [c]Only owner[/c];
[*]look and note at the md5 of the 7 packages in [c]installed.mdb5[/c];
take care at the version of the packages, there is a line for each version that has been installed
[*]compare (and note) at the one in [c]packages.md5[/c] and the one of its last update in [c]/var/log/slitaz/tazpkg.log[/c]
What are they?
Offline
Hi all,
please excuse me, I was mistaken:
for step 1 of my last post, use Ctrl+ Alt+ F1 (instead of '1') to switch to tty.
Maybe then you could try the rest as described?
Offline
Ceel & Filou,
Thanks again for your help.
I am away from the machine with the problem, I will try your suggestions when I get back to it.
I am currently signed in from a Live USB instance of Slitaz on someone else's computer.
Greetings again gibor, and thanks for helping.
I looked up bootopts.sh to see if I could understand what it does.
Slitaz Scratchbook says ...
"This script is used to configure the LiveCD options passed at boot time... (etc)" but the way you are mentioning it, that seems to be only a partial explanation.
Your explanation was actually more helpful!
Does bootopts.sh give a very different result from using TazPanel to create a new user? TazPanel doesn't produce log-innable new users since the malfunction started. It will be interesting to see if bootopts.sh does produce a log-innable user, when I get back to the machine in question.
Thanks all, until later,
. Slizzard
Offline
For any other inexperienced Linux users who are reading this thread, the following page may be helpful to understand Filou's suggestion regarding Ctrl-Alt-F1. Especially useful is knowing how to get out of the virtual terminal once you are in it...
https://askubuntu.com/questions/157617/reverting-from-ctrl-alt-f1
Slizzard
Offline
Greetings Filou;
I tried your suggestions.
I could login to tty1 as root and killed slim.
I tried to log in to tty2 as 2 other different valid users, but same issue as with slim: would not accept valid users & passwords (they show up OK in TazPanel).
SO I could not write a login record from another user, but I did so from root back at tty1.
Started X as root. looked at file.
There were no EE errors flagged in the login.log, but there were some other errors...
(process:1721): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
error: Broken zip file structure
error: Broken zip file structure
** (lxpanel:1706): WARNING **: Battery 0 not found
error: Broken zip file structure
error: Broken zip file structure
** (lxpanel:1706): WARNING **: Battery 0 not found
Obt-Message: Failed to open an Input Method
** (lxpanel:1706): WARNING **: lxpanel : X error: BadWindow (invalid Window parameter)
** (lxpanel:1706): WARNING **: lxpanel : X error: BadWindow (invalid Window parameter)
(pcmanfm:1700): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
(process:1784): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
Are these irrelevant?
Slizzard
Offline
Greetings Ceel;
Thanks for your continuing attention.
MD5 in files named installed.md5, packages.md5, and tazpkg.log all match.
Here they are:
64efc014876ba3f4b55470dc50d85f03 busybox-pam-1.31.1.tazpkg
f87ec2e9ca01fa2af63f20759e1e9441 dropbear-pam-2022.83.tazpkg
20a221c891fabcba647ab4cf5630240c libcap-pam-2.63.tazpkg
6db691904871a8e5c7f3fa3d2067d13a partimage-pam-0.6.9.tazpkg
e1c9c42eb0e38c6df34de550bcb16b06 ppp-pam-2.4.7.tazpkg
9ca25168d210001379baed42f5c9b32d slim-pam-1.3.6.tazpkg
0605e35bb6f19436da91e0c49677a095 systemd-195.tazpkg
(edit) Oh, I forgot to say - All file permissions were checked and were correctly owned by root with change by owner only.
Slizzard
Offline
Greetings gibor;
I tried your suggestions...
From the CLI as root, I removed the tux home directory.
Then I ran bootopts.sh to recreate it, and closed the terminal.
I tried to log out of the desktop, but could not do so normally with the GUI options. The panel and the icons went away, but the desktop would not.
So I got out with Ctrl-Alt-Bkspc.
I typed "reboot" and it asked for a password - but refused to accept the root password.
So I rebooted with Ctrl-Alt-Del, and then tried to log in as tux. No joy. Still can only log in as root.
Does anyone have any more ideas I can try?
Slizzard
Offline
Hi Slizzard,
strange that login as user is not even possible in tty.... :-/
Can you confirm that all users are present in /etc/passwd as well as in/etc/shadow?
Offline
Greetings again Filou;
I glad you are persisting in this!
All expected users are present in /etc/passwd and /etc/shadow.
Users nobody, www, partimag, & mysql, are also present. I assume these are system requirements?
However, one test user that I had deleted a long time ago, which no longer has a home directory on disk, nor any presence in the Tazpanel users manager, is also present. What would happen if I deleted that line from the passwd and shadow files?
Here's the line in shadow:
Test+User::19372:0:99999:7:::
and in passwd:
Test+User:x:1002:100:testuser:/home/Test+User:/bin/sh
This invalid user listing comes just before the two users which can never log in (which includes tux). Is it possible that the invalid entry is aborting processing of the two lines that follow, so that the subsequent users do not exist as far as the system is concerned??
Slizzard
Offline
Cheers Slizzard!
At least this might be an indication and a username with a "functional" character (like +, &, *, ...) have a very high potential for creating problems.
You should be safe to simply delete those lines from both files.
Good luck!
Offline
Filou;
I deleted the lines from the two files, and rebooted.
Still can only log in with root.
But at least it did not cause any other problems!
Slizzard
Offline
You didn't tell us you were using [c]pam[/c]... Wouldn't be your login issue appears since you installed it?
Here is your update "problem":
busybox-pam: PROVIDE="busybox:pam"
dropbear-pam: PROVIDE="dropbear:pam ssh:pam"
libcap-pam: PROVIDE="libcap:pam"
partimage-pam: PROVIDE="partimage:pam"
ppp-pam: PROVIDE="ppp:pam"
slim-pam: PROVIDE="slim:pam"
systemd: PROVIDE="udev"
You should be able to solve it like this:
[*]boot from a live session
[*]open a terminal as root
[*]mount the disk where Slitaz is installed (say in [c]/mnt[/c])
[*]remove [c]busybox-pam[/c], [c]dropbear-pam[/c], [c]libcap-pam[/c], [c]partimage-pam[/c], [c]ppp-pam[/c], [c]slim-pam[/c], [c]pam[/c] and [c]systemd[/c]:
[c]tazpkg -r <package_name> --root=/mnt[/c]
[*]remove [c]busybox[/c], [c]dropbear[/c], [c]libcap[/c], [c]partimage[/c], [c]ppp[/c], [c]slim[/c] and [c]udev[/c] in the same way
[*]re-install [c]systemd[/c], [c]pam[/c] and the [c]*-pam[/c] packages:
[c]tazpkg -gi <package_name> --root=/mnt[/c]
[*][c]umount /mnt[/c] and reboot.
Is your login issue still here? at least [c]tazpkg up[/c] shouldn't ask to you to update the 7 packages.
Offline
Ceel;
Thanks for the revelation!
The only "pam" I know about is for spraying on frying pans so food doesn't stick.
Tazpkg.log says pam was first installed (or first upgraded) in june 2022 as part of an update of about 40 pkgs, so this was a tazpkg choice, not a user choice, Interestingly, pam did not cause any problems until the most recent blomf of 200+ updates - when it was upgraded to v.1.2.0. So this suggests that upgrade is what triggered the current pam issues.
Tazpanel's description of the pam package says its a "pluggable authentication module", which tells me nothing at all useful, and I can't find any useful information by searching the forum. I'm not a dev.
If pam is an optional & unnecessary program, why don't I just uninstall it using tazpanel? Won't tazpanel then remove all the dependent *-pam other files as well?
I'd like to remind you that this problem has occurred multiple times, and is always a pain in the ass to fix. This time I'd like to understand it, and hopefully find a way to fix it quickly and easily when it next occurs. Even better would be if the devs recognised it as their issue, and fixed it in the distro.
Slizzard
Offline
[ Generated in 0.019 seconds, 7 queries executed - Memory usage: 1.61 MiB (Peak: 1.77 MiB) ]