I got a bad one today with Debian which took me an extra hour (at least) to find out.

It can happen to you and that's why I'm writing this page:

X11 starts and quits right away without any error — I had some errors about the system not being able to load some modules, I removed them by fixing my XFree86 configuration file. Really, there was no errors.

Ha! But there was ONE error. 

startx, once X itself started, calls the session manager (such as "/etc/X11/Xsession" under Debian), and the session manager can screw up. If that happens, X doesn't hold since the session terminates. The problem is that it looks like X is happy because the session doesn't emit the errors in your console. Instead, it goes in your ~/.xsession-errors (at least under Debian). So what you have to do is look in that file and you should be able to figure it out.

In my case, if you want to know, I just switch between a 170Gb to a 250Gb hard drive and I copied all the partitions except /tmp and the swap (obviously). This worked like a charm with dump + restore, as long as your /var is not too large and fits in a file (otherwise you get a broken pipe, the restore seems to stop before dump is done... maybe because on that day I didn't move the temporary files to /tmp and by default dump+restore use files under /var)

So I copied the partitions with:

	cd /mnt/p5/
	dump -0 -f - /home | restore -r -f -

I suppose you created a partition on your destination drive and mounted it (after you formatted it) as /mnt/p5. You MUST cd into it for the restore -r to work properly. WATCH OUT! You could overwrite all your files otherwise!!! The dump specifies the source partition which is currently mounted on /home. The -f - means send to standard output (dump) and read from standard input (restore).

So that worked well except for the /var partition. I'd bet that's because dump has some temporary files in there (that it keeps between dumps to know what to do). So I had to direct the dump to an actual file. This was fine since my /var was only half a giga bytes (you're limited to 2Gb on most Linux distros).

	dump -0 -f /some/place/var.dump /var
	cd /mnt/p7
	restore -r -f /some/place/var.dump

And somehow we do not get the error. It looks like some people get that error yet all the files are copied. It wasn't the case for me. At this time I have no idea how you could do if your /var partition is larger than 2Gb except maybe by using a remote device.

Not too long ago, I tried again using -D /tmp on the command line of the dump. This solved the problem of dumping the /var directory.

I hope this was somewhat helpful...

Now I may have another solution which is to use rsync. However, so far the driver I rsync-ed does not work so... let's wait a bit on that one, okay?