I have a 500GB Toshiba 2.5' HD, which I formated using Debian Wheezy 64bit. I created 2 partitions (180GB and 320GB).
RPi would only recognize the first partition. 

So, I tried creating the partitions using the raspberrypi. Here are my surprising findings:

root@raspberrypi:/home/ozn# fdisk -l

Disk /dev/mmcblk0: 4025 MB, 4025483264 bytes
4 heads, 16 sectors/track, 122848 cylinders, total 7862272 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000dbfc6

        Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1            8192      122879       57344    c  W95 FAT32 (LBA)
/dev/mmcblk0p2          122880     7862271     3869696   83  Linux

Disk /dev/sda: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x950e3b8d

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048   625142447   312570200   83  Linux
/dev/sda2       625142448   976773167   175815360   83  Linux


First, /dev/sda is NOT recognized correctly! This disk is 500GB. 

Second, mounting /dev/sda2 is not possible:

root@raspberrypi:/home/ozn# mount -t ext4 /dev/sda2 /media/usbhdd1/
mount: special device /dev/sda2 does not exist
# although fdisk -l showed this device !


Third, trying to format the disk, it really sees only the sectors until 320GB:
When I start fdisk I am warned:

Building a new DOS disklabel with disk identifier 0x6784fc4b.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.


I have other USB hard drives with 320GB and they really mount fine. 


Is this a limitation of RPi? Or a problem with this specific Hard Drive?   
How can I use this large disk with my RPi? 


update: solved the issue with help of the commentators here...

here is what I did ...


I thought I have some weired issue with Debian Wheezy &amp; gparted. So, I reformatted the hard drive to NTFS. Before that I ERASED the partition table. 
And created a new single NTFS partition. 
Bingo! RPi, identified the partition. However, it claimed my Drive is now 2TB big, and recommended I will use GPT:

root@raspberrypi:/home/ozn# fdisk -l /dev/sda

Disk /dev/sda: 2199.0 GB, 2199023255552 bytes
255 heads, 63 sectors/track, 267349 cylinders, total 4294967296 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xf720f720

Disk /dev/sda doesn't contain a valid partition table
root@raspberrypi:/home/ozn# fdisk  /dev/sda
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0xb7032c3f.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

WARNING: The size of this disk is 2.2 TB (2199023255552 bytes).
DOS partition table format can not be used on drives for volumes
larger than (2199023255040 bytes) for 512-byte sectors. Use parted(1) and GUID 
partition table format (GPT).



whoops! That is WRONG!

So, I disconnected the hard drive again. re-connented it to my laptop. I erased the partition table again, and re-created the partition table using fdisk on RPi! not on my laptop! This time, I took a short cut, and created the disk partition with ext4 directly. 
    I plugged the hard-drive to RPi and BINGO!

root@raspberrypi:/home/ozn# fdisk -l

Disk /dev/sda: 500.1 GB, 500107862016 bytes
81 heads, 63 sectors/track, 191411 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000505b8

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048   976773167   488385560   83  Linux

Disk /dev/mmcblk0: 4025 MB, 4025483264 bytes
4 heads, 16 sectors/track, 122848 cylinders, total 7862272 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000dbfc6

Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1            8192      122879       57344    c  W95 FAT32 (LBA)
/dev/mmcblk0p2          122880     7862271     3869696   83  Linux

Disk /dev/sda: 500.1 GB, 500107862016 bytes
81 heads, 63 sectors/track, 191411 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000505b8

Device Boot      Start         End      Blocks   Id  System
/dev/sda1            2048   976773167   488385560   83  Linux


The disk is now identified correctly on my laptop with Debian. 

ozdeb@yenitiny:~$ sudo fdisk -l /dev/sdb

Disk /dev/sdb: 500.1 GB, 500107862016 bytes
81 heads, 63 sectors/track, 191411 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000505b8

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048   976773167   488385560   83  Linux


conclusion (?)

My guess is that gparted in Debian Wheezy includes some nasty bug which is sometimes showing it's ugly face. I would report a bug if I had more solid evidence. But ... since I have only one 500GB hard drive, and I don't want to
risk the health of this hard drive reformatting it so many time, I will settle this with it. If you happen to bump into this post, and you have had similar problems with large SATA drives and partitioning on wheezy, I would be happy to know.


Question: XOR Gate design problem
Answer: Conceptually, I can see why you implemented the circuit this way:


If either of SW1 or SW2 is closed - either Q1 or Q2 will conduct and the current will flow to the LED
However, if both SW1 and SW2 are closed - both Q3 and Q4 will conduct which will cause Q5 to conduct. When Q5 is conducting, there is not enough voltage on LED to turn it on


Good thinking, really.

However, BJTs have high current gain (\$\beta\approx100\$). It means that even a low current to the base of Q5 will be amplified and the LED won't turn on. But how comes there is a current to the base of Q5 when SW1 is open? Isn't Q3 behaves as an open circuit when SW1 is open? The answer is NO - BJT transistors have very interesting behavior when operated with floating base. They are not, in general, behave like an open circuit.

What can you do? Well, in real applications you wouldn't design and use such a circuit. However, given that you are educating yourself (and me too), I'd suggest you try to apply the following changes:


Why did you choose 9V power supply? Each BJT has a maximum rating for \$V_{CE}\$ - check the model file that you're using and change your power supply accordingly. How this may help? Well, reducing \$V_{CE}\$ of Q3 may cause it to behave more like an open circuit when SW1 is open.
Try to add pull-down resistors between bases of Q3 and Q4 and the ground (these resistors must be pretty large). This approach will prevent the base of Q3 from being floating when SW1 is open (respectively for Q4 and SW2).
If none of the above worked, I suggest you'll try to find a way of "stealing" the current from the led which is not that sensitive to small unwanted currents as a single transistor. You may try to replace Q5 with Q3 and Q4 directly (collector of Q3 is connected in place of Q5's collector, emitter of Q4 is connected to ground).


Please let me know about the results.