I am unsure as to whether this problem is a bug in Puppy, so I'll start by enquiring in this sub-forum...

I am using Puppy with Kernel 2.6.31.14. I believe it is Cielo but I can't be sure as 'system information' does not tell me. I am not at the level of rebuilding Puppy to suit my own needs, so i am using an out-of-the-box download that does most things for me. I mainly run this on an EeePC (ASUS) as it was the only one I found that actually worked (details at the end for the interested).

To the problem...
I have a 3TB Western Digital (elements) hard disk. However, when I connect it to Puppy it reports a size of 746.5GB, and refuses to mount it.
At first I thought it might be the EeePC, so I booted Puppy (same version) on a desktop machine, and the same thing.
The disk is fine, as I can read/write it using both windows and ubuntu. The full capacity is reported and available.

Details of my EeePC install. The 'Cielo' version of Puppy was the only one I found that
- the sound in the EeePC worked
- it had libreoffice
- it had a VLC player install that worked
It has problems though
- the WiFi can't do AES connections. I don't use it for internet, so it is something I have not put a great deal of effort into solving.
- I would like a 'second monitor' on the external VGA port. I have to boot windoze to use this.

If I (dual) boot the computer using Win XP, the disk is fully accessible, and the correct size is reported.

The disk is formatted NTFS: Puppy does support NTFS for all my other disks, perhaps there is a problem with large NTFS volumes?

When I ask Puppy to mount the drive, it tells me it can't, and prompts again. When I hover over the icon, it reports a disk size of about 750GB. Interestingly this is one of the 'newer' type drives with the so called 'advanced' format : the sector size is 4096 bytes rather than the usual 512 bytes.

More interestingly, if I multiply the sector size difference (8x) by the size that Puppy reports the drive size to be, I get double the actual size.

IE: 8 x 750 GB ~ 6 TB (3 TB drive).

It is probably important that I add this is an external USB attached drive (I forgot in my original post), as apparently there is some issue with internal 3TB (and larger) drives - predominantly with Windoze though.

Is Puppy OK with 4k sectors, or is there some issue?

Ubuntu is OK with this drive, so it is unlikely to be a Kernel thing (unless my Puppy is extremely out of date).

Nikkel, Bruce J. (September 2009). "Forensic analysis of GPT disks and GUID partition tables". Digital Investigation 6 (1-2): 39–47. "The current popular BIOS and MBR partitioning scheme was originally developed in the early 1980s for the IBM Personal Computer using IBM PC-DOS or MS-DOS. The Basic Input/Output System (BIOS) provides an interface to the hardware and initiates the boot process (IBM, 1983). The MBR, located in sector zero, contains the initial boot code and a four entry partition table (Microsoft, 1983). Intended to solve booting and partitioning limitations with newer hardware, a replacement for both the BIOS and the MBR partition table was developed by Intel in the late 1990s (Intel, 2000). This is now called the Unified EFI (UEFI, 2008 UEFI Forum. Unified extensible firmware interface specification version 2.2 2008.UEFI, 2008) specification, and managed by the UEFI Forum (UEFI, 2009). A subset of this specification includes GUID (globally unique identification) Partition Tables, or GPT, intended to replace the DOS/MBR partition tables."

I have been trying to UEFI (Unified Electronic Firmware Interface) with Puppy. In the process. I did learn something about a GPT disk (required by UEFI). The older BIOS used for hard disks, the hard disk geometry (cylinders and heads) approach with sectors of 512 bytes in the partition table. The newer GPT approach uses sectors of 4096 bytes (8 times the old 512 byte sector). Additionally, all GPT partitions must end on a 1 Megabyte boundary. This can be a source of problems (unused or mapped sectors) with a mix of file system and partitions. This sounds like the source of the problem.

Puppy maybe mounting the disk with partition table information and not the GPT information. I have a similar ASUS EeePc with XP. I do know the disk is partition with a GPT approach. However, it is much smaller than yours.

