Mar 18 23:52:25 home kernel: [ 8661.700076] scsi_add_timer: scmd: ffff81004da8a700, time: 7500, (ffffffff88123ed0)
Mar 18 23:52:25 home kernel: [ 8661.700117] scsi_delete_timer: scmd: ffff81004da8a000, rtn: 1

If you too are suffering from this then do the following:

1. First, stop it right now by starting a shell and typing:

sudo sysctl -w dev.scsi.logging_level=0

2. To make sure it doesn’t start up again after a reboot then edit the file /etc/sysctl.conf and add this line anywhere in the file:

dev.scsi.logging_level = 0

And you should be all set.

a

Bookmark to:

(WW) NVIDIA(0): No valid modes for "1920x1200"; removing.
(WW) NVIDIA(0): No valid modes for "1600x1200"; removing.

To get the X server to tell you exactly why it’s removing those two modes, try starting X with -logverbose 6 as arguments, and it will log something like this instead:

    (II) NVIDIA(0): Validating Mode "1600x1200":
    (II) NVIDIA(0): 1600 x 1200 @ 60 Hz
    (II) NVIDIA(0): For use as DFP backend.
    (II) NVIDIA(0): Mode Source: EDID
    (II) NVIDIA(0): Pixel Clock : 162.00 MHz
    (II) NVIDIA(0): HRes, HSyncStart : 1600, 1664
    (II) NVIDIA(0): HSyncEnd, HTotal : 1856, 2160
    (II) NVIDIA(0): VRes, VSyncStart : 1200, 1201
    (II) NVIDIA(0): VSyncEnd, VTotal : 1204, 1250
    (II) NVIDIA(0): H/V Polarity : +/+
    (WW) NVIDIA(0): Mode is rejected: PixelClock (162.0 MHz) too high for
    (WW) NVIDIA(0): Display Device (Max: 150.0 MHz).

If this used to work for you, and all you did was upgrade Ubuntu (or some other distro), then edit your /etc/X11/xorg.conf file and add the line

Option         "ModeValidation" "NoMaxPClkCheck"

inside either the Screen or the Device group. Restart X and it should start up in a higher mode again. For more interesting options to set, try looking at the NVidia X driver documentation.

Leave a comment if you’re lost and I’ll try to guide you through the tricky parts.

a

Bookmark to:

Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run `apt-get -f install' to correct these.
The following packages have unmet dependencies:
  language-support-writing-en: Depends: openoffice.org-hyphenation-en-us but it is not installed
E: Unmet dependencies. Try using -f.

The easy fix out of this one is to start up System->Administration->Synaptics Package Manager and uninstall “openoffice.org-hyphenation”. This will trigger a removal of about 85 packages including OpenOffice itself. When that is done, use the same Package Manager to install OpenOffice again and in goes the 85 packages again.

The second one looked like this:

Setting up python-apt (0.7.4ubuntu5) ...
Traceback (most recent call last):
  File "/usr/bin/pycentral", line 1593, in 
    main()
  File "/usr/bin/pycentral", line 1587, in main
    rv = action.run(global_options)
  File "/usr/bin/pycentral", line 982, in run
    self.pkg.byte_compile(bc_option, self.options.exclude)
  File "/usr/bin/pycentral", line 624, in byte_compile
    rt.byte_compile(files, bc_option, exclude_regex)
AttributeError: 'NoneType' object has no attribute 'byte_compile'
dpkg: error processing python-apt (--configure):
 subprocess post-installation script returned error exit status 1

This has now been fixed, and a new python-central should be available at the repositories. I hacked my python-apt to bypass this before the official fix was out, but all you should have to do is update/upgrade as normal and everything will be fine.

a

Bookmark to:

Aaaanyway, there is really nothing to it. Edit your /etc/apt/sources.list and change all references to edgy to feisty. I.e. replace edgy with feisty throughout the file. Then run apt-get update and  update-manager -c, both as root. You may have to say yes to one or two "are you sure you’re willing to destroy your system"-questions, but what the hey. After that, you’ll be the proud owner of a bleeding Ubuntu system and you’ll be able to do an apt-get update as often as you wish and more or less be guaranteed to get an update every time. Upgrade bliss.

a

Bookmark to:

 # sudo apt-get install ntp-server

This is technically it, but the stock installation does not adjust your time right away if it is way out of sync. So we just do this to make sure we’re correct from the start:

# /etc/init.d/ntp-server stop
# ntpdate -s pool.ntp.org
# /etc/init.d/ntp-server start

There, you’re in sync and will stay in sync from now on.

a

Bookmark to:

Note up front that the procedure is somewhat new and you must either be willing to lose every bit of data on the disk array you are playing around with or made a recent backup. There are absolutely no guarantees here.

You know that your current kernel is too old if you get these kind of error messages when you try to grow your array:

# mdadm –grow /dev/md0 –raid-disks=4
mdadm: Cannot set device size/shape for /dev/md0: Invalid argument

And maybe also:

# mdadm –grow /dev/md0 –raid-disks=4
mdadm: /dev/md0: Cannot get array details from sysfs

Once running the newer kernel however, this is how I did it. Current setup is one RAID5 array with 6 disks.

 # cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
      
md0 : active raid5 sda[0] sdf[5] sde[4] sdd[3] sdc[2] sdb[1]
      1465180480 blocks level 5, 32k chunk, algorithm 2 [6/6] [UUUUUU]

 Adding a disk to the array will cause it to be tagged as a spare, only to be used if one of the existing disks fail:

 # mdadm –add  /dev/md0 /dev/sdg
mdadm: added /dev/sdg
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]

md0 : active raid5 sdg[6](S) sda[0] sdf[5] sde[4] sdd[3] sdc[2] sdb[1]
      1465180480 blocks level 5, 32k chunk, algorithm 2 [6/6] [UUUUUU]

And now for the critical part, telling the raid set to convert the spare into a working part of the array. The way this is done is with the –grow argument and telling the array how many disks the array will be made up of after the insertion. Since we had 6 disks to begin with, the new number is 7.
 

# mdadm –grow /dev/md0 –raid-disks=7
mdadm: Need to backup 960K of critical section..
mdadm: … critical section passed.
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]

md0 : active raid5 sdg[6] sda[0] sdf[5] sde[4] sdd[3] sdc[2] sdb[1]
      1465180480 blocks super 0.91 level 5, 32k chunk, algorithm 2 [7/7] [UUUUUUU]
      [>....................]  reshape =  0.0% (49804/293036096) finish=489.2min speed=9960K/sec

Piece of cake, and as you can see our array has started to incorporate the new disk into the array. This takes a long time, since it has to rewrite the existing data across the existing disks and the new one.

After that is done, we need to expand the actual file system to fill the new, larger device we’ve just extended.  How to do this depends greatly on what file system you have of course. I’ll show one ext2/ext3 method here, but check out the LVM HOWTO for information about how to deal with the other types.

 Note that there is a way of resizing an ext2/ext3 file system without unmounting, but we’ll do it the safe way here:

# umount /dev/md0
# ext2resize /dev/md0
ext2resize v1.1.19 – 2001/03/18 for EXT2FS 0.5b
# mount /dev/md0

The ext2resize also takes forever on a large file system, in the order of several hours. So be patient.
 

There, that’s it.

a

Bookmark to: