Ubuntu recognizing 250gb drive as 137gb
 

Hi guys

I've been using Ubuntu exclusively for the past month and love it. Recently my old 80gb hard drive died so I went out and bought a new 250gb (IDE) yesterday. Installed Ubuntu (jaunty) no problem except that the drive is only recognized as 137gb. I realize this is the bios 48lba issue. My laptop is Sony Vaio pcg-v505dx --> the bios is upto the latest one (2004). When I go into the bios --> it recognizes it as 137gb and there is no option to turn on LBA or turn on/off autodetect.

I've read on the forum here that partitioning is the answer. I tried partitioning the drive so that there is a /boot, /swap, and / but to no avail. When I try boot straight from the LiveCD to check with partition editor, it too recognizes the drive as 137gb. Fdisk output also says 137gb. Isn't Ubuntu supposed to ignore what the bios says?

It's very frustrating when I see everybody else posting about how GPartEd can see their full drive capacity, when I cannot. I'd appreciate any help on how to get Ubuntu to recognize the full 250 of the drive. Thanks!

How do you know what size drive ubuntu is seeing?

Did you:
Upgrade the BIOS.
Make sure each partition has 137GiB or less, if you want to use that workaround.

In other words - same advice as you got here.

Note that the partitions need to be formatted, and mounted, for this to have any effect.

In the Windows world, the answer is to stop using an old disk of XP and use one with at least SP1. Have you been in the bios and made sure LBA is enabled? What is your hardware?

How did you set the jumpers in the hard disk?

or it is a bios problem

See if open bios supports the main board

I thought the OP made that clear. But I also am never comfortable with what the OP says about that until the OP does a copy/paste into the post of the output from some partition listing program such as:
Then copy and post the results

I thought he said no newer BIOS available.

Can you explain that one.

I think most of us understand why the /boot partition or the whole partition containing the /boot directory should be within the initial portion of the disk that the BIOS can see. But after that, why does it matter?

I wouldn't guess the answer there was the correct answer.

I didn't think Linux cared about what fraction of the disk the BIOS can see (beyond needing the BIOS to see enough to allow grub to load the kernel). Once you are in a Linux partitioning program, the BIOS limits should be gone.

I don't know why the OP only has access to 137GB. Maybe a switch in the drive (as amani suggested). Maybe the drive firmware has been programmed to pretend to be smaller (as discussed in several other threads about the nasty Dell boot code that makes a drive pretend to be smaller). See
http://www.linuxquestions.org/questi...36#post3115736
http://en.wikipedia.org/wiki/Host_protected_area

But pending a good explanation, I can't believe the size of partitions matter beyond the end of the /boot partition.

Based on that wikipedia article, I think the hdparm program would be effective both in diagnosing and correcting this problem.

Just a couple more possibilities...

1) The drive may exceed the maximum size that's usable by the MB.

2) The drive's onboard controller may have flaked out and won't allow access to the entire drive. Defective new drives aren't completely unheard of.

My suggestion is to plug it into a newer machine and see what happens.

Cheers

My apologies -- you mentioned your hardware. A little research showed it's an Intel 855 chipset and an IDE hdd. Neither should present a problem; they're reasonably modern.

Laptop drives almost always come with no jumpers, so that's not likely to be an issue.

dragonslayer48dx has a good suggestion. If you have access to a desktop and a 2.5" to 3.5" IDE adapter I'd try partitioning and formatting it that way and then see if your Sony sees all of it.

Thank you very much for the replies guys. I checked the disk size recognized GPartEd in while in LiveCD mode and also in the terminal with fdisk (both regular boot and LiveCD)
Here is the fdisk output
Disk /dev/sda: 137.4 GB, 137438953472 bytes
255 heads, 63 sectors/track, 16709 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000ea827

Device Boot Start End Blocks Id System
/dev/sda1 * 1 30 240943+ 83 Linux
/dev/sda2 31 212 1461915 82 Linux swap / Solaris
/dev/sda3 213 15409 122069902+ 83 Linux
/dev/sda4 15410 16709 10442250 83 Linux