Unfortunately, like Flash, I have never done any kernel work. I do not have a clue on what needs to be done. But, maybe the experts can use this.

Looks like Pemasu and I will composing posts at the same time and he won!_________________Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

Without knowing too much about EFI partitions (I gave away keeping up with computer hardware long ago - no time!), I was under the impression a GPT was not essential to define a disk of this size...

Whether a disk is bootable or not, the MBR (first track, first sector) contains data about the geometry of the disk. Of course, much of it is no longer physical, it is logical (CHS : tracks, heads...) but some of it does relate to the real device (sector size, cluster size...).

So, in this 'table', one of the entries is 'bytes per sector' (a word at 0B). It always used to contain 512 (00 02), but for the 3TB disk I refer to it contains 4096 (00 10).

Does the linux kernel not use this information? Does it really need to refer to a GPT to get the size of a disk right?

Summary: Once a remote prospect, an important barrier in disk storage has become a reality: the venerable master boot record (MBR) partitioning scheme can't fully handle disks larger than 2.2TB (2TiB). With disks as large as 3TB readily available and with much larger RAID arrays common, alternatives to the MBR partitioning scheme have become important to understand. The heir apparent is the GUID Partition Table (GPT). Learn how to make sure your Linux system is fully prepared for the future of disk storage.

Quote:

Three main classes of software all require GPT support: the kernel, the boot loader, and low-level disk utilities

Without knowing too much about EFI partitions (I gave away keeping up with computer hardware long ago - no time!), I was under the impression a GPT was not essential to define a disk of this size...

Unfortunately, it is. MBR (also known as msdos disklabel) is limited to define a disk up to 2 TiB. Anything bigger would require GPT. It won't do to split your 3TB disk into 2TB + 1TB partition too - the limit isn't per-partition, it is for the entire disk. Afterall MBR definition encompasses the entire disk.

GPT has absolutely nothing to do with EFI (though the name of kernel config option, as pemasu has found out above, may mislead you). The only relationship is this: EFI/UEFI is capable of booting from GPT partition, BIOS does not, though there are some hacks around this.

Quote:

Whether a disk is bootable or not, the MBR (first track, first sector) contains data about the geometry of the disk. Of course, much of it is no longer physical, it is logical (CHS : tracks, heads...) but some of it does relate to the real device (sector size, cluster size...).

Correct. When you use GPT, you no longer use MBR to define the geometry of the disk. GPT replaces MBR, it does not live within the confines MBR.

Quote:

So, in this 'table', one of the entries is 'bytes per sector' (a word at 0B). It always used to contain 512 (00 02), but for the 3TB disk I refer to it contains 4096 (00 10).

It used to work like that, but suffice to say that the field is ignored for harddisk. It's a long story and I won't bore you here.

Quote:

Does the linux kernel not use this information?

No.

Quote:

Does it really need to refer to a GPT to get the size of a disk right?

Back in those days (a year ago), I only had one disk of this size, but now I have several. Back then not being able to use Puppy to get to this disk was not such an issue - I would just have to dual-boot to windoze.

However, it has since become somewhat more of an issue, since I now have several drives of this size (and larger). From my understanding a newer kernel is required than the one I have : I am still using Puppy Wary 0.5, and still using it on my Eee. It works, and it works damn well too. Unlike several refreshes of windoze that have been required to keep it running at the original speed, Puppy has had none of these issues, and works as well as the day I first loaded it!

So, is there something in the kernel that I can 'modprobe' to remove/replace/load the required driver/s to allow access to GPT disks? Even though a year has passed, I am still no further along the path to creating my own Puppy or compiling the kernel from scratch to make a Puppy to suit my Eee.

Why not just upgrade to the latest version of Wary? You could burn it to a CD (with Puppy's Burniso2cd), boot that CD with the puppy pfix=ram boot option, then see if it can access your 3TB hard disk drives. If it can, then you go ahead and upgrade (backing up your old version first, in case things go worng.)

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum