Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I installed Mint 17 xfce onto a friend's HP netbook a few months ago. Up until now all has been working pretty perfectly.
From this evening, she tells me that after she types in her password the following message appears:
no exec. line in this session file [her password appears here in plain text!] running the GNOME failsafe session instead
The only option at this point is seemingly to click ok. After that, this message appears:
Could not find the GNOME installation will try running the failsafe xterm session
Again the only option is to click ok, then this appears for a few seconds:
Cannot find xterm start a failsafe session
Then it goes to a black screen (though you can see the mouse cursor) on which it stays indefinitely.
She tells me that she wasn't trying to do anything other than web browsing and email checking before this started happening so there doesn't seem to be any logical reason behind it. Does anybody have any idea what is happening and how to fix it?
Can you do CTRL-ALT-F1 and get a system console, then login at that point? If yes, then I'd suggest an apt update, followed by trying to re-install gnome with the force option. There may be options to fix gnome from that console, just beyond my knowledge. If you can't get a system console, then unfortunately I'd try a re-install.
As a last alternative to a full reinstall if you can't get a system console you can try booting from a live DVD/USB. Mount up the real root partition and you may be able to fix it.
That suggestion was on the tip of my tongue; however my problem with that is that you really need to know the deep core problem at the file level and exactly how to fix it. Otherwise you can't just do an apt install, etc because the target system would then be the live one you're running, not the hard drive which has the problem. Another option might be to then try and rebuild and install from source. With gnome being so complicated, I'm not sure that would be too easy to accomplish when off of a live boot, same added problems that you might need to add a ton of things just to satisfy the dependencies.
I do think that J Martin's suggestion is great if you also happen to find a parallel thread here or in another forum which states something like "edit <this> file and change <that>" or "delete <this> file and reboot" something like that. There are a lot of things like that for gnome where it gets hosed up and then you can fix it if you hit the right "one tip" solution that works in your case.
That suggestion was on the tip of my tongue; however my problem with that is that you really need to know the deep core problem at the file level and exactly how to fix it. Otherwise you can't just do an apt install, etc because the target system would then be the live one you're running, not the hard drive which has the problem.
If you managed to mount the filesystem, couldn't you chroot into it? Then any package management would be applied to the damaged system?
Our diskless machines download a system image. That image is built from a directory structure and you can chroot into that. It's CentOs, so not quite the same, but I can use yum to install software with no problems. Therefore I'd image that chrooting onto a mounted sytem disk ought to be fine.
A couple of other suggestions:
1) During boot set the single user flag.
2) If you can mount the disk on a live distro, set the initdefault (the run level) in /etc/inittab to be 2 or 3. X11 won't start and you ought to have a simple command line console.
I know about chroot, I just don't know if that would work. I've only ever chroot'ed during the boot phase actually after like a file system was extracted. The idea makes sense though.
When you install Arch, that's how you do it. You mount your filesystem root to /mnt (and /home and stuff under there), there's a script that downloads the base system into it, then you chroot into it and can use pacman to install stuff like you normally would.
I tried logging in nothing and when I press ctl alt f2 I put starts it went blank screen how can I login now it keeps sayin what its has been saying in my first post
OK, when it boots up to the point to allow you to login to the desktop, DON'T try to login at that point, hit CTRL-ALT-F1, or F2, or F3, ... up to I think F7 or F8 (one of those higher ones returns you to the multi-user GUI form)
Try your FIRST login attempt at a system console which you attain by doing the CTRL-ALT-F sequence after it boots, but before you try to login at the UI based screen.