Well, for me it just does that once during the install, and never after that. It's been always more of an annoyance than a problem for me.
So, I don't know how to fix it, sorry.
As for my lost /home. Well, truth is stranger than fiction. /home is indeed safe, and just as I had left it. Which is good. But it makes what happened way more mysterious, although lot less dangerous;
I was ready to empty the partitions again for bootstrap install of Ubuntu
(have to do it that way, the installer won't work very well with dmraid). Then I noticed something rather important; my /home is on /dev/mapper/pdc_bcbeecdaj9. All this time the error message had been telling me that it can't mount /home, because /dev/mapper/pdc_bcbeecdaj10 does not have valid superblock. I didn't noticed it because... well, I have lot of partitions, as you can see. And I didn't really anticipate the system changing the mountings on its own, either.
Thing is, 10 is not supposed to have reiserfs superblock because it doesn't have reiserfs. It's just a /swap partition. I checked fstab and indeed, for some reason it was pointing /home to ...10 and /swap to ...9. Surprisingly enough, it didn't work. So, I changed it back, and now it works it just fine.
The question of course is, how on earth did that happen? I am about 99.95% sure that I hadn't touched fstab during the last time Ubuntu was up and running. I did open it up before that, to check that /home had extended attributes turned on, as Beagle uses them. And before that because installed the latest ntfs-3g. I had problems getting FUSE's kernel module loaded, and rebooted to make sure it was running. And then the system indeed did boot, so fstab had to be intact.
And like I said, I'm pretty sure that I hadn't touched it after that, except to check that the user_xattr was on - which it was
(I had anticipated installing Beagle and turned it on way before).Sure, I'm happy that it's working. But I'm more than little puzzled about how did the fstab get f***ed up.
EDIT: Or even weirder, I found an old temporary copy of fstab. It's almost week old, which is also supported by the fact that it still has ntfs instead of ntfs-3g.
It looks like this:
#FileSystem MountPoint Type Options Dump/Pass
proc /proc proc rw 0 0
/dev/mapper/pdc_bcbeecdaj4 / reiserfs notail,noatime,user_xattr 0 1
/dev/mapper/pdc_bcbeecdaj10 /home reiserfs notail,noatime,user_xattr 0 1
/dev/mapper/pdc_bcbeecdaj9 none swap sw 0 0
/dev/mapper/pdc_bcbeecdaj1 /media/c/ ntfs nls=utf8,umask=0222 0 0
/dev/mapper/pdc_bcbeecdaj7 /media/d/ ntfs nls=utf8,umask=0222 0 0
/dev/mapper/pdc_bcbeecdaj8 /media/e/ ntfs nls=utf8,umask=0222 0 0
/dev/hdc1 /media/f/ ntfs nls=utf8,umask=0222 0 0
Notice anything... bizarre?
Yeah, /home has indeed been pdc_bcbeecdaj10, and it has worked that way for several days and several reboots. Nothing changed fstab, but it seems that the partition numbers themselves have changed.
So, how come? Wait... I did run Partition Magic in Windows after the last time Ubuntu worked. I didn't
do anything with it, just started it and closed down when I realized that it can't do removable USB sticks. Did it refresh the partition table, or something? Because physically /swap
is after /home on the RAID-array, it just had smaller number as it was created before /home. Then again, /home was created with Partition Magic too, so if it was going to mess with the numbers, you'd expect that it had already done it during the first time it was creating new partitions.
Oh well, at least it works.
