[conspire] GNU parted *won't* create an ext3 file system - argh!
freepalestin at dslextreme.com
Fri Apr 2 11:37:04 PDT 2010
On Fri, Apr 2, 2010 at 12:37 AM, Rick Moen <rick at linuxmafia.com> wrote:
> Quoting Darlene Wallach (freepalestin at dslextreme.com):
>> I finally realized that when I thought I had successfully created an
>> ext3 file system on partition 1 - no file system had been created -
> I hope you realise that _partitioning_ utilities are basically to create
> and edit partition tables. That includes allocating space in the
> partition table for where partitions will later be. Once you're done
> creating the partition table and allocating space, you close / leave the
> partitioning table. As a second, separate step, you mkfs the actual
> partitions, using entirely different, _formatting_ AKA mkfs software,
> such as mkfs.ext3.
I used GNU parted:
parted) mklabel gpt
parted) mkpart primary ext3 0 960GB
parted) mkpart primary ext3 960GB 1000GB
When I printed /dev/sdb the filesytem was blank. There was no
filesystem. So since I had successfully made the gpt partition table,
I should have quit GNU parted and just used mkfs.ext3 to make the ext3
filesystem. If I want to try it again are these the steps that should
do I want using GNU parted and mkfs.ext3:
1. GNU parted /dev/sdb
2. mkfs.ext3 -c -c -L <LabelFor-sdb1> /dev/sdb1 # if I want the slower
checks for bad blocks
mkfs.ext3 -c -L <LabelFor-sdb1> /dev/sdb1 # if I want the faster
checks for bad blocks
mkfs.ext3 -L <LabelFor-sdb1> /dev/sdb1 # if I don't want to check
for bad blocks
That should do it?
> So, for example, here are the details of a partition table I posted
> # fdisk -l
> Disk /dev/sda: 80.0 GB, 80000000000 bytes
> 255 heads, 63 sectors/track, 9726 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
> Disk identifier: 0xbb59bb59
> Device Boot Start End Blocks Id System
> /dev/sda1 * 1 1216 9767488+ 83 Linux
> /dev/sda2 1217 1459 1951897+ 82 Linux swap / Solaris
> /dev/sda3 1460 8510 56637157+ 83 Linux
> /dev/sda4 8511 9726 9767520 5 Extended
> /dev/sda5 8511 9726 9767488+ 83 Linux
> I created that system's partition table using /sbin/fdisk. That
> includes the ~9GB /dev/sda1. It's important to realise that, when I
> finished defining that filesystem's partition table description in
> /sbin/fdisk, there still _wasn't any such partition_, i.e., no
> data-bearing filesystem capable of being mounted and storing files yet
> existed, because I hadn't yet run mkfs.ext3 to create it, let alone
> mounted it to make it usable.
> You would seek to use GNU parted (_or_ any other partitioning utility)
> to lay out the partition table. Then, you leave the partitioning
> utility and mkfs the space thus allocated. Then, you mount the
> partitions (and, if desired, edit /etc/fstab to ensure that the
> partitions are easier to mount in the future, and if you wish to ensure
> that they are automounted at startup time).
> GNU parted, and the various other partitioning applications designed to
> work using libparted, offers as a nicety the ability to run the mkfs
> step from _inside_ the partitioning utility -- except that GNU parted
> so far is limited in that area concerning ext3-type partitions.
>> Looks like I can't use GNU parted for my Seagate FreeAgent Go 1T
> I'm not at all sure that is the case. Please note that you didn't
> bother to say what precisely you tried that didn't work -- so it's not
> possible to intelligently comment on what GNU parted can and cannot do
> based on your experience.
> However, it just does not stand to reason that GNU parted cannot define
> partition table entries for ext3-type partitions. THere's really not
> that much to it! I mean, _look_ at the incredibly simple data in the
> /sbin/fdisk output quoted above. Notice that the only significant
> difference, in that output, between the /dev/sdb1 line and the /dev/sdb2
> one is that it's type 83 instead of type 82. That's really the
> sum-total difference between the partition-table data for an ext2/ext3
> partition on the one hand (type 83) and a Linux swap partition on the
> other hand (type 82).
>> cfdisk doesn't support GPT
> True, but what's the relevance?
> Darlene, I thought I covered this already. GPT is necesary only for
> drives with partitions over 4 TB in size. If you don't have at least
> one partition that large, then you haven't yet outgrown the capabilities
> of old-style IBM/Microsoft partition tables.
> Now, if for some reason you needed to _read_ (parse) an existing
> GPT-type partition table, that would be a compelling reason why you
> could not use /sbin/cfdisk or /sbin/fdisk. But that situation doesn't
> apply: You're blowing away the disk contents as your first step and
> then _creating_ (then editing) a partition table.
> So: You certainly can create and edit a GPT. Or you can create and
> edit an old-style IBM/Microsoft partition table.
> I don't want to sound as if I'm complaining, but I -did- say that at
> least a couple of times before in this discussion.
>> I guess I'm going back to gparted - argh! I would rather use a cli.
> I don't know of any reason to think there's anything wrong with GParted
> (other than the strategic consideration I described), but I think your
> reasoning is suspect.
> conspire mailing list
> conspire at linuxmafia.com
equal justice under law
More information about the conspire