Written by nandayo the 14 Apr 09 at 16:24.

This should be really more logical ! Ext3 filesystem into one color, swap into another color, NTFS into another one, and so on ! (as GParted do finaly !) This would be really more visual and a more intelligent use of colors. Of course, each partition must be clearly delimited, to avoid consecutive partitions of the same filesystem to be few visible.

Here is an (ugly :-p ) example I made to illustrate :
http://img209.imageshack.us/my.php?image=56626046.png
(this is just an *ILLUSTRATION*, not a graphical proposition ! )

Maybe another suggestion : note by a symbol (a star for example) the partition containing an OS.

This should be really more logical ! Ext3 filesystem into one color, swap into another color, NTFS into another one, and so on ! (as GParted do finaly !) This would be really more visual and a more intelligent use of colors. Of course, each partition must be clearly delimited, to avoid consecutive partitions of the same filesystem to be few visible. Here is an (ugly :-p ) example I made to illustrate : http://img209.imageshack.us/my.php?image=56626046.png (this is just an *ILLUSTRATION*, not a graphical proposition ! ) Maybe another suggestion : note by a symbol (a star for example) the partition containing an OS.

Written by nandayo the 14 Apr 09 at 16:27.

This probably made a lot of user to loose their previous OS and data ! I suggest a more intelligent partitioning, which keep alive existing OS *and* other existing data partitions.

This probably made a lot of user to loose their previous OS and data ! I suggest a more intelligent partitioning, which keep alive existing OS *and* other existing data partitions.

Written by nandayo the 14 Apr 09 at 16:32.

Just some smart tooltip, or a "watizit ?", to let new users to understand what the partitioning tool is asking about mounting point.

Just some smart tooltip, or a "watizit ?", to let new users to understand what the partitioning tool is asking about mounting point.

Written by Clorox the 15 Apr 09 at 02:36.

Shouldn't be hard. It is much more advanced and should fit in the installer.

Shouldn't be hard. It is much more advanced and should fit in the installer.

Written by Kver the 19 Apr 09 at 06:02.

Make the colour bar a prominent tool instead of only a display.

- Use icons to help identify the partitions, such as a windows logo on detected windows installations, an Ubuntu logo for Ubuntu installs, and other icons for common types of partitions.
- Allow users to drag/stretch/squish partitions on the bar itself. Ie; squish a windows partition. Back or transparency could be used for empty space.
- Do NOT make it one colour/one filesystem type. If you have multiple partitions of the same type, it might appear as a single colour slab. Using alternating shades could correct this problem (dark/light/dark/light)
- Explain a partition on mouseover in a box underneath the bar.

Make the colour bar a prominent tool instead of only a display. - Use icons to help identify the partitions, such as a windows logo on detected windows installations, an Ubuntu logo for Ubuntu installs, and other icons for common types of partitions. - Allow users to drag/stretch/squish partitions on the bar itself. Ie; squish a windows partition. Back or transparency could be used for empty space. - Do NOT make it one colour/one filesystem type. If you have multiple partitions of the same type, it might appear as a single colour slab. Using alternating shades could correct this problem (dark/light/dark/light) - Explain a partition on mouseover in a box underneath the bar.

Written by Kver the 19 Apr 09 at 06:19.

A dropdown could be placed with several options, the selected being what it will do. Or more radio buttons could be added. These would be "smart" based on what is on the hard-drive(s), and which options would lose the least data.

Options could include:
- replacing the dominant partition (the single, largest partition will be deleted)
- shrinking all partitions (except swap) (it will try to scale by %)
- Wiping all small partitions (except swap) (keeping the largest partition and the swap, deleting all smaller partitions for space)
- Format * partition (* being a dropdown with any non-swap parition greater than 4.9gb)
- formatting (no explanation here)
- Manual

Tt would recommend a scheme based on the following, and would not show the option if the requirement isn't met:
#1 - Shrink partitions. If every partition (including Ubuntu) would have 10% of the HD's overall capacity as free space, recommend this option. Ie a 100gb hard drive would require 10gb of free space on each non-swap partition after the shrink.
#2 - Wipe small partitions. Use this option if the largest partition is at least 50% larger than non-swap partitions combined. If not, check #3.
#3 - Wipe the largest partition. Recommend this only if less than 20% of the partition is in use. Otherwise, recommend #4.

A dropdown could be placed with several options, the selected being what it will do. Or more radio buttons could be added. These would be "smart" based on what is on the hard-drive(s), and which options would lose the least data. Options could include: - replacing the dominant partition (the single, largest partition will be deleted) - shrinking all partitions (except swap) (it will try to scale by %) - Wiping all small partitions (except swap) (keeping the largest partition and the swap, deleting all smaller partitions for space) - Format * partition (* being a dropdown with any non-swap parition greater than 4.9gb) - formatting (no explanation here) - Manual Tt would recommend a scheme based on the following, and would not show the option if the requirement isn't met: #1 - Shrink partitions. If every partition (including Ubuntu) would have 10% of the HD's overall capacity as free space, recommend this option. Ie a 100gb hard drive would require 10gb of free space on each non-swap partition after the shrink. #2 - Wipe small partitions. Use this option if the largest partition is at least 50% larger than non-swap partitions combined. If not, check #3. #3 - Wipe the largest partition. Recommend this only if less than 20% of the partition is in use. Otherwise, recommend #4. #4 - Format. Always shown. #5 - Format * partition. Always shown. #5 - Manual. Never recommended, always shown, as serious damage can be done by a new user.

