Lots of problems since upgrade to 9.10

Rolling back is not an option, you would have to perform a clean installation. So as our only choice is to fix 9.10, let's give it a try (I assume you already have made a back-up of your valuable data before upgrading. If not: this would be a good moment!):

1) Hard disk: try to use e2fsck, look in de manpage, you'll find the -c and -p options interesting. Note that the command must NOT be run on read/write mounted filesystems.

So unmount any filesystem you want to check or mount it read-only. You cannot unmount the he root filesystem, but you can do the following (where /dev/hd?? must be replaced and $ is the command prompt):

$ init 1
$ mount -o remount,ro /dev/hd??
$ fsck -C /dev/hd??

I am not sure where all the bad blocks come from... maybe they were already there, but up to now not addressed (upgrading performs a lot of deleting and writing, so other parts of the disk may now be in use). If it is really bad, watch your backups closely. If it is a recurring problem, consider replacing the disk.

2) Sound: If you hear sound in VLC, then your sound card is OK. In the commandline start alsamixer and ensure that the slider of the PCM channel is up (ESC to quit). If that's not it, it could be many things... please come back then.

3) Touch pad: I need to guess... did you look for deselected checkboxes in the settings for Keyboard & Mouse? Else it might be an x.org problem.
You can try:
$ sudo aptitude purge xserver-xorg-input-synaptics && sudo aptitude install xserver-xorg-input-synaptics

4) Slow: check use of excessive resources with "top" (press "q" to quit) or "ps aux". Also perform a memory check to check even more hardware failures (in CMOS or use the entry Ubuntu has made available in GRUB). (You didn't throw your laptop out of the window, did you? :-) )
I've read some stories about upgrades not using the right kernel version (you can see this in GRUB) and therefore being slow.

I'd start with the memory test (it will take a while though). You could also check how your laptop performs with a 9.10 LiveCD.

Hope this helps

Johan

Thanks for that...

I'm currently in a Live CD of 9.10. The touch pad and sound card are both working properly, and everything seems to be running a pretty good speed. The only issue from before that remains in the Live CD as the local install is that the hard drive apparently still has bad sectors... But apart from that, everything is fine in a Live CD.

So now I'm going to go and reboot into the local install and try the ideas you've given me. :)

1) Hard disk: I can't find what to replace "hd??" with. Which drive would it be? Is there a way to find out which drive has which number?

2) Sound: I tried alsamixer in the terminal, it doesn't work. It says: "alsamixer: function snd_ctl_open failed for default: No such file or directory"
I went to the Ubuntu Software Center and installed ALSA Mixer that I found there, but I still get the same thing when I try to open it from the terminal, and when I open it from the menu all it has a config window with about 4 options, none of them a slider or anything.
When I try to play music, it says it's playing, but it's as if it is muted: no sound comes out. It is not muted, it is at full volume. But it still doesn't do anything.

3) Touch pad: I had already looked, and have looked again, at the mouse settings; there is no mention of touch pad anywhere that I can see. I looked through a few different parts of Preferences and Administration, and found nothing to do with a touch pad. So that command you gave me didn't do anything, either.

4) Slow: I tried the Live CD, and it ran well, at a good speed. Then rebooting back into the local install, it's really slow again. I tried "top"--nothing seemed to unusually. Root did sit around 100% sometimes, but not all the time. Is that a bad thing?
About the wrong kernel... How would I tell this?

I am going to reboot and run memtest now, too see what that brings up.

1) This will list your partitions:

$ df -h

among the output are lines like (/dev/sda1 is the root partitions, indicated by the "/"):
/dev/sda1 19G 3,4G 15G 20% /
/dev/sda5 61G 20G 38G 35% /home
/dev/sda7 2,8G 1,1G 1,6G 39% /var
/dev/sda6 61G 180M 58G 1% /media/disk

(not that these are named sd?? instead of hd??)

2) problem might be wrong kernel version, see 4)

3) awaiting 4), if implementing 4) doesn't solve this issue, try the command in my first post (under 3) ) again.

4) execute this command at a console, it wil list your kernel version number:

$ uname -r

it should read: "2.6.31-14-generic" (or "2.6.31-14-generic-pae" if you have more than 3GB of memory). If it lists another number, you want the latest kernel to be installed:

