View unanswered posts    View active topics

All times are UTC - 6 hours





Post new topic Reply to topic  [ 9 posts ] 
Print view Previous topic   Next topic  
Author Message
Search for:
PostPosted: Thu Nov 19, 2009 11:30 pm 
Offline
Joined: Sat Mar 22, 2008 10:24 pm
Posts: 26
Location: Dsm, IA
So I took the jump [baited breath], and the upgrade failed. :(
I'll try to step through what happened, and end where I am now.

I switched fstab to UUIDs in R5.5 before the upgrade. I ran with this for a few days and a few reboots/remounts to make sure it was working correctly before upgrading, so I don't think I messed up there. I have not switched the boot drive to sata yet, as responses here left me wary of doing that.
I ran checkbackup after mythbackup. They both reported no errors.

The upgrade gave me no explicit errors. I got no "Couldn't find the config file, proceed with update?" or other screen here (didn't know it existed til later..). I got the positive "successfully finished", "100%", and "done" (or whatever they were, I've only run through it once so far...). The only hint things weren't going as they should would've been the upgrade/installer asking things it should've known, like root pwd and static IP. --but what did I know?, R6 with Arch is SO different, I don't know what to expect it to need or not.

After reboot, it booted to the default LinHES Myth menu, only 'locked'. *this might be a seperate issue; Does choosing "no_remote" cause it ignore the keyboard too? Only the menu was like this, I could switch to VTs just fine.
I started investigating and found no database, mysqld.log empty, mythweb empty, and questioned what configuration it did import..
I'm assuming it found savedfiles.tar.gz but not mythconverg.tar.gz (even though they are both in /myth/backup), because there are /alsa.old and /etc.old folders in /, with R5.5 files in /etc.old. The new fstab also had a new UUID for /, so it appears like the installer reformatted that partition, found savedfiles.tar.gz, and copied these R5.5 files in.

Before the upgrade, the UUID equivalents of fstab made the drive layout like this:
hda1= /
hda2= swap
hda3= /myth3
hdb1= /myth2
hdc1= /myth
The switch to libata appeared clean, with the drives themselves becoming:
hda1 > sda1
hda2 > sda2
hda3 > sda3
hdb1 > sdb1
hdc1 > sdc1
However, the new R6 fstab had the equivalent (in UUIDs) of:
sda1= /
sda2= swap
sda3= /myth
and when /myth was unmounted, the myth folder of / I was using as a mountpoint now has a new "/miro/Movies" tree in it.
Is any part of the upgrade assuming /myth to be only at the 3rd partition of the 1st disk?

~~~~~
Then, I made a mistake: I put the PC to sleep overnight, via suspend-to-disk. I apparently used the wrong method, because when I went to boot it back up it did not unroll itself back to where it was before, and there were many filesystem errors for /. Using a recent LiveCD, I fscked / and remade swap. So, new problems: the new /etc is gone (scattered about lost+found), swap has a new UUID, and it will no longer boot.

When I try the CD again I get "Couldn't find the config file, proceed with update?"

Advice?

Are all the config files it's looking for in /etc, in savedfiles.tar.gz, or elsewhere?
If I manually pull savedfiles.tar out of savedfiles.tar.gz, edit fstab inside savedfiles.tar, and re-gzip it, the timestamp will be different. Will this be safe for the installer?
Why are there really old mythconverg-xxxx-xxxxxxxxxxxx.sql.gz files in /myth/tv ?
While in the LiveCD, I also moved all the recordings out of /myth3, so it can be scrapped if needed.

I'll be in #linhes during most of the day if anyone wants to help me that way :) . I can walk through this with someone so the "bug" can be found and an entry put in flyspray, if needed.


Last edited by stonewalker on Sat Nov 21, 2009 1:23 pm, edited 2 times in total.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Nov 20, 2009 9:56 pm 
Offline
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location: Arlington, MA
See the post I linked to in stonewalker's thread. It includes some clues. http://knoppmyth.net/phpBB2/viewtopic.php?t=20302

I saw the "Couldn't find the config file, proceed with update?" message too until I did this.
tjc wrote:
Copy your backup to /root/backup which is an alternate place that the new installer looks. This may not be necessary but it definitely helped with my LVM case.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Nov 20, 2009 11:39 pm 
Offline
Joined: Sat Mar 22, 2008 10:24 pm
Posts: 26
Location: Dsm, IA
Yes, I've read that. And I fully admit I hadn't copied the backup to /root/backup the first time around. However, I didn't get that message the 1st time. Only on my 2nd try, after / had been messed up by the suspend-to-disk.
Now / is a borked R6 install. It's Ok to put a copy in /root/backup on it and use that?
Shouldn't I at least edit the fstab in savedfiles.tar.gz so the new UUIDs match, or is the /myth drive the only one that matters (whether it changes or not..) ? Will the time/date mismatch on the two files throw the installer off?

Thanks


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 21, 2009 9:08 am 
Offline
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location: Arlington, MA
You should probably _not_ restore your original fstab because the UUID of the reformatted partition will change. R6 is actually pretty good about bringing across the fstab from the image that it's upgrading if you do the UUID conversion for it, so it shouldn't even be necessary. This may actually be your main problem. (Restoring your xorg.conf is a bad idea too as noted in that thread.)

Memory says that the installer also acts differently if it finds an existing R6 install versus an R5.5 install.

My first move would be to boot into rescue mode and try repairing the /etc/fstab on the disk. Mount the root partition off the HD, Use the blkid utility to find the current UUID, and then edit the fstab file on the disk appropriately.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 21, 2009 1:13 pm 
Offline
Joined: Sat Mar 22, 2008 10:24 pm
Posts: 26
Location: Dsm, IA
Quote:
You should probably _not_ restore your original fstab because the UUID of the reformatted partition will change.
Which is why I thought of editing it so it would match again on installation start.

Quote:
R6 is actually pretty good about bringing across the fstab from the image that it's upgrading if you do the UUID conversion for it, so it shouldn't even be necessary. This may actually be your main problem.
What may be? I did the UUID conversion!

Quote:
My first move would be to boot into rescue mode and try repairing the /etc/fstab on the disk. Mount the root partition off the HD, Use the blkid utility to find the current UUID, and then edit the fstab file on the disk appropriately.
So, say I do this; 1. Create a new /etc & /etc/fstab on sda1 (remember, they are GONE now..), listing out the UUIDs correctly from blkid. 2. Copy the backup to /root/backup. What happens when the installer runs? :arrow:
Quote:
Memory says that the installer also acts differently if it finds an existing R6 install versus an R5.5 install.
Will it just foul up again because it's expecting a working R6 install when it finds any kind of R6 on the drive?

I could start over by installing R5.5 from scratch > then restoring backup > then new backup (just so the new UUIDs get caught) > then R6 install, but that's a long way if it just ends back at the "~~~~~" point ^^^ above!
I feel like I'm between a rock and a hard place, forced to go back to R5.5 because the R6 installer won't work. :(


Top
 Profile  
 
 Post subject:
PostPosted: Sun Nov 22, 2009 10:50 am 
Offline
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location: Arlington, MA
stonewalker wrote:
Quote:
You should probably _not_ restore your original fstab because the UUID of the reformatted partition will change.
Which is why I thought of editing it so it would match again on installation start.

Quote:
R6 is actually pretty good about bringing across the fstab from the image that it's upgrading if you do the UUID conversion for it, so it shouldn't even be necessary. This may actually be your main problem.
What may be? I did the UUID conversion!

It sounds like I misunderstood what you were doing. My impression was that you were restoring your old fstab from the backup. That's what I was talking about.

stonewalker wrote:
Quote:
My first move would be to boot into rescue mode and try repairing the /etc/fstab on the disk. Mount the root partition off the HD, Use the blkid utility to find the current UUID, and then edit the fstab file on the disk appropriately.
So, say I do this; 1. Create a new /etc & /etc/fstab on sda1 (remember, they are GONE now..), listing out the UUIDs correctly from blkid. 2. Copy the backup to /root/backup. What happens when the installer runs? :arrow:

I'm a bit confused, did you lose the R6 install and end up with a blank root partition somehow?


Top
 Profile  
 
 Post subject:
PostPosted: Sun Nov 22, 2009 12:42 pm 
Offline
Joined: Sat Mar 22, 2008 10:24 pm
Posts: 26
Location: Dsm, IA
It's not blank, but it's not complete either.
I'm not sure what partial amount = writing it off as a total loss, but:
It won't boot.
/etc is gone. Parts of it are in lost+found, but I've got no idea how to put everything back where it goes. Even if I could, it wouldn't be back 100%.
Who knows what other files are gone. /etc is the big obvious missing folder, but random other files could be gone as well. Since I don't know what exactly the installer looks for (other than the backup and fstab..), I don't know what to make sure is there.

The ideal would be to make the installer think it's still an R5.5 > R6 upgrade, have whatever config files it's looking for on the drive, and have the installer correctly stay on /myth throughout the install.
Whatever guidance can get me closer to that would be appreciated. Thank you.


Top
 Profile  
 
 Post subject:
PostPosted: Mon Nov 23, 2009 8:24 pm 
Offline
Joined: Thu Mar 25, 2004 11:00 am
Posts: 9551
Location: Arlington, MA
Well the good news is that if you still have your backup you can always revert to R5.5. The last time I tried to upgrade my production box LVM and X issues along with a severe shortage of time to monkey with it forced me to do just that. Probably not the answer you wanted, but I don't have a better one at the moment.

Also the inclusive backup selective restore means that 100% of your old /etc was preserved in the backup. When I'm paranoid enough about an upgrade/downgrade/sidegrade I often unpack the backup somewhere else and do a recursive diff (using meld these days) to compare the two trees.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Nov 25, 2009 12:55 am 
Offline
Joined: Sat Mar 22, 2008 10:24 pm
Posts: 26
Location: Dsm, IA
Quote:
Probably not the answer you wanted, but I don't have a better one at the moment.

No, it's not. :cry: ... But I understand your POV. You've been good about helping all you could. I just wish someone with a better understanding of the installer could pipe in and give a basic rundown of the steps the new installer takes, so those of us with problems can more intelligently troubleshoot them. Then we could find the source and potentially post it on flyspray. I would honestly like to post it if it isn't just a one-time fluke that I had.

It seems the installer found /myth during one part of the upgrade/install ,as evidenced by the .old directories, and did not during another, as evidenced by the missing mythconverg DB and the creation of /miro/Movies in the mountpoint directory.
Crazy Q: The mountpoint directory I was using for my /myth drive was on / (the same as default?). This wouldn't cause the upgrader to stop looking at that empty directory would it?

Quote:
Also the inclusive backup selective restore means that 100% of your old /etc was preserved in the backup.

Thanks for reminding me. I will 'upgrade'-install R5.5, restoring the backup, then try extracting all of savedfiles.tar.gz back to their former places with the LiveCD. Should I try running the patcher at some point too?
If I tried the R6 upgrade again, I bet the installer would finish if I put a copy of the backup in /root/backup, as then it wouldn't have to find any other drives. If it failed to correctly find the /myth drive again, it would just put the DB in the empty mountpoint directory, which I could then manually move/fix later.
I guess my only decision is whether I do that or try one more time without /root/backup just to see if it was a fluke.

Quote:
When I'm paranoid enough about an upgrade/downgrade/sidegrade I often unpack the backup somewhere else and do a recursive diff (using meld these days) to compare the two trees.
To make sure it gets everything?


Top
 Profile  
 

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 


All times are UTC - 6 hours




Who is online

Users browsing this forum: No registered users and 34 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group

Theme Created By ceyhansuyu