PDA

View Full Version : [ubuntu] 10.04 to 10.10 Upgrade Halts; Unbootable



mattruby
October 21st, 2010, 08:46 PM
The short version is that using update-manager to upgrade from Ubuntu 10.04 to 10.10 made my OS crash on booting, and now I'm stuck in several days waiting for gparted to shrink the partition so I can create a new one into which to install a new 10.10 OS.

The detailed version:

I used update-manager last week to upgrade my Ubuntu 10.04 to 10.10. Everything went well, taking about an hour or two, with the upgrade indicating steadily completing progress (time remaining steadily decreasing). But when the progress reached 15
minutes remaining, it stayed at that "time left" for over half an hour, maybe an hour. I clicked to cancel, and the update cancelled. But the OS was unusable - lots of apps were obviously missing, as I found when I tried to use the commandline. I tried to reboot, thinking the upgrade had left some tasks for cleanup on reboot, but the OS wouldn't boot: it would boot through the text screen, then the screen would go completely blank, then the monitor would power down as if there were no VGA signal, though the PC continued to remain powered on.

I figured that I needed to install a new Ubuntu from scratch. So I took an Ubuntu 10.10 LiveCD and booted. I started to run the OS installer, but I wasn't sure that a new install wouldn't delete my existing data, like my APT installed packages status,
my email and browser data, downloaded files, etc. So I decided to shrink my 220GB partition that had only 72 GB of data, creating a new 100GB partition to install a bootable Ubuntu, into which I would transfer my old data. I started GParted and
started the shrink operation.

That was *four days ago*. The GParted "progress bar" in the "applying pending operations" window is just a colored block that moves back and forth in the bar, indicating (I suppose) only that the process isn't hung. Above the progress bar it
says "Shrink /dev/sda2 from 219.85 GB to 119.85 GB"; under the bar it says "check file system on /dev/sda2 for errors and (if possible) fix them". "Completed Operations" says "0 of 1 operations completed". In "Details" it says "Shrink
/dev/sda2 from 219.85 GB to 119.85 GB" with a pair of gears in the rightmost column. Indented in the next row it says "calibrate /dev/sda2", then a column to the right that says "00:00:00", and a column with a green checkmark. Indented in the next 4 rows is what looks like data for a "recalibrate" task for my /dev/sda2. The next row has indented at the same level as the "Shrink..." row the text "check file system on /dev/sda2 for errors and (if possible) fix them", then an empty column, then a
column with a pair of gears. Indented in the next row is "e2fsck -f -y -v /dev/sda2".

I opened a terminal window, and ps showed e2fsck running, but at a nice of 19. I used renice to set it to -20.

Mainly I want to get back a working Ubuntu, whether 10.10 or 10.04. Of course I don't want to lose my data in the /dev/sda2 partition that I asked to resize. So at least I need to know how much longer the resize operation is going to take. If it's
"only" another day I can wait. If I can cancel the resize safely I will. I could have bought a new HD, partitioned and installed, and copied everything from my old one to it in the time it's already taken, and I'd now have a backup on the old drive. If I can cancel or wait out the resize, I still need to make the HD that the 10.10 installer left incomplete into a working Ubuntu, and restore it to my APT state with my email, browser data, etc.

Thanks for your help.

P4man
October 21st, 2010, 10:29 PM
Its absolutely not normal its taking THAT long. A few hours at most.

Do you see anything in dmesg?

BTW, I wouldnt bet on it, and I wont accept responsibility for data loss, but I THINK you will be okay cancelling it. If I understand it correctly it hasnt even started moving stuff around, and once I even hit the reset button accidentally in the middle of resize operation and I was able to recover from that with no apparent data loss (I did have to fix partition tables). Absolutely not recommended of course, but just FYI.

mattruby
October 21st, 2010, 10:49 PM
Its absolutely not normal its taking THAT long. A few hours at most.

I have seen plenty of comments on websites saying their gparted operation was taking several days, and people agreeing that's normal, and some calculations explaining why.



Do you see anything in dmesg?

I don't see any activity in (grep sda2 /var/log/messages) since starting gparted.



BTW, I wouldnt bet on it, and I wont accept responsibility for data loss, but I THINK you will be okay cancelling it. If I understand it correctly it hasnt even started moving stuff around, and once I even hit the reset button accidentally in the middle of resize operation and I was able to recover from that with no apparent data loss (I did have to fix partition tables). Absolutely not recommended of course, but just FYI.

At what point in the process would gparted start moving data around? If it's already running e2fsck I would think it's done moving data, and is now performing fsck on the resized partition, which would be the final task of the whole operation.