$ sudo aptitude install linux-generic

If it is installed, reboot:
$ shutdown -r now

Now watch the GRUB menu as the computer boots and see that it boots to kernel 2.6.31-14

Please report back if this was helpful to you and which problems persist (apart from the bad blocks).

Last line under 1) should read:
"(note that these are named /dev/sd?? instead of /dev/hd??)"

Thanks. Just quickly, before I do anything... I was trying to post this last night, but then the Internet crashed and I couldn't. So here it is.

I totally just had a brainwave. You know how you mentioned something about kernels? Well, I don't usually pay much attention to GRUB, I just hit enter twice (after entering my BIOS password) and it skips right past it. So when I went to boot memtest, I actually looked at what GRUB said and noticed that it still said Ubuntu 9.04 everywhere.

Now, I have Ubuntu dual booting alongside Windows Vista (Ubuntu being my primary OS), and so when I first got them running alongside each other I needed to change the name for half the boot options, plus reorder them. This required editing the menu.lst file. In order to keep the bootloader list how it was, whenever I'm asked whether to keep the current menu.lst or replace it, I choose to keep the current one. Usually this doesn't present a problem.

But whilst Ubuntu was upgrading today from 9.04 to 9.10, I was asked many many times what I wanted to do with it. I just kept choosing "keep current version". So when all was done, the current one was kept, and it still remains.

Could this be the cause of the problem? Would the menu.lst file from 9.04 be telling GRUB to boot with the wrong kernel or other settings? If this is the case, then how do I go about obtaining the correct menu.lst?

Thanks!

I just ran the "uname -r" command. Yes, I am in fact using the wrong kernel. This is what I got:

"2.6.28-11-generic"

Could this be because of the above mentioned issue?

I won't do anything else until I receive another reply, just to be sure about the menu.lst thing.

Yes, that could be one major source for your problems.
N.B.: Have you secured your data yet?

Now try to install the new kernel, it may (or may not) exist already, but if it does, it will say so.

If (and only if) NO new kernel is being installed, read the next few lines.

menu.lst is no more in 9.10. GRUB will generate a menu.cfg file (which is not meant to be edited) after issuing the following command:
$ sudo update-grub

then reboot and look for changes. If everything goes well you should have better experiences. If everything goes wrong, you will not be able to boot into Ubuntu or Vista, but let's assume that everything goes well :-)

I have backed up the entire Ubuntu partition, and my main data on the Windows partition.

I will go and try to install the new kernel now.

Hmm...

Well I ran "sudo aptitude install linux-generic" and it said that nothing was being installed, updated or removed. So I ran "sudo update-grub" and it said it updated something, but curiously at the end it still said "menu.lst updated" or something along those lines. Anyway, I rebooted and GRUB was still the same, saying Ubuntu 9.04 and kernel 2.6.28-11-generic.

From this I would gather that the new kernel has been installed, but GRUB is using the old kernel and doesn't seem to want to update... :S

Ah joy... well... the problem is clear, I had to search a bit how to handle it. Obiously the system thinks it is still 9.04, so it uses the latest kernel for 9.04 and the GRUB belonging to 9.04.

