partman doesn't like new HFSX partitions

[Fabio Massimo Di Nitto]

Hi Colin,

there is a problem with partman (i think) on ppc, where the manual partitioning
cannot see the disk layout when
there is a HFSX partition with CaseSentitive property enabled (journal makes no
difference). parted in background
works fine, so we think that partman gets confused somehow.

Here is a irc talk with Ben:

benh> ok, can you report that up ?
fabbione> ok.. if you can get to install and reboot.. the logs will be saved in
/var/log/debian-installer or installer
fabbione> sure
benh> when parted is launched on a disk formatted with that newer OS X
fabbione> please i want that so we can fix it
benh> it displays "Error: The partition's data region doesn't occupy the entire
partition"
benh> Ignore/Cancel
fabbione> did you use HFS+ with that Casesensitive option?
benh> I think that's what is confusing the frontend
benh> yes
fabbione> option -> property
fabbione> yes i can even reproduce it here
benh> I created an HFSX case sensitive, no journal
benh> I think that's what is confusing parted
fabbione> journal makes no difference in that case
fabbione> yes
benh> anyway, I think that message is causing the front end to go bonk
benh> I'll try to get the logs after the install
benh> brb (installing)
fabbione> cool thanks

[Benjamin Herrenschmidt (benh-kernel)]

Just for completeness, I can't be 100% sure that it's because I used that HFX
partition format that OS X created partitions that make parted spew this error
message, but I _suppose_ that the error message is what causes the front-end to
go bonk. I'll try to get the install logs in case they are useful later.

It's also interesting to note that when using such an HFSX format, OS X creates
a bootstrap partition of its own with its bootloader in it (because I suppose OF
doesn't grok HFSX).

[Colin Watson (cjwatson)]

Is this the Breezy partitioner? If so, Breezy's parted is known not to support
HFSX (or journalled HFS+), because it predates those patches going in; you have
to use Dapper.

[dcode (de-c0d3)]

I recently installed Tiger, then installed Dapper (20060308). This bug is still present. Tiger is installed on HFSPlus w/ case-sensitive (HFSX?). From installer console, parted doesn't recognize the partition map, but mac-fdisk does. I can partition with mac-fdisk and bypass the partitioner in expert mode by mounting the root filesystem from a console.

[Benjamin Herrenschmidt (benh-kernel)]

What happens if you use parted manually ? Do you see a similar error as I copied above ?

[VinceLe (legoll)]

I was trying to install 6.06 beta 2 after a tiger installation from scratch, on my G4 mac mini, stock 80Go drive,but the setup's graphical partitionner didn't grok the partition table, it was created like that:

(parted) unit s
(parted) print
Error: The partition's data region doesn't occupy the entire partition.
Ignore/Cancel? i
Disk geometry for /dev/hda: 0s - 156301487s
Disk label type: mac
Number Start End Size File system Name Flags
1 1s 63s 63s Apple
3 122880008s 123142151s 262144s hfs+ eXternal booter
4 123142152s 156301471s 33159320s hfsx Apple_HFSX_Untitled_1

whereas fdisk -l /dev/hda showed:

ubuntu@ubuntu:~$ sudo fdisk -l /dev/hda
/dev/hda
        # type name length base ( size ) system
/dev/hda1 Apple_partition_map Apple 63 @ 1 ( 31.5k) Partition map
/dev/hda2 Apple_Free 122879944 @ 64 ( 58.6G) Free space
/dev/hda3 Apple_Boot eXternal booter 262144 @ 122880008 (128.0M) Unknown
/dev/hda4 Apple_HFSX Apple_HFSX_Untitled_1 33159320 @ 123142152 ( 15.8G) Unknown
/dev/hda5 Apple_Free 16 @ 156301472 ( 8.0k) Free space

Block size=512, Number of Blocks=156301488
DeviceType=0x0, DeviceId=0x0

And yes, the HFSX partition was created with case-sensitive option.

I manually created a new primary partition:

(parted) mkpart primary =64s =122880007s
Error: The partition's data region doesn't occupy the entire partition.
Ignore/Cancel? i
Partition type? [primary]?
File system type? [ext2]?
Start? 64
End? 122880007
(parted) print
Disk geometry for /dev/hda: 0s - 156301487s
Disk label type: mac
Number Start End Size File system Name Flags
1 1s 63s 63s Apple
2 64s 122880007s 122879944s untitled
3 122880008s 123142151s 262144s hfs+ eXternal booter
4 123142152s 156301471s 33159320s hfsx Apple_HFSX_Untitled_1

Then I get the right display in the GUI setup, at the "Prepare disk space" wizard page, with the 3 options:
"erase entire disk", "use largest partition" or "manually edit"

I chose the "manually edit" one and get to the "prepare partition" page with all partitions showing up, two tiger unknown and one hfs+, and my newly created one, unknown type too.

I then click forward button, and get to "prepare mount points" page, where the right hda2 (the new one) was already selected for / the reformat check box was checked, as this partition never was mke2fs'ed...

Then I click the forward button, the window telling "starting the partitionner" shows up for a few seconds, and then I get a python backtrace from the installer:

Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line 1061, in watch_debconf_fd_helper
    return callback(source, debconf_condition)
  File "/usr/lib/python2.4/site-packages/ubiquity/filteredcommand.py", line 141, in process_input
 ...

[VinceLe (legoll)]

Confirmed with 6.06 beta 2

[VinceLe (legoll)]

I'm sending this comment, while 6.06 release is installing in the backgroung, my setup was the same as previously stated, but this time the partitionner seems to have correctly mke2fs'ed the partition. There was a warning about the partition table, that I quickly ignored...

Will update after the first boot attempt...

[VinceLe (legoll)]

Argh, I think I shouldn't have ignored the partition table warning. The installer crashed at the end, with the following python backtrace:

Traceback (most recent call last):
  File "/usr/bin/ubiquity", line 130, in ?
    install(sys.argv[1])
  File "/usr/bin/ubiquity", line 55, in install
    ret = wizard.run()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line 266, in run
    self.process_step()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line 741, in process_step
    self.mountpoints_to_summary()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line 1029, in mountpoints_to_summary
    self.progress_loop()
  File "/usr/lib/python2.4/site-packages/ubiquity/frontend/gtkui.py", line 538, in progress_loop
    raise RuntimeError, ("Install failed with exit code %s; see "
RuntimeError: Install failed with exit code 1; see /var/log/installer/syslog and /var/log/syslog

With the end of /var/log/installer/syslog being, just before the same python backtrace:

[...]
0 upgraded, 0 newly installed, 0 to remove and 108 not upgraded.
Mon, 26 Jun 2006 21:31:10 INFO switched to page stepPartDisk
ubiquity: ['/usr/lib/ubiquity/yaboot-installer/yaboot-installer', '/target'] exited with code 1
Mon, 26 Jun 2006 21:31:10 INFO umount -f /target/proc
Mon, 26 Jun 2006 21:31:11 INFO umount -f /target/dev
ubiquity: ['/usr/share/ubiquity/install.py'] exited with code 1

And /var/log/syslog being empty...

Rebooting anyway...

[rusivi2 (rusivi2-deactivatedaccount)]

Thank you for posting this bug.

Dapper is in End of Life status. Please update and repost detailed error report.

[Launchpad Janitor (janitor)]

[Expired for parted (Ubuntu) because there has been no activity for 60 days.]