learnings from upgrading a notebook

Lennart Sorensen lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org
Tue Sep 2 17:49:41 UTC 2008


On Mon, Sep 01, 2008 at 09:24:30PM -0400, D. Hugh Redelmeier wrote:
> 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.

No actually the BIOS is wrong.  Some BIOS vendors seem to assume you
will use windows and hence PAT rather than MTRR to deal with things but
for backwards compatibility and linux use, this is not nice.

There is nothing X can do to help the problem.  Linux could get their
PAT support completed (which they are working away at), which should
take care of it.

For most of these systems that do overlapping messed up MTRRs, 64bit
windows often runs dreadfully slow as well, although it isn't so much a
problem of overlapping MTRRs for that as for having some memory not
covered at all and hence uncached.

The MTRR is becoming rather hopeless though given it just doesn't have
enough entries to deal with the amount of ram in modern machines
anymore.

> 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.

Vista chainloads fine from grub2.

You can easily repair the vista boot sector using the recovery console
after which it is perfectly happy.  This requires a vista DVD to boot
from of course.

> 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.

Using /dev/sda for grub worked great for me.

> 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.

No idea. :)

-- 
Len Sorensen
--
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