What we want is the old GRUB to disappear and GRUB2 to be installed. The following I took from another post (http://ubuntuforums.org/showthread.php?t=1313323&page=3) and checked with an extensive manual (http://ubuntuforums.org/showthread.php?t=1195275). I trust the advice (sounds logically):

$ sudo mv /boot/grub /boot/grub_legacy
$ sudo mkdir /boot/grub
$ sudo aptitude purge grub grub-common
$ sudo aptitude install grub-pc
$ sudo update-grub
$ sudo grub-install /dev/sda

IMPORTANT NOTE 1: Where /dev/sda is the disk where you want the boot loader to be installed (normally this would be the disk where Ubuntu is installed upon). You can check your configuration with:
$ df -h or
$sudo fdisk -l (the option is a small "L" derived from "list")

if all ubuntu partitions start with /dev/sda use that.

IMPORTANT NOTE 2: do not reboot during this process, because you will not be able to and it takes even more steps to re-install GRUB from the liveCD.

explanation of the commands: we park the files generated by the old GRUB in another file and prepare a clean folder for GRUB2, then we remove (and purge) the old GRUB packages and install the new one. Next, we generate the configuration file which GRUB2 will load to indicate the installed operating systems. Then the most important step: we install the bootloader to a disk, which will enable your laptop to start it and read the generated configuration list.

If all this completed succesfully, you should now have GRUB2 on your laptop. You might as well check if /boot/grub/grub.cfg contains any entries by typing:
$ sudo cat /boot/grub/grub.cfg

It should display several menu entries as of line 55. If that's all OK, I'd say you're ready to reboot and see if the new GRUB works (exciting moment, enjoy!).

If you encounter any errors, just post it here (but don't shutdown or reboot).

Thanks for this.

I have encountered something I am unsure of.

I just ran the command "sudo aptitude install grub-pc" (all has gone fine so far) and it has come up with a blue terminal saying:

Configuring grub-pc
"The following Linux command line was extracted from /etc/default/grub or the `kopt' parameter in GRUB Legacy's menu.lst. Please verify that it is correct, and modify it if necessary."

Then it has "Linux command line:" and an empty space to type in. I assume that there is meant to be a line there (or that there is actually just an empty line in the mentioned file?)... What should I do here?

These are Kernel OPTions while booting. You can find the ones that are applicable to your laptop in your old menu.lst (good that we didn't remove it). Open another console and do:

$ sudo cat /boot/grub_legacy/menu.lst | grep kopt=

This will display your kernel options. You should take over everything after "# kopt=". This could be, e.g. "root=/dev/sda1 ro quiet splash" (without quotes). But it could also be a little different.

make sure no trailing spaces are added.

It works!

I went through it all and then rebooted, after successfully finishing the GRUB install, and the first thing I noticed as it was starting up was that there was SOUND. Then at the login screen I used my TOUCH PAD to move the mouse. And now I can use applications at a decent speed again! :D

The boot speed is still slower than it used to be, but that could just be that it was the first time booting with the new kernel?

Either way, once booted, it's all good. :)

Unfortunately, the hard drive still apparently has bad sectors... I should probably try that suggestion you mentioned earlier, now that my computer is moving at a decent speed for my patience, and I know how to find the right drive number. I shall do that soon.

One other thing, the GRUB boot screen had way too many options... It has the normal entries for Windows, but there are heaps for Ubuntu.

If I recall correctly, there is as follows:
Ubuntu 2.6.31-14-generic
Ubuntu 2.6.31-14-generic (recovery)
Ubuntu 2.6.28-11-generic
Ubuntu 2.6.28-11-generic (recovery)
memtest...
memtest [random string og numbers and letters]

Then Other...
Windows loader
Windows loader
(where one is Vista and the other is Recovery)

So the normal Windows ones, but the old AND new Ubuntu ones. You said it's not meant to be edited... Why's that? Is there any way I could fix that up?

Thank you thank you thank you thank you!

I tried to check my hard disk using the commands you gave me... but it wouldn't work.

Here's what happened:

$sudo fsck -C /dev/sda2
[sudo] password for brandon:
fsck from util-linux-ng 2.16
fsck: fsck.ntfs: not found
fsck: Error 2 while executing fsck.ntfs for /dev/sda2

Any ideas?

Great to hear that most problems are solved, Bsnapz!

I thank you, too, for trusting me and giving good feedback during the process!

The GRUB menu is just fine like this. If you want you can remove kernel 2.6.28-11, but it does no harm just being around. Generally speaking it is good practice to keep a few kernels. Sometimes regression occurs in newer kernels, which breaks functionality for your system. Sometimes you can't even boot in such a scenario. At that point it might be useful to boot with an older kernel which still works. When you upgrade Ubuntu, it will remove some older kernels (so that the list won't grow infinitely).

It wasn't in my expectation that the bad sectors would be fixed by a new kernel, because it is a hardware problem. I checked out some details about bad block recovery.
If you are interested you can read http://smartmontools.sourceforge.net/badblockhowto.html
It is a tool which can monitor the health of your hard disk (your hard disk must support it).

If you think this is just too much of a hassle,

$ init 1
$ umount -r /dev/sd??
This will try to u(n)mount a partition or, if that doesn't succeed, remount the filesystem read-only.
you should see a difference in the file /etc/mtab (currently mounted partitions). It should say "ro" (read-only) and not "rw" (read/write) for the partition you umounted or remounted read-only.
If the command is successful, you can skip section A below and go on to the next command on the same partition.

----section A----
Sometimes, however, there's some stubborn process that makes that you cannot umount. If that is the case, we need to track that process and kill it. For that it would be good to know what the error is. Please post here.
---End of section A---

$ e2fsck -pfv /dev/sd??
(this is the same check that runs once in a while during boot, it repairs only if that is safe; the report should show you how many bad blocks there are)

If you feel you need to add bad blocks to the bad block list, use (umounting obligatory, but you already did it, see above commands):
$ e2fsck -cv /dev/sd??

Basically what it does is adding bad blocks to a blacklist (not usable). It may lead to loss of data, because data is suddenly missing. Using the smartmontools manual, you can identify which files will be affected, so that would be a slightly better method.

Now on your question regarding the ntfs error: e2fsck is meant to check ext file systems. It is (AFAIK) not suitable for NTFS or FAT file systems. However, if you want to check your windows partitions, too, you can use windows tools. Here again, using "fsck" could cause loss of data. Often, disk vendors have utilities to check your harddisks (might not be a bad idea).

small addition for being complete: bad blocks can be hardware problems OR filesystem problems. I am not completely confident, but I guess filesystem problems can be corrected by tools like e2fsck (with -p option), but for hardware problems, it is better to turn to advanced tools if you want to be sure not to loose data. That is because earlier mentioned tools can only avoid using a particular part of the disk (the -c option of e2fsck), which might cause "gaps" in files.

and another small addition :-)

You should thus run e2fsck only on partitions using ext2, ext3 or ext4. You can check which partitions that are by issuing the following command as root (or use sudo if you are using your own ordinary account):

$ fdisk -l

The output for my system is:
   Device Boot Start End Blocks Id System
/dev/sda1 * 1 2432 19535008+ 83 Linux
/dev/sda2 2433 19457 136753312+ 5 Extended
/dev/sda5 2433 10458 64468782 83 Linux
/dev/sda6 10459 18484 64468813+ 83 Linux
/dev/sda7 18485 18849 2931831 83 Linux
/dev/sda8 18850 19457 4883728+ 82 Linux swap / Solaris

I would check sda1, sda5, sda6 and sda7 (I do not need to check the partitions marked "Extended", because it's just a container for other partitions and I do not need to check Linux swap, because it is used as RAM).

The main reason I want to edit the GRUB menu is that I want to re-order the options, plus rename the Windows options (as they both say simply Windows Loader--I want an easier way to tell them apart). In the past I always used "sudo gedit /boot/grub/menu.lst" and made the necessary adjustments. Could I do that with the menu.cfg file? If so, where is this located? (As it doesn't seem to be in /boot/grub as far as I could tell.)
I'll keep in the old kernel, then. I never thought of that. One question still remains though: Why are there two memtest options?

When I try the command "umount -r /dev/sda2" it comes up with two different responses.

If /dev/sda2 was mounted, it says nothing, but unmounts it.
If /dev/sda2 was not mounted, it says: "umount: /dev/sda2: not mounted"

Either way, mtab has no mention at all of /dev/sda2 afterwards. In case it helps, here's the file (/etc/mtab):

/dev/sda5 / ext3 rw,relatime,errors=remount-ro 0 0
proc /proc proc rw 0 0
none /sys sysfs rw,noexec,nosuid,nodev 0 0
none /sys/fs/fuse/connections fusectl rw 0 0
none /sys/kernel/debug debugfs rw 0 0
none /sys/kernel/security securityfs rw 0 0
udev /dev tmpfs rw,mode=0755 0 0
none /dev/pts devpts rw,noexec,nosuid,gid=5,mode=0620 0 0
none /dev/shm tmpfs rw,nosuid,nodev 0 0
none /var/run tmpfs rw,nosuid,mode=0755 0 0
none /var/lock tmpfs rw,noexec,nosuid,nodev 0 0
none /lib/init/rw tmpfs rw,nosuid,mode=0755 0 0
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,noexec,nosuid,nodev 0 0
gvfs-fuse-daemon /home/brandon/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,user=brandon 0 0

Note: This IS a Windows partition (NTFS) so that could be why? I wouldn't be able to check this, anyway.

Here's what "fdisk -l" gives me:

/dev/sda1 1 1208 9701376 27 Unknown
/dev/sda2 * 1208 22893 174177734+ 7 HPFS/NTFS
/dev/sda3 22894 24321 11470410 5 Extended
/dev/sda5 22894 24254 10932201 83 Linux
/dev/sda6 24255 24321 538146 82 Linux swap / Solaris

sda1 is Windows recovery; sda2 is Windows; sda5 is Ubuntu.

Question: Is it safe to run something such as "umount -r /dev/sda5" when that is the partition Ubuntu is on, when you are using Ubuntu? I don't particularly want to try it in case I crash Ubuntu.

Another question: Does the partition have to be mounted (read-only) for e2fsck to work, or can it just be not mounted at all?

One more random question: You mentioned having to be root, or else using "sudo" if you were on your normal account. I've always just used sudo, cos I haven't been able to figure out how to log-in to root. How do you do this?

lots of questions :D

sda2 isn't meant to be checked, because it belongs to windows. You should only check /dev/sda5 (it is the only non-swap linux partition).

Unmounting is better, but mounting read-only is the second option in our order of preference.
You cannot completely unmount sda5 because it contains the root directory (and we have to use some elements of the installation, right? Like the little programs that we call with the commands we type!)
Therefore, the only option for sda5 is to be mounted read-only (with the umount -r command, unmounting will fail, but the -r option will then continue to remount read-only; you can receive feedback of the command by adding the -v option, verbose mode).

$ init 1
$ umount -rv /dev/sda5 (it will now show you feedback, whether the filesystem was umounted or remounted read-only)
$ e2fsck -pfv /dev/sda5
If it doesn't help enough and you can suffer to loose a few bits:
$ e2fsck -cv /dev/sda5
otherwise, you should read into smartmontools to know which files you should restore from back-up.

About logging in as root: you should not do that, it is bad practice. But if you boot and select 'safe mode' and 'drop to prompt' you will be root already.
In general, you can login as another person with:
$ login [username]

About two memtest options... actually... I wouldn't know!

If you want to remove the old kernel (which doesn't work too good anyway, so let's do it):
$ sudo aptitude purge linux-image-2.6.28-11-generic
(doublecheck to make sure you don't delete the new kernel ;-) )

The old menu.lst file is now called grub.cfg (not menu.cfg). But since that file is overwritten at each reboot, it's no use to edit it!
You can change options in the file /etc/default/grub
E.g. "GRUB_DEFAULT=4" will probably select your windows entry by default (after you have removed the old kernel).
You can change some other options there.
I think you can only change the order of boot options by renaming the files in /etc/grub.d/, but I wouldn't recommend it.
See http://ubuntuforums.org/showthread.php?t=1195275 for an extensive manual. It also describes how you can e.g. disable the memtest options in the GRUB menu.

Sorry I've taken so long to get back to you. Just had exams and was way too buried in studying to get on to this.

I tried: "umount -rv /dev/sda5" and it said:
"umount: /: device is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))"

I take it that it didn't work... :P

Are you still able to help me?

sorry, didn't see the notification of your previous message.

Please make sure you boot in safe mode, drop to root prompt and then execute the "init 1" command. With the -r option umount should remount in case unmounting is not possible.
If it still doesn't work, try to add the -f option (force):
$ umount -rvf

Just need to clear one thing up, cos it still doesn't seem to be working.

What do you mean by "boot in safe mode"? I cannot find a way to do this. The only way to boot that I can tell, besides normal boot, is in recovery mode.

When I try doing the above commands in recovery mode, logged in as root, I get the same error. Even with the -f option.

I meant recovery mode indeed. If you get this "device is busy" error, try to seek&kill the disturbing process:

$ fuser -km /dev/sda5

or look for the process id (second column) with either command (you may need to vary the search term after grep):
$ ps aux | grep /dev/sda5
$ lsof | grep /dev/sda5

and then kill it:
$ kill [id]

You can find more details about these commands by entering:

$ man [command]