SliTaz Forum

Users become unusable

(28 posts) (4 voices)

• Started 1 year ago by Slizzard
• Latest reply from Ceel
• This topic is not resolved

Tags:

No tags yet.

1. 

   Slizzard
   

   offline

   Member

   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

   Posted 1 year ago #
2. 

   Filou
   

   offline

   Moderator

   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)

   Posted 1 year ago #
3. 

   Slizzard
   

   offline

   Member

   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

   Posted 1 year ago #
4. 

   Filou
   

   offline

   Moderator

   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:
   find /home/[user] -user root

   Posted 1 year ago #
5. 

   Slizzard
   

   offline

   Member

   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

   Posted 1 year ago #
6. 

   Filou
   

   offline

   Moderator

   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.) killall slim to free up X-server
   3.) login as a user (maybe from tty2)
   4.) startx &> login.log

   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).

   Posted 1 year ago #
7. 

   Ceel
   

   offline

   Administrator

   @ Slizzard,

   Concerning "the 7 files that perpetually demand upgrade", maybe these packages are provided by another one. ie:

   gcc83-lib-base provides gcc-lib-base; if gcc83-lib-base was installed after gcc-lib-base and a new build for gcc-lib-base is available on the mirror, Tazpkg will install... gcc83-lib-baseand next time you run tazpkg update, Tazpkg will tell you that you need to update gcc-lib-base. 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:
   

   tazpkg -r gcc83-lib-base
   tazpkg -r gcc-lib-base
   tazpkg -gi gcc83-lib-base

   Posted 1 year ago #
8. 

   Slizzard
   

   offline

   Member

   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

   Posted 1 year ago #
9. 

   gibor
   

   offline

   Moderator

   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

   Posted 1 year ago #
10. 

    Slizzard
    

    offline

    Member

    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

    Posted 1 year ago #
11. 

    Slizzard
    

    offline

    Member

    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

    Posted 1 year ago #
12. 

    gibor
    

    offline

    Moderator

    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.

    Posted 1 year ago #
13. 

    Ceel
    

    offline

    Administrator

    @ Slizzard

    Seeing the packages concerned, it cannot be what I suggested.

    Please could you

    • change in /var/lib/tazpkg;
    • verify for each file inside that permissions Owner is root and Change content is Only owner;
    • look and note at the md5 of the 7 packages in installed.mdb5;
      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 packages.md5 and the one of its last update in /var/log/slitaz/tazpkg.log

    What are they?

    Posted 1 year ago #
14. 

    Filou
    

    offline

    Moderator

    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?

    Posted 1 year ago #
15. 

    Slizzard
    

    offline

    Member

    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

    Posted 1 year ago #

RSS feed for this topic

Reply »

You must log in to post.