PDA

View Full Version : [ubuntu] 8.04 upgrade on Dell Inspiron 530



Janeleaper
August 20th, 2008, 06:47 PM
I have a Dell Inspiron 530 which I bought loaded with Gutsy 7.10.

I've been trying to upgrade it to Hardy 8.04. After a lot of hassles I've reached this point:

I can only boot up by going into the GRUB menu and choosing kernel 2.6.22-14. Even then it does not always boot and I have to go into 2.6.22-14 recovery mode.

Kernel 2.6.24-21 will not boot, even in recovery mode. I've tried recovery several times without success. I've also tried sudo dpkg --configure -a in terminal, and sudo apt -get update several times.

Reading the Dell Ubuntu wiki, I get the drift that I should probably switch to RAID from IDE in Bios, but I'm a noob and I don't know how to do this.

Can anyone help?

Janeleaper
August 20th, 2008, 07:05 PM
I'd like to add that if this is a problem with the Dell hardware or settings, then I'm not very impressed. My machine is only a month old and was sold to me with no documentation alerting me to the problem I'd have upgrading.

superm1
August 20th, 2008, 07:47 PM
It's a bug that is resolved in kernel 2.6.26. There are two workarounds (as indicated in the wiki).

1) Switch the mode from IDE to RAID in the BIOS
2) Add all_generic_ide to the boot parameters.

Janeleaper
August 20th, 2008, 07:49 PM
Thank you. But, I don't know how to do this. I went into the Dell menu (f2 from the Dell screen) but it did not give me this option, as far as I could see. I'm going to need more explicit instructions on what to do.

superm1
August 20th, 2008, 07:59 PM
I don't have a 530 in front of me, so I'll try to describe the second solution:

1) Hit ESC to open up the grub menu.
2) Highlight the first option and hit "E"
3) At the end of the second command line showing boot parameters add "all_generic_ide"
4) Boot

5) Edit /boot/grub/menu.lst
Look for a line similar to this:
# kopt=root=UUID=5db4588f-50e0-4d00-b073-82aaad496204 ro

At the end of that line add all_generic_ide

6) Run update-grub
sudo update-grub

prinknash
August 20th, 2008, 08:06 PM
Thank you. But, I don't know how to do this. I went into the Dell menu (f2 from the Dell screen) but it did not give me this option, as far as I could see. I'm going to need more explicit instructions on what to do.

From memory:

- After pressing F2, you enter 'Setup'.
- At the 'Integrated Peripherals' screen, go to SATA mode and select RAID (rather than the default IDE)
- Save changes and reboot.
p

Janeleaper
August 20th, 2008, 08:20 PM
Thanks to both of you. I'll try one of the options you've given me and report back.

Janeleaper
August 20th, 2008, 08:48 PM
Thanks to both of you again. I tried Prinknash's solution because it was easiest, and it has worked. I am left with one small glitch. The login screen is shifted to the right so there is a black margin down the left hand side, although it does not interfere with login.

I had this problem on the desktop as well, but solved it by trial and error with screen resolution settings. I don't know how to change the screen resolution settings for the login screen.

I can live with this, but if you know the solution I'll have a go at fixing it.

superm1
August 20th, 2008, 10:14 PM
Thanks to both of you again. I tried Prinknash's solution because it was easiest, and it has worked. I am left with one small glitch. The login screen is shifted to the right so there is a black margin down the left hand side, although it does not interfere with login.

I had this problem on the desktop as well, but solved it by trial and error with screen resolution settings. I don't know how to change the screen resolution settings for the login screen.

I can live with this, but if you know the solution I'll have a go at fixing it.
You might be able to get away with resolving this by using the "auto adjust" function of your monitor.

Janeleaper
August 20th, 2008, 10:59 PM
COOL! That worked. Thanks.

jjtstan
August 25th, 2008, 02:28 PM
If I could follow up on Superm1's post:



1) Hit ESC to open up the grub menu.
2) Highlight the first option and hit "E"
3) At the end of the second command line showing boot parameters add "all_generic_ide"
4) Boot

