Freeze When Updating

Have you tested your RAM for issues?
Was the CD you installed with checked for errors and burned as slowly as you couldf burn it?
Did you MD5 test the ISO you downloaded?

1. No, but the computer runs fine with no issues in Windows 7, and it would be a bit strange for RAM issues to cause a freeze when going for a specific file. I've also been using varying amounts of RAM when installing updates, for instance, I was using Firefox and installing drivers for the video, chipset, and wireless at the same time as running the updater the first time it froze. The second time, I went straight to update directly after it booted up the first time after install and did nothing else.

2. The CD was not burned. It's straight from the ISO through Wubi.

3. I downloaded it through BitTorrent, so it was verified automatically after completion, and I checked the MD5 checksum after. I also checked it after copying the ISO over the network from my desktop (where I downloaded it at) to my laptop, and the file integrity was automatically checked by Wubi before installation. So, yes.

However, I believe that if it were a bad checksum from the installation disk which could cause such an issue, I would be seeing problems before I could even get to the Update Manager, or when the manager first loads up, rather than when trying to access a recently downloaded update package after successfully handling quite a few before it.

A bad ISO will cause issues, it's important to MD5sum no matter what method is used to download but you are right that the torrent protocol adds extra checking.

Windows manages RAM differently to Linux so is worth a check.

Not using a CD takes one complication out which is good.

If you boot to root recovery mode (with networking), can you upgrade there ok? Have you chkdsk'd your NTFS partition? Wubi uses an image file for the Ubuntu "disk" so is very at the mercy of the shortcomings of NTFS, especially with fragmentation. a normal install of Ubuntu uses ext3 and does not get affected by any fragmentation so it is good to test your filesystem's health.

Well, I can't boot to Recovery Mode. If it freezes during update, and I hard reboot, then it won't boot into either the main Ubuntu boot or the Recovery Console. If I REISUB it, then it doesn't give me any time to choose the Recovery boot option, the Ubuntu boot submenu with the primary and recovery options flashes up for perhaps a tenth of a second before going straight to the primary boot.

I suppose checking the RAM might be useful, but I just can't see how it could cause such an issue with Linux when Windows 7 uses a hefty percentage of the RAM, and even all of it + pagefile (I don't have too much RAM in the laptop), with no freezes or crashes or errors of any sort.

As for the Filesystem, well, it's kept largely contiguous with MyDefrag (formerly JKDefrag) scheduled to run daily. I also tried to force contiguity in the ISO with MS SysInternals contig.exe, but it wasn't fragmented, but I didn't think to contig the installation directory just to make sure. I suppose I will try that next.

You hold shift before the grub loads and you can choose recovery mode from there (not sure if its the same in wubi but worth a try).

Daily defragging of your system is not advised as it severely labours the drive machanics and shortens drive life expectancy.

I'll try holding shift in GRUB if it happens again after I reinstall.

MyDefrag has scripts for daily, weekly, and monthly system or data disk defrag, and daily only defrags what it needs to and what it can easily defrag. Weekly goes a bit deeper, filling in gaps, and monthly reorganizes the entire contents of the hard drive to fit a set model, with boot and system files at the front of the disk, smaller frequently accessed files in the middle, and big, less accessed files at the end. So, once the monthly runs, daily is pretty much just housekeeping, and most subsequent monthly runs are just housekeeping as well, so long as there haven't been a lot of new installations or uninstallations in the meantime.

Ok. I used contig on the folder which it installs to (C:\ubuntu), and it defragged a couple files in there, nothing too big. I ran a memory checker for 20 passes on extended testing mode with no problems found, and I did a check disk on C: with no problems found.

So, I installed through Wubi again, booted up Ubuntu, and went to update. It got through to about 50% (I was a bit off on my previous assessment of how far along it gets), and it finishes replacing "libwww-perl 5.834-1", switches to "Preparing linux-headers-2.6.32-24" up under the progress bar and then this is displayed in the extended info:

Preparing to replace linux-headers-2.6.32-24 2.6.32-24.39 (using .../linux-headers-2.6.32-24 2.6.32-24.43_all.deb) ...
Unpacking replacement linux-headers-2.6.32-24 ...
[]

Where [] is a now no longer blinking console cursor location. So the hard drive light stops and total lock up ensues. So, I let it sit a while, about 15 minutes without any activity, just in case, then I REISUB it.

I hold shift and go into the Ubuntu recovery console, and it goes through it's thing and gets to:

Begin: Running /scripts/local-premount ...
Done.
[ 3.150705] EXT4-fs (loop0): INFO: recovery required on readonly filesystem
[ 3.150836] EXT4-fs (loop0): write access will be enabled during recovery
[ 6.326782] EXT4-fs (loop0): orphan cleanup on readonly fs
[ 6.327356] EXT4-fs (loop0): 10 orphan inodes deleted
[ 6.327479] EXT4-fs (loop0): recovery complete
[ 6.329584] EXT4-FS (loop0): mounted filesystem with ordered data mode
Begin: Running /scripts/local-bottom ...
Done.
Done.
Begin: Running /scripts/init-bottom ...
Done.
_

And stops. Just sitting there. No menu or hard drive light or anything.

Oh, also, if I reboot from there, it still boots up primary Ubuntu and freezes on boot.

sounds like an unhealthy drive. I recommend you boot to liveCD and fsck the partitions

Nope. Of course, there is no ntfs option for fsck at this time on the ubuntu livecd, but ntfsresize, ntfsfix, gparted, and the disk utility in the Live CD, as well as chkdsk and Crystal Disk Info in Windows, all give the hard drive and it's lone partition a clean bill of health.

I could just avoid updating that specific file, but by damn, if I could get Windows 98 and Red Hat playing nicely on the same disk before GRUB came along, then I can get this to do something as simple as updating the compiler kernel headers.

You can install ntfsprogs and get an fsck.ntfs. You have used wubi so boot to windows and check the partition there.

ntfsprogs is installed by default on the livecd (hence why there are such nice things as ntfsfix and ntfsresize, both parts of ntfsprogs). The ntfsprogs people even say that fsck.ntfs/ntfsck isn't currently available and to use ntfsresize to check for partition errors, but the about page for ntfsck was updated last year. I know it used to be there several years ago, because I've used it before, but seems that they've taken it out. There were also no updates available for ntfsprogs, I checked when I couldn't find ntfsck.

I think you may be barking up the wrong problem tree here. I've been maintaining computer systems for 20 years, and I know when there's bad hardware. I can feel it in my bones, like some sort of weird empathic man to computer link. Probably just the sum experience of reading the subtle cues of responsiveness and the minor ways in which the computer will react to stimuli as a piece of hardware gradually decays to faultiness though.

Well, I'm not sure if it was just setting the cache higher, or if it was the fact that I only selected the headers, headers-generic, and image-generic for update this time, but it went through. Never had to change the cache size for apt-get before.

As for the RAM suggestion, it is low, but I also said it runs Windows 7 fine, and if it runs Windows 7 fine, then you know that you can pretty much bet that any distro of Linux is gonna run fine, unless there's an Ubuntu Extreme Memory Leak Edition that I don't know about.

Thanks Sam, that solved my question.