learnings from upgrading a notebook

D. Hugh Redelmeier hugh-pmF8o41NoarQT0dZR+AlfA at public.gmane.org
Tue Sep 2 01:24:30 UTC 2008


I recently got a Thinkpad x61t tablet.  I did a few upgrades and
learned a few lessons.  I thought I'd report them here in case this
saves someone else some bother.


RAM
===

I replaced the 1G of RAM that it came with.  Two 2G SIMMs (the maximum
possible) cost only $70-ish, so why not?

The supplied OS was 32-bit Microsoft Windows Vista Business.  Until
Service Pack 1, Vista could only recognize and use about 3.2G.  The
rest was a waste.  After SP1, Vista can recognize but not use more
memory.  Of course this lack of ability to use is not evident.  64-bit
Vista can handle more.

With this much memory, the BIOS sets up the variable MTRRs with
overlapping ranges.  This prevents X from changing the frame buffer's
type to "write combining".  This probably has significant performance
impact.

The BIOS is not wrong.  X and the kernel are.  This is a long-standing
problem for some systems with 4G or more RAM.  I have a worse form of
it on my desktop.

Here's one relevant reference
https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/253204


Hard Disk
=========

I replaced the 80G hard drive with a 320G hard drive.  $80 (excluding
tax, after rebate).  500G drives have started to become available but
they are quite expensive.

I don't know enough about HD brands and models to choose the best.
Instead, I opportunistically bought an inexpensive Hitachi from the
same family as the one supplied by Lenovo.

Why isn't 80G enough?

- 5G is tied up in the recover partition

- Vista whined horribly at me that it was running out of space in the
  25G partition I had left it.  And the only thing I installed other
  than Vista updates was firefox.  Unbelievable.

When I used parted to shrink the original Vista partition, Vista
became unbootable.

Eventually, I discovered a workaround/fix.  Vista would not boot
chainloading from grub.  I had put the grub bootsector on the Linux
root partition, leaving the normal bootloader on the MBR.  If instead
I used fdisk to mark the Vista partition as the bootable partition,
Vista came up and repaired some damage (no errors were reported, so I
don't know what was wrong).  This is a very fragile OS.

The machine came with no installation media for Vista.  Eventually I
tried to use the recovery partition.  It could not recover!  Not only
did it fail, but it rendered the Vista itself unbootable.  I could
order DVD's from Lenovo for $50.  Lenovo Support did not know any
other way to address my problem and didn't offer to send the DVDs for
free.

It turns out that it ("ThinkVantage") could recover if I told it to
only overwrite "c:".  It failed if I asked it to perform the more
natural task of re-initializing the whole disk.

To transfer the data from the old 80G drive I used a live Ubuntu disk
and an external hard drive:

- dd raw 80G from internal drive to file on external drive.  Note
  This is a whole-drive copy, not just a partition.  Thus the MBR
  and all partitions are copied all at once.

- swap in new 320G drive

- dd 80G of content from external drive to internal drive

- adjust partitions to taste.  The first thing I did was extend the
  extended partition to fill the disk.

Beware: when dding from or to a raw disk, make sure none of the partitions
is mounted and that none is being used as swap.  I rediscovered how
Ubuntu live systems automatically discover and use swap partitions.


Grub
====

Using parted, I moved the /dev/sda3 partition.  This broke grub.  This
makes sense: the stage of grub in the boot sector needs to know where
the next stage lives.  It would be nice if parted knew how to fix this
but that seems like it is putting too much onto parted.

I don't know the right way to fix that grub.  I tried the technique
that is supposed to work with Fedora:

	- boot live CD
	- mount /dev/sda3 /tmp/root
	- cd /tmp/root
	- chroot /tmp/root
	- grub-install /dev/sda3

This failed because there is no /dev/sda3 in that root filesystem.
Something must build it no the fly.

I redid the procedure after doing a mknod somewhere other than /dev/sda3
since I didn't want to clash with the normal mechanism.  This didn't
work, possibly because grub thinks it knows the meaning of the
pathname.

So I started over.  I booted from a grub floppy.  That was easy; type
in:
	- root (hd0,2)
	- configfile /boot/grub/menu.lst
then booting proceeded as usual.

Once booted, I needed to reinstall grub so that I don't need to keep
using a boot floppy.

	sudo grub-install /dev/sda3
This failed with an obscure message:
	Error /dev/sda3 does not have any corresponding BIOS drive
This worked:
	sudo grub-install --recheck /dev/sda3
	sudo grub-install /dev/sda3
Note that --recheck is considered iffy.  I don't know if the second
command was required.

For some reason that I don't understand, the sudoers file broke at
this point.  Mysterious.
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists





More information about the Legacy mailing list