I've tried partitioning it with only 3 parts (/boot, swap and /) and with 4 parts (/boot, swap, /home and /) --> both yield the same results

The bios is upto date with then newest one possible (from 2004)
The hard drive is a Western Digital Scorpio Blue 2.5" 250gb IDE drive --> when I look at the drive, I didn't see any jumpers but I will check again.

I think I found something interesting ... with the link that Johnsfine gave me regarding HPA and it's role in limiting hard drive size --> I noticed that Phoenix was mentioned AND that Phoenix bios is responsible for my Sony. Typing in hdparm, I find that HPA is enabled:

sudo hdparm -N /dev/sda

/dev/sda:
max sectors = 268435456/488397168, HPA is enabled

Do you guys think this HPA may be responsible and if so, how to get around it.

I'll ask around to see if any of my friends can lend me their computers to check the disk size and to partition it from there. Thanks again

RE: your opening post.

Just how big did you make those partitions? The point of partitioning is that none of your partitions is greater than 137GB. I have a hard time believing you assigned 100GB or more to boot and swap so the third one would be less than 137.

There used to be a boot option ("stroke") that would format all of a hard drive regardless of the size reported by BIOS. I don't know whether it is alive anymore, though.

http://www.linux.org/docs/ldp/howto/...k-HOWTO-4.html
http://ubuntuforums.org/showthread.php?t=1165648
... if we are looking at the usual 137GiB limitation, so long as the boot partition is at the start of the drive, it is not supposed to matter.

While some people report that sticking to 137GiB for all partitions works for them - it shouldn't matter on standard hardware. The usual approach for ubuntu would be to make a 10-30GiB partition for root (sda1), and use the rest for swap (sda2) and home (sda3).

What isn't clear is if the installer reports more that 137GiB on the drive. Please verify.
If it does not, you cannot, directly, use the repartition method to work around the limit, and the trouble comes from inside the drive itself.

You have stated that you have partitioned the drive, but fdisk seems to be reporting all your partitions inside the 137GiB range. Whats curious is that no empty space is reported.

Obviously! If it weren't responsible those two numbers 268435456/488397168 would be much closer together.

I'm not sure and mistakes certainly run the risk of trashing the contents of the hard drive.

I don't know how you disable HPA or whether your should. My own drive has HPA enabled:
The instructions for hdparm make it seem like the correct thing to do is

where you replace size with some number nearly as big as the max value of 488397168.

I've never tried anything like that. I don't know if it is important to make the value you choose divisible by something such as the cylinder size 16065 you quoted. The current value 268435456 isn't divisible by 16065, so probably not. I don't know whether you should go all the way up to 488397168 or just try for a little less than that. Clearly more would be wrong.

If you fix it that way, I expect once is enough. But maybe something in your BIOS or hidden boot code is setting it back and you would need your Linux startup script to re fix it on every boot (before accessing any partition outside the first 137GB).

That was a valid idea before seeing the results of hdparm. Now you're past having any value to the results of testing in a different computer.

If it were my situation, I'd back up anything important, then try the hdparm command to set it to nearly 488397168, then do the other hdparm command to see if the change initially stuck. Then reboot both to see if the change sticks past a reboot (use the hdparm command to list it yet again after reboot) and if all that is good the reboot should also let the partitioning tool finally see the larger size.

But again, it isn't my situation, I've never tried anything like that, and if the above advice is bad, I won't back it up with anything more than a heartfelt "oops".

Hi again, thanks for the speedy replies. To answer some of your questions:
@jay73 - I made the /boot 250mb, swap 1.5gb, /home 125gb and / for the remainder (~10gb)