5) Edit /boot/grub/menu.lst
Look for a line similar to this:
# kopt=root=UUID=5db4588f-50e0-4d00-b073-82aaad496204 ro

At the end of that line add all_generic_ide

6) Run update-grub
sudo update-grub

I completed the first four steps, I believe.

On my 530, the first option is kernel 2.6.24-19-generic, the second option is 2.6.24-19-generic (recovery mode), followed by 22-15 and 22-15 (recovery mode) and 22-14 and 22-14 recovery mode.

So I selected 22-19 (regular, no recovery mode), edited the boot parameter line, and booted. The result was the same as the problem I have been having, described here:

http://ubuntuforums.org/showthread.php?t=865679&highlight=upgrading+hardy&page=10

Basically, I can log in blind, and then get a blank beige screen. Mouse continues to track, just no way to raise a terminal window or do anything.

I tried this also with kernel 22-14 regular, with the same results. I guess I will try prinknash's solution next (resetting IDE to RAID), although I'm a little confused why, if dpkg --configure -a fails due to excessive errors, that resetting IDE to RAID will help

The error I get is this:


dpkg: too many errors, stopping
dpkg: ../../src/packages.c:251: process_queue: Assertion `!queuelen' failed.eric (recovery mode), -15

I'm running a Dell 530 with Nvidia 8300 graphics card.

Any help appreciated.

jjtstan
August 25th, 2008, 03:44 PM
I've taken failure to new levels.

I've now tried prinknash's solution, which returned me to the familiar blank beige screen.

I also tried following superm1's advice, except booting out of 26-14 recovery mode (rather than 26-19 regular mode). I stayed in the command line mode, which provided marginally more progress, in that the machine checked the mount on my hard drive - something I hadn't seen it do before.

I then edited /boot/grub/menu.lst, ran update-grub, and rebooted. Which got me back to my friend the blank beige screen.

I've since tried re-running dpkg --configure -a in the kernel 26-14 recovery mode, and once again got the


dpkg: too many errors, stopping
dpkg: ../../src/packages.c:252: process_queue: Assertion `!queuelen' failed.
Aborted

message. This is slightly different than the last error message I quoted; I think I copied it wrong last time.

Also, when I ran sudo dpkg --config -a this time, I never got a chance to enter my password, which struck me as odd. I went directly to the "too many errors. . failed . .Aborted." Which strikes me as a little odd.

Janeleaper
August 25th, 2008, 05:02 PM
You have my deepest sympathy, since you are going through what I went through and then some. The only extra advice I can give is that I found running recovery mode (in kernel 14) several times reaped results. This was before I'd followed the advice to set IDE to RAID. After running 14 -recovery several times I was able to boot into 8.04, but only from 14-recovery and not every time. Sometimes I had to run recovery twice or three times before it would boot. However, the IDE/RAID thing did finally sort it out.

jjtstan
August 25th, 2008, 05:19 PM
Thanks.

I had this idea in my head that if the upgrade installation number was reasonably high, and it had been a few months since the new upgrade came out, most of the crippling bugs would be gone. . .

I guess I should have read up first.

Hopefully someone out there's fixed this, cause I'd rather not lose my data. I'm reading as much as I can now, but most of the things I read are along the lines of: dpkg --configure -a or reformat the disk.

jjtstan
August 25th, 2008, 05:57 PM
Other things I have since tried:

Sudo apt-get install –f

Error: dpkg was interrupted, you must manually run ‘dpkg –configure –a’ to correct the problem

Rm /usr/bin/localedef

