|
Subject: : learnings from upgrading a notebook Newsgroups: gmane.org.user-groups.linux.tolug Date: Tuesday 2nd September 2008 01:24:30 UTC (over 9 years ago) 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 |
||