@simon bridge - I put the boot partition at the very beginning of the drive. You are correct in that there is no empty space reported after. When I used the Ubuntu installer to check, it sees the drive as only 137gb with no extra space. When I used GPartEd to check when booting through LiveCD, it also shows a total of 137gb without any space available afterwards. It's as though I really did buy a 137gb drive (which I didn't .. ha ha). What do you mean that the trouble comes from the drive itself .. as in defective? Or as in stubborn hardware clash?

@johnsfine - thanks for the thoughts. I don't have any qualms about reformatting this drive over and over and over. I'll give the hdparm a whirl. Heh heh ... I like your disclaimer at the end :)

Hmmm .. bit of a road bump. I tried the hdparm -Nsize, but got the following message:
sudo hdparm -N488397168 /dev/sda

/dev/sda:
setting max visible sectors to 488397168 (temporary)
SET_MAX_ADDRESS failed: Input/output error
max sectors = 268435456/488397168, HPA is enabled

I then tried dmesg and scanned through the output and found the following. I'm new to Ubuntu, so not sure what to make of it --> it seems like Ubuntu wants to set the drive as larger but something is preventing it from doing so:
[ 3.880927] scsi0 : ata_piix
[ 3.881153] scsi1 : ata_piix
[ 3.883682] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x1860 irq 14
[ 3.883691] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x1868 irq 15
[ 4.102899] ata1.00: failed to set max address (err_mask=0x1)
[ 4.102908] ata1.00: device aborted resize (268435456 -> 488397168), skipping HPA handling
[ 4.102921] ata1.00: ATA-8: WDC WD2500BEVE-00WZT0, 01.01A01, max UDMA/100
[ 4.102929] ata1.00: 268435456 sectors, multi 16: LBA48
[ 4.116392] ata1.00: configured for UDMA/100
[ 4.272221] ata2.01: NODEV after polling detection
[ 4.280760] ata2.00: ATAPI: UJDA745 DVD/CDRW, 1.01, max UDMA/33
[ 4.296760] ata2.00: configured for UDMA/33
[ 4.297777] scsi 0:0:0:0: Direct-Access ATA WDC WD2500BEVE-0 01.0 PQ: 0 ANSI: 5
[ 4.298034] sd 0:0:0:0: [sda] 268435456 512-byte hardware sectors: (137 GB/128 GiB)
[ 4.298081] sd 0:0:0:0: [sda] Write Protect is off
[ 4.298089] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 4.298162] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 4.298322] sd 0:0:0:0: [sda] 268435456 512-byte hardware sectors: (137 GB/128 GiB)
[ 4.298364] sd 0:0:0:0: [sda] Write Protect is off
[ 4.298372] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 4.298442] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 4.298452] sda: sda1 sda2 sda3 sda4
[ 4.321982] sd 0:0:0:0: [sda] Attached SCSI disk
[ 4.322103] sd 0:0:0:0: Attached scsi generic sg0 type 0

Again, thank you for taking time into looking at my situation

[ 4.102908] ata1.00: device aborted resize (268435456 -> 488397168), skipping HPA handling
http://ubuntuforums.org/archive/index.php/t-924543.html

This feels familiar... I keep thinking you need to edit the bios entry for your drive to show the correct drive geometry, and the rational part says nonsense, there are no grub errors and the system boots. I suspect that I've encountered this problem way back when I saw the grub ones. Curiously, one of the guys in the above link had a similar idea.

Discussion of HPA issues arising from upgrading HDD size.
http://lkml.indiana.edu/hypermail/li...08.0/1158.html

I am seeing a bunch of unresolved problems like this one - each one has an old dive die, to be replaced by a new, large one. Something common to the whole is that the subsequent drive also dies or that the ide controller or the socket or the mobo also has damage.

Perhaps we should rule this out:
Have you tested the old drive in another machine?
Have you tested the new drive in another machine?

It's a bit of a long shot, but did you try a smaller value?

If I computed it right, partitioning rules won't let you use more than 488392128 out of 488397168 anyway, so trying slightly smaller won't loose any usable space. Maybe there is some very small but non zero minimum on the size of the HPA (the difference between the two numbers).