dpkg --configure -a continues to fail in the same way, with dpkg: too many errors, stopping
dpkg: ../../src/packages.c:252: process_queue: Assertion `!queuelen' failed.
Aborted

Apt-get upgrade – some index files failed to download, have been ignored or old ones used instead. Dpkg was interrupted, you must manually run dpkg –configure –a to correct the problem

Apt-get update -- no change, just a direct order to manually run dpkg

hubie
August 26th, 2008, 01:59 AM
As I was correcting my borked update, I would get the blank beige screen as well. However, I didn't worry about it because all I needed was the command line, which I got to by doing the usual Ctrl-Alt-F1 command. I logged in and from there continued to do my dpkg --configure -a command.

The only hang up I received was when it was chugging along after getting by the en_AU locale problem and it got to somewhere (something having to do with updating init.d) and it failed with a "too many dependencies" error. All I needed to do from here was to reboot into the latest kernel (whereas before, I had booted into an earlier kernel), Ctrl-Alt-F1 back to the command line, and reissue the dpkg --configure -a command. The newer kernel apparently took care of all the dependency issues that hung me up. I suggest you might want to give that a try because I was getting a similar error as you.

jjtstan
August 26th, 2008, 04:24 AM
When you ran dpkg --configure -a out of the command line after booting, did you boot regularly or into Gnome failsafe mode?

hubie
August 26th, 2008, 11:24 AM
The first time I booted into an older kernel (14, I think) in the recovery mode option. That got me as far as the error I mentioned. I then rebooted normally, meaning I didn't go into GRUB and thereby booted into the latest normal kernel. I didn't do anything Gnome related (I did get the login field to pop up) because I ignored it and went straight to the F1 login screen.

jjtstan
August 26th, 2008, 04:05 PM
Hey, the ctrl-alt-F1 worked really well for me. I booted into kernel 26-14 because people seemed to be saying that was the way to go for repairs. I chose a GNOME Failsafe session, which sent me to the blank beige screen. Crtl-Alt-F1 got the command line, and then I ran

sudo apt-get update
sudo apt-get upgrade, and
sudo dpkg --configure -a

in that order. the upgrade and the dpkg both hung on installation of ivman, but after logging out and rebooting into the most recent kernel, things seem pretty much normal, apart from the heron on my desktop.

I've lost the ability to mount my USB hard drive (NTFS format), which I think is related to my problems loading ivman.

Also, I keep getting messages (twice in the past hour) that a program has crashed. But those are topics for other threads.

So thanks very much to everyone who posted here and in the other thread.

Very nice to have the computer back. Even nicer to have kept my data.

Thanks again.

hubie
August 27th, 2008, 12:54 AM
I'm very happy it worked out for you. I never accept the "reformat the whole drive" advice as there usually seems to be another way. Even if the drive dies, all is still not lost (the Trinity Rescue Kit (http://trinityhome.org/Home/index.php?wpid=1&front_id=12) is my best friend).

Good luck cleaning up the loose ends. And go out and back up that data! ;)

DavidTangye
August 28th, 2008, 02:36 AM
I had this idea in my head that if the upgrade installation number was reasonably high, and it had been a few months since the new upgrade came out, most of the crippling bugs would be gone. . . I thought the same. Unfortunately in this case the bug was introduced in possibly a combination of kernel 2.6.22.15, released June 19th, and something else released prior to 17th July, when it was reported on Launchpad (https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/249340) by Nathaniel Gray (https://bugs.launchpad.net/%7En8gray-n8gray).

DavidTangye
August 28th, 2008, 02:49 AM
I'm very happy it worked out for you. I never accept the "reformat the whole drive" advice as there usually seems to be another way. Even if the drive dies, all is still not lost (the Trinity Rescue Kit (http://trinityhome.org/Home/index.php?wpid=1&front_id=12) is my best friend).

Good luck cleaning up the loose ends. And go out and back up that data! ;)
Certainly there is often an alternative to reformatting and starting again, especially to allow you to recover your data. However continually hacking a fix is obviously not guaranteed to clear all hidden mis-configuration issues, which I believe generally surface some time later in the future and cause no end of confusion in what seem to be entirely unrelated facilities. I have always had the impression that a large number of problems with systems reported here are due to hacks of some sort back in the past that effectively left time-bombs in people's own systems. These waste time (and in the commercial world, money) trying to trace. So the most effective way strategy to avoid this is to not hack in the first place. Tactically, yes, hack and recover if you must, but then flag the system as untrusted until it is rebuilt. Due to this latest bug, this machine is unfortunately now in that category.