Written by aadityabhatia the 3 May 09 at 21:17.

Display some information about different directories and their purpose, such as:

/home Contains the home directories (personal storage) for each user on the system
/usr Contains system programs and other files for general users such as games, online help, and documentation
/tmp Contains temporary files that are erased upon reboot
/etc Contains configuration files for Linux and other installed software
/bin Contains the Linux system commands and programs (also called binaries)
/var Contains variable data that changes constantly when the system is running
... and so on.

This will help a basic user understand the system better by knowing the purpose of each directory. It is difficult to make changes once the system has been installed. Therefore the user will be able to make an informed one-time decision about allocating partitions to different directories.

Display some information about different directories and their purpose, such as: /home Contains the home directories (personal storage) for each user on the system /usr Contains system programs and other files for general users such as games, online help, and documentation /tmp Contains temporary files that are erased upon reboot /etc Contains configuration files for Linux and other installed software /bin Contains the Linux system commands and programs (also called binaries) /var Contains variable data that changes constantly when the system is running ... and so on. This will help a basic user understand the system better by knowing the purpose of each directory. It is difficult to make changes once the system has been installed. Therefore the user will be able to make an informed one-time decision about allocating partitions to different directories.

Written by delphiexile the 5 May 09 at 12:07.

As said in the title ; GParted is powerful tool , it just lacks simplicity for new comers to UBUNTU, we should keep it but simplify it.
ex:
1- Simplify the meaning of mount point
2- Simplify the error messages for public understanding.
... & more if you have !!

As said in the title ; GParted is powerful tool , it just lacks simplicity for new comers to UBUNTU, we should keep it but simplify it. ex: 1- Simplify the meaning of mount point 2- Simplify the error messages for public understanding. ... & more if you have !!

Written by danbhfive the 9 May 09 at 21:57.

Gparted is on the livecd anyway. Why not have it be an option? IE, there would be two "manually partition" options. One, for the current, low memory partitioner, and one for GParted.

This is how I remember it being done on Redhat, some ten years ago. Then, the options were autopartition, manually partition with the graphical partitioner, or manually partition with fdisk (yuk).

(Personally, I fire up GParted to partition before I do an install anyway. Like the original poster, I find the new partitioner too confusing.)

Gparted is on the livecd anyway. Why not have it be an option? IE, there would be two "manually partition" options. One, for the current, low memory partitioner, and one for GParted. This is how I remember it being done on Redhat, some ten years ago. Then, the options were autopartition, manually partition with the graphical partitioner, or manually partition with fdisk (yuk). (Personally, I fire up GParted to partition before I do an install anyway. Like the original poster, I find the new partitioner too confusing.)

Written by tuxxy the 13 May 09 at 01:53.

New users may not understand a separate /home partition fully, an idea is to illustrate to them the future benefits that it will bring to them such as updating and personal data reliability.

New users may not understand a separate /home partition fully, an idea is to illustrate to them the future benefits that it will bring to them such as updating and personal data reliability.

Written by gianni_casagrande the 30 Aug 09 at 08:04.

The partitioning process could be made simpler by adding a simplified option for Manual partitioning where a user can create custom partitions without needing to worry about mount points, filesystems etc.
The installation program will take care of making reasonable choices on mount points and fylesistems and creating a swap partition of resonable size.
There could be an option to create a separate /home partition with explained benefits and costs.

The installation program should advise simplified mode for manual partitioning to user that want to customize partition sizes but are not familiar with terms such as 'ext3' or 'swap partition'(like me for example).

The partitioning process could be made simpler by adding a simplified option for Manual partitioning where a user can create custom partitions without needing to worry about mount points, filesystems etc. The installation program will take care of making reasonable choices on mount points and fylesistems and creating a swap partition of resonable size. There could be an option to create a separate /home partition with explained benefits and costs. The installation program should advise simplified mode for manual partitioning to user that want to customize partition sizes but are not familiar with terms such as 'ext3' or 'swap partition'(like me for example).

Written by elias1884 the 29 Sep 09 at 22:06.

Add LVM and RAID Support to the application. Also these technologies should be supported in the LiveCD installer.

Add LVM and RAID Support to the application. Also these technologies should be supported in the LiveCD installer.

Written by waster the 2 Oct 09 at 07:48.

With >1 disk, the partitioner could do a quick benchmark to see what latency and throughput are, especially for SSD hardware. It could then say for example:

