I tried using the LiveCD feature to remaster my existing Kwheezy 1.5. The drive had insufficient workspace for the process and it trashed the existing installation. However, that is not the subject of this bug report.
I got another drive with more space and used the original V1.5 LiveDVD (probably 4 months old), to do a fresh install. That was successful but it found over 300 updates. I installed the updates, rebooted and at the point that the log-in screen normally appears, I got this message:
Debian GNU/Linux 7 Kwheezy tty1
Kwheezy Login:
Fatal server error:
Could not create lock file in /tmp/.tXO-lock
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help
I repeated the entire process and got the same result. Without a fix, there is no way to recreate a working Kwheezy installation, and I suspect the same would apply to anyone else. BTW, there was nothing useful at the x.org link.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I just tried to reproduce by doing a fresh install in a VirtualBox VM. I used version 1.5 64bit. After installation, I rebooted and applied the updates. I then rebooted successfully into Kwheezy with allthe updates applied.
So, unless it's hardware related (possibly video drivers), I think it's something you're doing wrong.
Judging by your error message, it looks like you either have a permissions issue on your /tmp folder. Or you are out of space.
Firstly, did you reboot after installing and before you applied the updates?
Give me some more details about your installation. What is the size of the drives involved? What partitioning options did you choose in the installer?
I'm pretty confident it's nothing to do with Kwheezy, and it's I'm sure it's fixable your end. And I'm sure the solution will involve you learning something about Linux that you really need to. Give me more info and I will try to help.
If your attempt to use kwheezy-livecd failed due to lack of space, it will not hose your installation. That is the point you should have asked for help, not just here, but any Linux forum. You could have run "kwheezy-livecd clean" to delete the working files and regain space on your filesystem. I, and many others, could have told you how to move your installation to another drive without using kwheezy-livecd. Kwheezy-livecd is not designed to backup your files, only the installation. You probably just needed to make an exclusion for your data files (having backed up, so you can restore to the next installation). to mention a couple of options; (i) Clonezilla (ii) the dd command.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your response. I've been dealing with a cascade of problems. Let me try to shed more light.
It looks like I did the original Kwheezy install in June or July using the V1.5 available at that time. The files on the DVD are all dated 3/21/14. The installation went fine and I've been using it as my primary OS since. That installation started out as a trial run. I had an old 20 GB HDD from a defunct laptop that I installed it on. I went with the default partitioning, which created a swap partition and installed everything in the remaining space. I subsequently uninstalled a few things and ended up with roughly 4 or 5 GB of free space. It was enough for normal work, but not enough for anything big.
The computer is an off-the-shelf Gateway Windows 7 box coming up on 5 years old: quad-core processor, 8 GB RAM, ATI Radeon graphics (which was not a problem for the original install or the new one I tried). On the new installation, I selected the ATI open source driver, and it worked fine (I forget what I selected on the original install).
I tried several backup programs from the repository, but they excluded in-use files, making them pretty worthless for backup (and Clonezilla is not available there). I'll have to research using dd. I ended up booting into Mint (on another drive), and using Ark to save either everything from root or everything from home at varying frequencies. I wanted to create a mirror backup, which was how I ended up at Kwheezy-livecd (seemed like a solution at the time). I did exclude home in addition to the default exclusions. From the messages I got, it looked like it was trying to create a 7 GB temporary file and then compress an iso from that (which doesn't work with less than 5 GB of free space).
It locked the system. With all of the problems I've been trying to clean up, the details are a bit confused at this point. My recollection is that the process bombed after numerous error messages and it wrote a 1.5 GB iso. I believe I deleted that and maybe some of the temporary files, which freed up enough space to be operational, and then ran kwheezy-livecd clean. However, the system is not at the same point it was prior to this.
When I try to reboot, it gets through the password, then produces an error message: call to lnusertemp failed (temporary directories full?). Clicking OK on the message window takes it back to the password entry screen. To get operational, I tried moving my Thunderbird profile to Mint, but Thunderbird there can't use it. It could be an unrelated problem. If I can get back into the original Kwheezy installation, I can sort that out.
Which brings me to the original post, above. I have another old laptop HDD, a 40 GB, which I figured I would use to just reinstall Kwheezy with some breathing room. This is all on the same system and I started with the original Kwheezy DVD. It installed; I rebooted onto the new installation; got a message that there was something like 325 updates; installed them; rebooted; and got the error message in the original post. After seeing your response, I tried again using a newly downloaded DVD. My recollection was that the web site indicated the iso was from October (although all of the files match the previous DVD's 3/21/14 date.
I used the new DVD to install; rebooted into the new installation; changed a few preferences; rebooted; and got a message that there were 63 updates and 250 security updates. I installed all of them and then rebooted. It brought me to the same error message as in the original post.
The second hard drive is a working drive, twice the size of the first, so space shouldn't be driving the problem. I installed Kwheezy the same way and haven't customized any system-level stuff or changing default permissions. The virgin, default installation appeared to work properly until all of the updates were installed. Both drives are in external USB enclosures.
So that's where I am. I have a problem with both Kwheezy installations that prevents me from getting into either one. I'd welcome any insight you may have. Let me know if any additional information would be helpful.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, you seem to be having some bad luck because the things you've tried should have worked without any problem. I am still very confident that installing updates after a Kwheezy 1.5 installation should cause no problems. My best guess would be video driver because that is something VirtualBox can't test, and I don't have ATI cards on my machines to test it.
So you still have the original installation, good. Let's try get you up and running on your original installation, so you can get stuff done. First thing to try is cleaning up your /tmp folder. Login as root on tty2. You can do this by pressing Ctrl-Alt-F2, then login as "root" and you root password. Run the following command and send me the output:
df -h
I only need to know the Filesystem, Size and Available fields for each entry.
Then run these commands (be VERY careful and exact, these are powerful commands):
Performed the commands. That didn't fix the problem but it may provide some diagnostic information.
On the original installation, the df command produced:
filesystem
size
available
rootfs
17G
5.5G
udev
10M
10M
tmpfs
776M
775M
/dev/disk/by-uuid/...
17G
5.5G
tmpfs
5.0M
5.0M
tmpfs
1.9G
1.9G
/dev/sda3
824G
749G
/dev/sdb1
932G
462G
There was never any problem related to video on the original installation, but I switched it as requested (I assume to eliminate the variable).
After deleting the tmp directories and rebooting, the login failed again (lnusertemp message). I logged in as root and checked what tmp directories had been recreated. There were 25 (nested) entries.
I tried booting up the new installation and found a number of potentially interesting things.
1) Early in bootup the system performs a filesystem check. When I booted the original installation, it said there were no problems. However, when I booted the new installation, there was a message: /dev/sde1 contains a filesystem with errors. I believe sde1 is the original installation when I boot the new one. I have no idea why there should be a discrepancy, but if there is some kind of filesystem error, that might explain the problem on the original installation.
2) Although nothing has been changed on the new installation, the installation did not produce the error message noted in the original post. It went the system login prompt:
Debian GNU/Linux 7 Kwheezy tty1
Kwheezy Login:
but no message: Could not create lock file in /tmp/.tXO-lock
3) I logged into root and listed the /tmp directories. This should be the same as on the original. However, there were only four:
So 21 directories created at boot by the original installation are missing, including the .tX0-lock directory mentioned in the previous error message (and it wouldn't allow me to create one--read-only filesystem message).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Aha, we've nailed it! I suspected it may by filesystem errors, but i thought that would be a bit of a coincidence to happen right when you had a kwheezy-livecd failed run. Perhaps your drive has bad blocks and filling the drive caused the filesystem to use them.
Anyways, hopefully you just need a fsck (check and repair your filesystem). This is why it's good idea to keep your data on a seperate partition, hopefully your home folder is OK.
Login to tty2 again as root and run the following command:
shutdown -rF now
That should force a fsck on the reboot. Watch out for feedback when it boots up. I'm not sure if it does an automatic repair, but at least we'll get a step further.
You can also use the Live CD to do a fsck and repair, since the partitions will not be mounted while your Live CD/DVD is running in memory. Run the following command (as root):
fsck -a /dev/sda1
Replace and repeat for the correct partition (/dev/sda3, /dev/sde1 etc.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Promising but no cigar. When I ran fsck on the original installation, it came back clean, like the report at boot. So that's not the issue on that one.
I also ran it on the new installation and that one reported errors, which was suprising since the drive was repartitioned and reformatted prior to the install. I assumed that booting on that drive made it sda, but it looks like it was always sde, and it was reporting on itself. fsck cleaned up the errors but that didn't affect anything. That one still now boots to a system prompt before getting to the desktop manager.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Let's just clarify some things. How many PCs are involved. When you say the original, you mean the Gateway right? And the second/third installation was on a different machine? You have at least 2 drives, sda and sdb, but I don't know what drives or partitions are used for what yet.
I realize it's not easy to post output from a non-graphical session, but I need the output of a few commands (as root):
parted -l
cat /etc/fstab
blkid
mount
touch /tmp/testwrite
It's good news your filesystems are healthy, but did you fsck the home partition as well?
Describe what the different drives are for, expand the description to partitions if you can. Did you add any disks since the original problem (kwheezy-livecd failure).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is one PC. The original HDD contains Windows and Linux Mint. There are four external USB HDDs (none added since the second Kwheezy drive). From the parted output:
Drive | ID |Partition |
--------|----|------------------|----
Internal|sda1|primary ntfs diag |
|sda2|primary ntfs boot |
|sda3|primary ntfs |
|sda4|extended |
|sda5|logical ext2 |
|sda6|logical linux-swap|
Ext USB |sdb1|primary ntfs |
Ext USB |sdc1|pri fat32 boot,lba|
Ext USB |sdd1|primary ext4 boot |
|sdd2|primary linux-swap|
Ext USB |sde1|primary ext4 boot |
|sde2|primary linux-swap|
The table was too wide to fit. The last two columns are below:
ID
Size
Use
sda1
16G
Windows recovery
sda2
0.1G
boot
sda3
884G
Windows 7
sda4
100G
sda5
91G
Linux Mint
sda6
8G
"
sdb1
1T
Backup
sdc1
80G
general storage
sdd1
18G
Kwheezy original
sdd2
2G
"
sde1
36G
Kwheezy new
sde2
4G
"
I assumed this was the key information you were looking for. Let me know if you want the entire output.
Please clarify the cat command. I'm currently operating in Mint and it gives me the mint information, which doesn't come into play when I boot Kwheezy. Are you looking for this from one or both Kwheezy sessions?
blkid goes off and spends some time doing something and then returns to the prompt with no output.
Mount output (from Mint session):
/dev/sda5 on / type ext2 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
/dev/sdc1 on /media/administrator/WDC$USB2 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,flush,uhelper=udisks2)
/dev/sda3 on /media/administrator/Gateway type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096)
/dev/sdb1 on /media/administrator/HD-CEIU2 type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096)
/dev/sdd1 on /media/administrator/38e3d668-7fd6-4b3a-8e1c-533914a159ff type ext4 (rw,nosuid,nodev,uhelper=udisks2)
/dev/sde1 on /media/administrator/f51525e4-1113-48af-9837-e447e108202a type ext4 (rw,nosuid,nodev,uhelper=udisks2)
Let me know if you're looking for this to be run from one or both Kwheezy sessions.
Touch will work with Mint, where I'm currently working. I assume this should be run on one or both Kwheezy boots after logging into root, instead?
re: fsck and home directories, The two drives with Kwheezy are too small to partition without risking running out of space on one of the partitions. Home is on the same partition as root.
Last edit: fixer1234 2015-01-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I really need the output to all the commands, and they must be run from within the original Kwheezy installation. In other words, you need to boot into the orignal Kwheezy installation, the one you can't get graphical login working. I beleive you are able to use tty2 (Ctrl-Alt-F2) to login. What you can do is try to add another user in order to get graphical login, so you can post the output easier.
Once you have booted into Kwheezy (orig) and logged into the tty2 as root, you can use 'adduser' command to add another user. Then try to graphical login as that user, 'su' to root, run the commands in my last post, copy and paste the output to a text file (out.txt) and attach it to your next post using "Add Attachments".
I simply can't help any further without the full output from all those commands from WITHIN the original Kwheezy installation itself.
Ultimatly, your problems stem from the fact that you have too complex a configuration. You're triple booting on several drives, and some are USB drives. What I do when I have multi OSes on my Desktop PC is to use a dedicated drive for each OS/distro. I install a bootloader to each of those drives, and I use the BIOS to switch which drive gets booted, instead of using GRUB. This makes things much less fragile when factors change. I wouldn't even attempt to do this on a laptop/notebook. Bottom line is, multi-boot with different OS types is tricky and can require an understanding of what's going on under the hood. In other words, you need to know what you're doing. Having said that, we all have to learn these things through trial and error.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK. That wasn't clear, although after looking up what some of the commands do, I suspected it might be the case that I needed to run them from Kwheezy. I'll give that try and get back to you.
A question on the GRUB problem, though. Grub just points the system to a boot procedure, and that is working on all four OSs. My understanding is that once a selected boot starts, GRUB is irrelevant. Also, the original Kwheezy was set up as a third OS, and worked fine until the Kwheezy-liveCD debacle. It is unaware of the new Kwheezy installation. If you think making the new Kwheezy a fourth OS might be related to its problem, is there a way to modify its boot (or is it likely to work if I just reinstall it as a third or only OS)?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Semi-good news. I created a new user and was able to boot into that to a normal desktop. It appears that the problem with the original installation is associated with the original user. I was able to use su to switch users in a terminal session and saw that my stuff is still there. I'll try booting into the original account again after posting this to see if the problem is magically fixed and will report back.
Update: The original user is still hosed (lnusertemp error; returns to the login screen). The new user works. If there is not a simple way to diagnose what got corrupted, is there a way to clone everything in the original user setup and apply it to the new user, reassign the home directory, etc.?
I ran the commands and have attached the output, including some additional explanation. The touch command didn't produce terminal output, but it did create a zero byte file with the current time. I attached a screenshot of the /tmp directory.
An update on the new Kwheezy installation. I disconnected all drives except the internal HD and the 40 GB USB drive being used for the new Kwheezy installation. I tried various things reinstalling Kwheezy many times and noticed that when installing the updates, each time it would get to 67% and suddenly say it was done. I reinstalled Kwheezy and did the updates a small batch at a time, rebooting after each batch, to locate what might be going on. I saved 7 updates for last, dealing with the kernel and Xserver, figuring those were the most likely candidates. (The sudden update completion turned out to be irrelevant.)
As the next-to-last update, I did the kernel updates, and those are what breaks it. On rebooting after those, the system goes to a system prompt instead of the password screen. A screen shot of the last set of updates is attached. The four checked ones are the ones installed prior to producing the error.
Update: I tried this exercise again, reinstalling Kwheezy and then doing all of the updates except the four kernel-related ones, and then rebooting. That all worked normally, and GRUB contained the Mint and Windows options as well as the Kwheezy options. Then I installed linux-libc-dev, which looked like it might be loadable on its own, and rebooted. GRUB then contained only the Kwheezy options, but it loaded normally.
The three remaining kernel and header files looked like they needed to be loaded together, so I installed them and rebooted. It then went to a system prompt with the "Could not create lock file in /tmp/.tXO-lock" error message reported in the first post.
OK, lets fix one thing at a time. Let's stick to the original install for now.
I haven't looked at the out.txt you posted. Ironically, the adding of the user sucessfully tells me what i need to know. It's something in your home folder (user profile). As root, in terminal, cd (change directory) to your home folder of the user that can't login. Then run these commands and give me output:
ls -la
ls -la .kde
After the second and last command, you will see some links to /tmp/* files, they start with cache- socket- tmp- . These are temp files that can be deleted. As root delete the links (inside .kde directory) and what they point to (inside /tmp directory). Don't delete the .kde or /tmp directories themselves. Then try again to login.
Also, su to the borked user and try to touch a file in the home folder with following command:
touch ~/testfile
rm ~/testfile
This tests if you can write to the home folder.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmmm, I really begs the question what happened. I can't see how kwheezy-livecd could have borked your home folder so badly. The ownership of the files are wrong too, they are all owned by root, instead of administrator.
If you wan to keep your original installation, you will best create a new user (named after yourself). But there is not much point in doing so. I recommend blowing away all the kwheezy installations and trying again. Backup your data first (just copy to another drive). Then re-install kwheezy, perhaps give it the whole drive.
Hopefully yur update after install issue will just go away. I can vouch that there is not a generic problem with installing Kwheezy 1.5 and updates breaking something.
Give it a try and we can go from there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After extensive testing, I determined that the problem with the new Kwheezy installation was a bad interface in the USB enclosure. The drive tested as fine, but a number of different distros had trouble re-partitioning it or formatting it. I removed the drive, connected it to an IDE/USB adapter, and loaded two of the previous problem distros, both successfully (one replacing the other).
So I took your advice and started over with Kwheezy. Rather than use that 40 GB drive, I used the 80 GB USB drive, dedicated entirely to Kwheezy. This is a commercial external drive (not a cheap enclosure plus a bare drive), which was formatted vfat. I have been actively using it and know that it is good. Kwheezy repartitioned and reformatted it, and installed on it fine. There were 320 updates, which I installed. Upon rebooting, I am back at the point of my original post. The updated Linux kernal trashed the installation, the same as described in my previous post, above. It boots to a system prompt and the same /tmp/.tX0-lock error message. So, it looks like there is some kind of problem or incompatibility with the new kernel (possibly with the interface of old USB drives?).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, but how come my own installation (form which I am posting fomr) is OK after continual updates since 1.5 was realeased. I am up to date currently.
From now on, let's work on this new installation. I assume you have blown away all previous installations and only have a Win7 and Mint instaalation on same machine?
Can you login to this new Kwheezy instalation via tty2. If so, enter the commands and post output:
The issue appears to be hardware-specific (older USB hard drive interfaces), and is not limited to Debian. So I guess we should just focus on getting it working and deal with any future update issues when and if they happen.
This round was a challenge. I re-did everything from scratch, including returning the drive to its original state as a starting point. The initial install went fine. I did the initial settings and rebooted. Then I installed only the four kernel-related updates. On rebooting, the system was totally hosed.
I couldn't add a user. Message: groupadd: cannot lock /etc/group; try again later. Adduser `/usr/sbin/groupadd -g 1000 tempuser' returned error code 10. Exiting
Everything on the system (root and home partitions), came back as read-only file system, so there was no way to save output to the drive (including the touch command). I also could not access any other drive on the system. The only way to get you the output was to photograph the screen.
The attached archive contains:
1 png with the parted and fstab results
1 png with the blkid and mount results
11 pngs with the Xorg.0.log results, one screen at a time
Well done, I know that's a tedious way to gather output!
I'm just reading through the output now. I thought to speed things up you could point me to a link regarding this known issue ewith older USB hard drive interfaces.
I suspected your use of external USB drives may be related to your problem, based on it's introducing complexity. It's not so common to boot an OS from USB drive, usually they are just for data. In fact I doubt Windows can install to a USB drive at all.
One easy solution, assuming your Gateway is a desktop PC, would be to add another internal drive and install to that. You could take the one from your enclosure, since it's designed to be removed. Or youy can break open your other USB drive enclosure. The drives are exactly the same regular internal drives, SATA is SATA.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
(i) re-install over the top of last instaalation, this time use GPT partitioning. Whilst the bug probably does not relate to msdos partitioning, GPT may just coincidentally avoid the error.
(ii) don't update the kernel. Debian stable does not actually update the kernel version, versions are fixed per stable release. So the kernel update was probably just a security fix. So, whilst it's best to apply security fixes, there's good chance the security patch doesn't even apply to you. It may only effect servers or other hardware. Also, even without security patches, you'll be 1000x more secure than on Windows. That's a decision you'll have to make, but it will solve your problem. If you want to do this, follow commands (as root, before you do any updates):
apt-mark hold linux-image-amd64
apt-mark hold linux-image-3.2.0-4-amd64
apt-mark hold linux-headers-3.2.0-4-common
apt-mark hold linux-headers-3.2.0-4-amd64
apt-mark hold firmware-linux-free
apt-mark hold firmware-linux-nonfree
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding ii, above, I assume "apt-mark hold" locks the files so they don't get updated. That would prevent any future updates, also. Whatever the USB interface problem is, in testing, it has manifested itself in several different types of odd software failures across certain Linux distros. Without figuring out the underlying problem, I'll be waiting for the other shoe to drop with some future update, perhaps failing in some other way. I think the key is to use a known-compatible usb interface or install internally, as you suggested.
Last edit: fixer1234 2015-01-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, "apt-mark hold" locks the packages, so they don't get updated. This means you can aplly the updates without having to unselect the kernel ones that bork your system. They can easily be un-held with "apt-mark unhold ...".
Yes, install internally would be my recommended course of action. Installing to USB drive is fine for testing, but not good for a daily driver. Unless you use USB 3.0, you will be slowing HDD access down noticably.I doubt your Gateway has USB 3.0. However you can safely hold back the kernel, they are only security fixes, so compatability will never be broken. Also, the kernel is independent from userland. In the famous words from Linus (our benovelent dictator), the one rule for a Linux kernel developer is "You never ever break user space". Which means the kernel never breaks the OS and apps above it. Of course, hardware related issues can make this rule have exceptions. But you get the point.
Anyway, please let me know what you decide. I've spent some time helping. I will not at all be offended if you drop Kwheezy, it's getting old now. I'm just deciding what direction (if any) to take about a follow up distro.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What makes the most sense is to install Kwheezy on an internal drive. I appreciate your support on this problem.
Kwheezy is really a work of art. It would be a shame to drop it. It is a near perfect Windows replacement, better for Windows immigrants than the standard recommendations of Mint or Ubuntu. The biggest problem for Windows immigrants is trying to learn a bunch of new stuff all at once when what you are trying to learn doesn't work. I started with Mint but was constantly running into things from its Ubuntu origins that didn't work.
I looked at Debian Wheezy, but it wasn't newbie friendly. Kwheezy worked out of the box with everything needed--drivers, software, configuration, etc., all ready to go. Other than this debacle from installing it originally on too small a USB drive, there wasn't any significant issue with it or with anything bundled with it. The only time I needed to go outside was to get a current version of Firefox from the LMDE repository.
You did a phenomenal job of putting the package together. Amazing attention to detail. The only thing I would change is adding the ability to disable the annoying KDE bouncing icon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried using the LiveCD feature to remaster my existing Kwheezy 1.5. The drive had insufficient workspace for the process and it trashed the existing installation. However, that is not the subject of this bug report.
I got another drive with more space and used the original V1.5 LiveDVD (probably 4 months old), to do a fresh install. That was successful but it found over 300 updates. I installed the updates, rebooted and at the point that the log-in screen normally appears, I got this message:
Debian GNU/Linux 7 Kwheezy tty1
Kwheezy Login:
Fatal server error:
Could not create lock file in /tmp/.tXO-lock
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help
I repeated the entire process and got the same result. Without a fix, there is no way to recreate a working Kwheezy installation, and I suspect the same would apply to anyone else. BTW, there was nothing useful at the x.org link.
OK, I just tried to reproduce by doing a fresh install in a VirtualBox VM. I used version 1.5 64bit. After installation, I rebooted and applied the updates. I then rebooted successfully into Kwheezy with allthe updates applied.
So, unless it's hardware related (possibly video drivers), I think it's something you're doing wrong.
Judging by your error message, it looks like you either have a permissions issue on your /tmp folder. Or you are out of space.
Firstly, did you reboot after installing and before you applied the updates?
Give me some more details about your installation. What is the size of the drives involved? What partitioning options did you choose in the installer?
I'm pretty confident it's nothing to do with Kwheezy, and it's I'm sure it's fixable your end. And I'm sure the solution will involve you learning something about Linux that you really need to. Give me more info and I will try to help.
If your attempt to use kwheezy-livecd failed due to lack of space, it will not hose your installation. That is the point you should have asked for help, not just here, but any Linux forum. You could have run "kwheezy-livecd clean" to delete the working files and regain space on your filesystem. I, and many others, could have told you how to move your installation to another drive without using kwheezy-livecd. Kwheezy-livecd is not designed to backup your files, only the installation. You probably just needed to make an exclusion for your data files (having backed up, so you can restore to the next installation). to mention a couple of options; (i) Clonezilla (ii) the dd command.
Thanks for your response. I've been dealing with a cascade of problems. Let me try to shed more light.
It looks like I did the original Kwheezy install in June or July using the V1.5 available at that time. The files on the DVD are all dated 3/21/14. The installation went fine and I've been using it as my primary OS since. That installation started out as a trial run. I had an old 20 GB HDD from a defunct laptop that I installed it on. I went with the default partitioning, which created a swap partition and installed everything in the remaining space. I subsequently uninstalled a few things and ended up with roughly 4 or 5 GB of free space. It was enough for normal work, but not enough for anything big.
The computer is an off-the-shelf Gateway Windows 7 box coming up on 5 years old: quad-core processor, 8 GB RAM, ATI Radeon graphics (which was not a problem for the original install or the new one I tried). On the new installation, I selected the ATI open source driver, and it worked fine (I forget what I selected on the original install).
I tried several backup programs from the repository, but they excluded in-use files, making them pretty worthless for backup (and Clonezilla is not available there). I'll have to research using dd. I ended up booting into Mint (on another drive), and using Ark to save either everything from root or everything from home at varying frequencies. I wanted to create a mirror backup, which was how I ended up at Kwheezy-livecd (seemed like a solution at the time). I did exclude home in addition to the default exclusions. From the messages I got, it looked like it was trying to create a 7 GB temporary file and then compress an iso from that (which doesn't work with less than 5 GB of free space).
It locked the system. With all of the problems I've been trying to clean up, the details are a bit confused at this point. My recollection is that the process bombed after numerous error messages and it wrote a 1.5 GB iso. I believe I deleted that and maybe some of the temporary files, which freed up enough space to be operational, and then ran kwheezy-livecd clean. However, the system is not at the same point it was prior to this.
When I try to reboot, it gets through the password, then produces an error message: call to lnusertemp failed (temporary directories full?). Clicking OK on the message window takes it back to the password entry screen. To get operational, I tried moving my Thunderbird profile to Mint, but Thunderbird there can't use it. It could be an unrelated problem. If I can get back into the original Kwheezy installation, I can sort that out.
Which brings me to the original post, above. I have another old laptop HDD, a 40 GB, which I figured I would use to just reinstall Kwheezy with some breathing room. This is all on the same system and I started with the original Kwheezy DVD. It installed; I rebooted onto the new installation; got a message that there was something like 325 updates; installed them; rebooted; and got the error message in the original post. After seeing your response, I tried again using a newly downloaded DVD. My recollection was that the web site indicated the iso was from October (although all of the files match the previous DVD's 3/21/14 date.
I used the new DVD to install; rebooted into the new installation; changed a few preferences; rebooted; and got a message that there were 63 updates and 250 security updates. I installed all of them and then rebooted. It brought me to the same error message as in the original post.
The second hard drive is a working drive, twice the size of the first, so space shouldn't be driving the problem. I installed Kwheezy the same way and haven't customized any system-level stuff or changing default permissions. The virgin, default installation appeared to work properly until all of the updates were installed. Both drives are in external USB enclosures.
So that's where I am. I have a problem with both Kwheezy installations that prevents me from getting into either one. I'd welcome any insight you may have. Let me know if any additional information would be helpful.
OK, you seem to be having some bad luck because the things you've tried should have worked without any problem. I am still very confident that installing updates after a Kwheezy 1.5 installation should cause no problems. My best guess would be video driver because that is something VirtualBox can't test, and I don't have ATI cards on my machines to test it.
So you still have the original installation, good. Let's try get you up and running on your original installation, so you can get stuff done. First thing to try is cleaning up your /tmp folder. Login as root on tty2. You can do this by pressing Ctrl-Alt-F2, then login as "root" and you root password. Run the following command and send me the output:
I only need to know the Filesystem, Size and Available fields for each entry.
Then run these commands (be VERY careful and exact, these are powerful commands):
Then reboot and see if it's fixed.
Next thing to try is changing your video driver. Again from the console:
This will show you the list of available drivers. Let's use opensource to start with, it's the default on the Live CD also:
Then reboot and test again.
That will do to start with, we'll go from there.
NOTE: to reboot from console (need root privileges) use the 'reboot' command. If running as administrator use 'sudo reboot'.
Performed the commands. That didn't fix the problem but it may provide some diagnostic information.
On the original installation, the df command produced:
There was never any problem related to video on the original installation, but I switched it as requested (I assume to eliminate the variable).
After deleting the tmp directories and rebooting, the login failed again (lnusertemp message). I logged in as root and checked what tmp directories had been recreated. There were 25 (nested) entries.
I tried booting up the new installation and found a number of potentially interesting things.
1) Early in bootup the system performs a filesystem check. When I booted the original installation, it said there were no problems. However, when I booted the new installation, there was a message: /dev/sde1 contains a filesystem with errors. I believe sde1 is the original installation when I boot the new one. I have no idea why there should be a discrepancy, but if there is some kind of filesystem error, that might explain the problem on the original installation.
2) Although nothing has been changed on the new installation, the installation did not produce the error message noted in the original post. It went the system login prompt:
Debian GNU/Linux 7 Kwheezy tty1
Kwheezy Login:
but no message: Could not create lock file in /tmp/.tXO-lock
3) I logged into root and listed the /tmp directories. This should be the same as on the original. However, there were only four:
/tmp
/tmp/.ICE-unix
/tmp/pulse-PKdhtXMmt18n
/tmp/.X11-unix
So 21 directories created at boot by the original installation are missing, including the .tX0-lock directory mentioned in the previous error message (and it wouldn't allow me to create one--read-only filesystem message).
Aha, we've nailed it! I suspected it may by filesystem errors, but i thought that would be a bit of a coincidence to happen right when you had a kwheezy-livecd failed run. Perhaps your drive has bad blocks and filling the drive caused the filesystem to use them.
Anyways, hopefully you just need a fsck (check and repair your filesystem). This is why it's good idea to keep your data on a seperate partition, hopefully your home folder is OK.
Login to tty2 again as root and run the following command:
That should force a fsck on the reboot. Watch out for feedback when it boots up. I'm not sure if it does an automatic repair, but at least we'll get a step further.
You can also use the Live CD to do a fsck and repair, since the partitions will not be mounted while your Live CD/DVD is running in memory. Run the following command (as root):
Replace and repeat for the correct partition (/dev/sda3, /dev/sde1 etc.)
Promising but no cigar. When I ran fsck on the original installation, it came back clean, like the report at boot. So that's not the issue on that one.
I also ran it on the new installation and that one reported errors, which was suprising since the drive was repartitioned and reformatted prior to the install. I assumed that booting on that drive made it sda, but it looks like it was always sde, and it was reporting on itself. fsck cleaned up the errors but that didn't affect anything. That one still now boots to a system prompt before getting to the desktop manager.
Let's just clarify some things. How many PCs are involved. When you say the original, you mean the Gateway right? And the second/third installation was on a different machine? You have at least 2 drives, sda and sdb, but I don't know what drives or partitions are used for what yet.
I realize it's not easy to post output from a non-graphical session, but I need the output of a few commands (as root):
It's good news your filesystems are healthy, but did you fsck the home partition as well?
Describe what the different drives are for, expand the description to partitions if you can. Did you add any disks since the original problem (kwheezy-livecd failure).
There is one PC. The original HDD contains Windows and Linux Mint. There are four external USB HDDs (none added since the second Kwheezy drive). From the parted output:
Drive | ID |Partition |
--------|----|------------------|----
Internal|sda1|primary ntfs diag |
|sda2|primary ntfs boot |
|sda3|primary ntfs |
|sda4|extended |
|sda5|logical ext2 |
|sda6|logical linux-swap|
Ext USB |sdb1|primary ntfs |
Ext USB |sdc1|pri fat32 boot,lba|
Ext USB |sdd1|primary ext4 boot |
|sdd2|primary linux-swap|
Ext USB |sde1|primary ext4 boot |
|sde2|primary linux-swap|
The table was too wide to fit. The last two columns are below:
I assumed this was the key information you were looking for. Let me know if you want the entire output.
Please clarify the cat command. I'm currently operating in Mint and it gives me the mint information, which doesn't come into play when I boot Kwheezy. Are you looking for this from one or both Kwheezy sessions?
blkid goes off and spends some time doing something and then returns to the prompt with no output.
Mount output (from Mint session):
/dev/sda5 on / type ext2 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
/dev/sdc1 on /media/administrator/WDC$USB2 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,flush,uhelper=udisks2)
/dev/sda3 on /media/administrator/Gateway type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096)
/dev/sdb1 on /media/administrator/HD-CEIU2 type fuseblk (rw,nosuid,nodev,allow_other,default_permissions,blksize=4096)
/dev/sdd1 on /media/administrator/38e3d668-7fd6-4b3a-8e1c-533914a159ff type ext4 (rw,nosuid,nodev,uhelper=udisks2)
/dev/sde1 on /media/administrator/f51525e4-1113-48af-9837-e447e108202a type ext4 (rw,nosuid,nodev,uhelper=udisks2)
Let me know if you're looking for this to be run from one or both Kwheezy sessions.
Touch will work with Mint, where I'm currently working. I assume this should be run on one or both Kwheezy boots after logging into root, instead?
re: fsck and home directories, The two drives with Kwheezy are too small to partition without risking running out of space on one of the partitions. Home is on the same partition as root.
Last edit: fixer1234 2015-01-12
I really need the output to all the commands, and they must be run from within the original Kwheezy installation. In other words, you need to boot into the orignal Kwheezy installation, the one you can't get graphical login working. I beleive you are able to use tty2 (Ctrl-Alt-F2) to login. What you can do is try to add another user in order to get graphical login, so you can post the output easier.
Once you have booted into Kwheezy (orig) and logged into the tty2 as root, you can use 'adduser' command to add another user. Then try to graphical login as that user, 'su' to root, run the commands in my last post, copy and paste the output to a text file (out.txt) and attach it to your next post using "Add Attachments".
I simply can't help any further without the full output from all those commands from WITHIN the original Kwheezy installation itself.
Ultimatly, your problems stem from the fact that you have too complex a configuration. You're triple booting on several drives, and some are USB drives. What I do when I have multi OSes on my Desktop PC is to use a dedicated drive for each OS/distro. I install a bootloader to each of those drives, and I use the BIOS to switch which drive gets booted, instead of using GRUB. This makes things much less fragile when factors change. I wouldn't even attempt to do this on a laptop/notebook. Bottom line is, multi-boot with different OS types is tricky and can require an understanding of what's going on under the hood. In other words, you need to know what you're doing. Having said that, we all have to learn these things through trial and error.
OK. That wasn't clear, although after looking up what some of the commands do, I suspected it might be the case that I needed to run them from Kwheezy. I'll give that try and get back to you.
A question on the GRUB problem, though. Grub just points the system to a boot procedure, and that is working on all four OSs. My understanding is that once a selected boot starts, GRUB is irrelevant. Also, the original Kwheezy was set up as a third OS, and worked fine until the Kwheezy-liveCD debacle. It is unaware of the new Kwheezy installation. If you think making the new Kwheezy a fourth OS might be related to its problem, is there a way to modify its boot (or is it likely to work if I just reinstall it as a third or only OS)?
Semi-good news. I created a new user and was able to boot into that to a normal desktop. It appears that the problem with the original installation is associated with the original user. I was able to use su to switch users in a terminal session and saw that my stuff is still there. I'll try booting into the original account again after posting this to see if the problem is magically fixed and will report back.
Update: The original user is still hosed (lnusertemp error; returns to the login screen). The new user works. If there is not a simple way to diagnose what got corrupted, is there a way to clone everything in the original user setup and apply it to the new user, reassign the home directory, etc.?
I ran the commands and have attached the output, including some additional explanation. The touch command didn't produce terminal output, but it did create a zero byte file with the current time. I attached a screenshot of the /tmp directory.
Last edit: fixer1234 2015-01-12
An update on the new Kwheezy installation. I disconnected all drives except the internal HD and the 40 GB USB drive being used for the new Kwheezy installation. I tried various things reinstalling Kwheezy many times and noticed that when installing the updates, each time it would get to 67% and suddenly say it was done. I reinstalled Kwheezy and did the updates a small batch at a time, rebooting after each batch, to locate what might be going on. I saved 7 updates for last, dealing with the kernel and Xserver, figuring those were the most likely candidates. (The sudden update completion turned out to be irrelevant.)
As the next-to-last update, I did the kernel updates, and those are what breaks it. On rebooting after those, the system goes to a system prompt instead of the password screen. A screen shot of the last set of updates is attached. The four checked ones are the ones installed prior to producing the error.
Update: I tried this exercise again, reinstalling Kwheezy and then doing all of the updates except the four kernel-related ones, and then rebooting. That all worked normally, and GRUB contained the Mint and Windows options as well as the Kwheezy options. Then I installed linux-libc-dev, which looked like it might be loadable on its own, and rebooted. GRUB then contained only the Kwheezy options, but it loaded normally.
The three remaining kernel and header files looked like they needed to be loaded together, so I installed them and rebooted. It then went to a system prompt with the "Could not create lock file in /tmp/.tXO-lock" error message reported in the first post.
Last edit: fixer1234 2015-01-13
OK, lets fix one thing at a time. Let's stick to the original install for now.
I haven't looked at the out.txt you posted. Ironically, the adding of the user sucessfully tells me what i need to know. It's something in your home folder (user profile). As root, in terminal, cd (change directory) to your home folder of the user that can't login. Then run these commands and give me output:
After the second and last command, you will see some links to /tmp/* files, they start with cache- socket- tmp- . These are temp files that can be deleted. As root delete the links (inside .kde directory) and what they point to (inside /tmp directory). Don't delete the .kde or /tmp directories themselves. Then try again to login.
Also, su to the borked user and try to touch a file in the home folder with following command:
This tests if you can write to the home folder.
Done. See attachment. There is a lot of missing stuff in the borked user directory.
Hmmm, I really begs the question what happened. I can't see how kwheezy-livecd could have borked your home folder so badly. The ownership of the files are wrong too, they are all owned by root, instead of administrator.
If you wan to keep your original installation, you will best create a new user (named after yourself). But there is not much point in doing so. I recommend blowing away all the kwheezy installations and trying again. Backup your data first (just copy to another drive). Then re-install kwheezy, perhaps give it the whole drive.
Hopefully yur update after install issue will just go away. I can vouch that there is not a generic problem with installing Kwheezy 1.5 and updates breaking something.
Give it a try and we can go from there.
After extensive testing, I determined that the problem with the new Kwheezy installation was a bad interface in the USB enclosure. The drive tested as fine, but a number of different distros had trouble re-partitioning it or formatting it. I removed the drive, connected it to an IDE/USB adapter, and loaded two of the previous problem distros, both successfully (one replacing the other).
So I took your advice and started over with Kwheezy. Rather than use that 40 GB drive, I used the 80 GB USB drive, dedicated entirely to Kwheezy. This is a commercial external drive (not a cheap enclosure plus a bare drive), which was formatted vfat. I have been actively using it and know that it is good. Kwheezy repartitioned and reformatted it, and installed on it fine. There were 320 updates, which I installed. Upon rebooting, I am back at the point of my original post. The updated Linux kernal trashed the installation, the same as described in my previous post, above. It boots to a system prompt and the same /tmp/.tX0-lock error message. So, it looks like there is some kind of problem or incompatibility with the new kernel (possibly with the interface of old USB drives?).
OK, but how come my own installation (form which I am posting fomr) is OK after continual updates since 1.5 was realeased. I am up to date currently.
From now on, let's work on this new installation. I assume you have blown away all previous installations and only have a Win7 and Mint instaalation on same machine?
Can you login to this new Kwheezy instalation via tty2. If so, enter the commands and post output:
The issue appears to be hardware-specific (older USB hard drive interfaces), and is not limited to Debian. So I guess we should just focus on getting it working and deal with any future update issues when and if they happen.
This round was a challenge. I re-did everything from scratch, including returning the drive to its original state as a starting point. The initial install went fine. I did the initial settings and rebooted. Then I installed only the four kernel-related updates. On rebooting, the system was totally hosed.
I couldn't add a user. Message: groupadd: cannot lock /etc/group; try again later. Adduser `/usr/sbin/groupadd -g 1000 tempuser' returned error code 10. Exiting
Everything on the system (root and home partitions), came back as read-only file system, so there was no way to save output to the drive (including the touch command). I also could not access any other drive on the system. The only way to get you the output was to photograph the screen.
The attached archive contains:
1 png with the parted and fstab results
1 png with the blkid and mount results
11 pngs with the Xorg.0.log results, one screen at a time
sdb is the 80 GB drive with Kwheezy.
Well done, I know that's a tedious way to gather output!
I'm just reading through the output now. I thought to speed things up you could point me to a link regarding this known issue ewith older USB hard drive interfaces.
I suspected your use of external USB drives may be related to your problem, based on it's introducing complexity. It's not so common to boot an OS from USB drive, usually they are just for data. In fact I doubt Windows can install to a USB drive at all.
One easy solution, assuming your Gateway is a desktop PC, would be to add another internal drive and install to that. You could take the one from your enclosure, since it's designed to be removed. Or youy can break open your other USB drive enclosure. The drives are exactly the same regular internal drives, SATA is SATA.
A couple more things to try:
(i) re-install over the top of last instaalation, this time use GPT partitioning. Whilst the bug probably does not relate to msdos partitioning, GPT may just coincidentally avoid the error.
(ii) don't update the kernel. Debian stable does not actually update the kernel version, versions are fixed per stable release. So the kernel update was probably just a security fix. So, whilst it's best to apply security fixes, there's good chance the security patch doesn't even apply to you. It may only effect servers or other hardware. Also, even without security patches, you'll be 1000x more secure than on Windows. That's a decision you'll have to make, but it will solve your problem. If you want to do this, follow commands (as root, before you do any updates):
The "known" issue with the USB interfaces is just my own testing. I posted a question about it on Super User: http://superuser.com/questions/865757/apparent-linux-incompatibility-with-some-usb-hard-drive-interfaces. I can give you more details if it would be useful.
Regarding ii, above, I assume "apt-mark hold" locks the files so they don't get updated. That would prevent any future updates, also. Whatever the USB interface problem is, in testing, it has manifested itself in several different types of odd software failures across certain Linux distros. Without figuring out the underlying problem, I'll be waiting for the other shoe to drop with some future update, perhaps failing in some other way. I think the key is to use a known-compatible usb interface or install internally, as you suggested.
Last edit: fixer1234 2015-01-16
Yes, "apt-mark hold" locks the packages, so they don't get updated. This means you can aplly the updates without having to unselect the kernel ones that bork your system. They can easily be un-held with "apt-mark unhold ...".
Yes, install internally would be my recommended course of action. Installing to USB drive is fine for testing, but not good for a daily driver. Unless you use USB 3.0, you will be slowing HDD access down noticably.I doubt your Gateway has USB 3.0. However you can safely hold back the kernel, they are only security fixes, so compatability will never be broken. Also, the kernel is independent from userland. In the famous words from Linus (our benovelent dictator), the one rule for a Linux kernel developer is "You never ever break user space". Which means the kernel never breaks the OS and apps above it. Of course, hardware related issues can make this rule have exceptions. But you get the point.
Anyway, please let me know what you decide. I've spent some time helping. I will not at all be offended if you drop Kwheezy, it's getting old now. I'm just deciding what direction (if any) to take about a follow up distro.
What makes the most sense is to install Kwheezy on an internal drive. I appreciate your support on this problem.
Kwheezy is really a work of art. It would be a shame to drop it. It is a near perfect Windows replacement, better for Windows immigrants than the standard recommendations of Mint or Ubuntu. The biggest problem for Windows immigrants is trying to learn a bunch of new stuff all at once when what you are trying to learn doesn't work. I started with Mint but was constantly running into things from its Ubuntu origins that didn't work.
I looked at Debian Wheezy, but it wasn't newbie friendly. Kwheezy worked out of the box with everything needed--drivers, software, configuration, etc., all ready to go. Other than this debacle from installing it originally on too small a USB drive, there wasn't any significant issue with it or with anything bundled with it. The only time I needed to go outside was to get a current version of Firefox from the LMDE repository.
You did a phenomenal job of putting the package together. Amazing attention to detail. The only thing I would change is adding the ability to disable the annoying KDE bouncing icon.