Mirror root across two fast disks
Put /tmp on a RAID0 array
Set up a video/music media mount point to get most capacity out of slower disks, not worrying about latency.
etc, etc.

You could even toggle how much data security you want vs speed, so a new user could benefit from RAID0 speed, RAID1, RAID5 etc securtity without knowing the details underneath.

Needless to say, LVM should be on top of all this, and the chunk/stripe size alignment should be set up automatically (currently this is only optimal by chance - beware!) and the readahead for LVM should have a much better default.

With >1 disk, the partitioner could do a quick benchmark to see what latency and throughput are, especially for SSD hardware. It could then say for example: Mirror root across two fast disks Put /tmp on a RAID0 array Set up a video/music media mount point to get most capacity out of slower disks, not worrying about latency. etc, etc. You could even toggle how much data security you want vs speed, so a new user could benefit from RAID0 speed, RAID1, RAID5 etc securtity without knowing the details underneath. Needless to say, LVM should be on top of all this, and the chunk/stripe size alignment should be set up automatically (currently this is only optimal by chance - beware!) and the readahead for LVM should have a much better default.

Written by rbsfou the 16 Apr 09 at 07:50.

The user's OSX HFS Partition needs to be identified and mounted read-only at install time. It then needs to be entered into the fstab of the installed system (read/write) - HFS filesystems do have UUID's.

If it's not published under the APSL, plutil needs to be reverse-engineered to allow reading the PLIST files in XML format from their ~/Library/ directory.

Work needs to be done to map settings in com.apple.* files to gconf values.

Either the user's account needs to be created with the same numerical UID and GID as their OSX account (this is something that troubles all unix-unix integration!), or an extra group created, containing the user, with the same numerical GID as on their HFS home folder.

Warning the user that they MUST disable journalling support (and telling them how to run diskutil from inside OSX to do so - no support for DISABLING journalling in "Diskutility.app").

And finally, leaving a symlink to the user's OSX home-folder on their Ubuntu desktop.

The user's OSX HFS Partition needs to be identified and mounted read-only at install time. It then needs to be entered into the fstab of the installed system (read/write) - HFS filesystems do have UUID's. If it's not published under the APSL, plutil needs to be reverse-engineered to allow reading the PLIST files in XML format from their ~/Library/ directory. Work needs to be done to map settings in com.apple.* files to gconf values. Either the user's account needs to be created with the same numerical UID and GID as their OSX account (this is something that troubles all unix-unix integration!), or an extra group created, containing the user, with the same numerical GID as on their HFS home folder. Warning the user that they MUST disable journalling support (and telling them how to run diskutil from inside OSX to do so - no support for DISABLING journalling in "Diskutility.app"). And finally, leaving a symlink to the user's OSX home-folder on their Ubuntu desktop.

Written by ziroday the 16 Apr 09 at 11:03.

Ubiquity (the graphical livecd installer) already has support for migrating many windows settings over to ubuntu. This feature should be extended for OS X users.

Ubiquity (the graphical livecd installer) already has support for migrating many windows settings over to ubuntu. This feature should be extended for OS X users.

Written by rbsfou the 18 Apr 09 at 18:18.

OK, i'm going to describe this better:

--> For Importing data:

a) The user's OSX HFS Partition needs to be identified and mounted read-only at install time.

b) If it's not published under the APSL, "plutil" needs to be reverse-engineered to allow reading the PLIST files in XML format from their ~/Library/ directory.

c) Work needs to be done to map settings in com.apple.* files to gconf values.

--> For Providing Write Support to the user's OSX home folder: (Optional!)

a) Either the user's account needs to be created with the same numerical UID and GID as their OSX account (this is something that troubles all unix-unix integration!), or an extra group created, containing the user, with the same numerical GID as on their HFS home folder.

b) Warning the user that they MUST disable journalling support (and telling them how to run diskutil from inside OSX to do so - no support for DISABLING journalling in "Diskutility.app") - IF they want write support, and ONLY until this is fixed upstream

OK, i'm going to describe this better: --> For Importing data: a) The user's OSX HFS Partition needs to be identified and mounted read-only at install time. b) If it's not published under the APSL, "plutil" needs to be reverse-engineered to allow reading the PLIST files in XML format from their ~/Library/ directory. c) Work needs to be done to map settings in com.apple.* files to gconf values. --> For Providing Write Support to the user's OSX home folder: (Optional!) a) Either the user's account needs to be created with the same numerical UID and GID as their OSX account (this is something that troubles all unix-unix integration!), or an extra group created, containing the user, with the same numerical GID as on their HFS home folder. b) Warning the user that they MUST disable journalling support (and telling them how to run diskutil from inside OSX to do so - no support for DISABLING journalling in "Diskutility.app") - IF they want write support, and ONLY until this is fixed upstream c) Entering the filesystem RW in the fstab, and installing hfsutils to allow automatic / manual fsck. Don't worry kids, the fsck IS from apple! d) And finally, leaving a symlink to the user's OSX home-folder on their Ubuntu desktop (If the user chooses to do so)