Gparted bugfix

ext3 partition creation failure
In the Puppy 4.1beta feedback there was a report that Gparted failed to create a ext3 partition, but did succeed in creating a ext2 partition. I have confirmed this bug.

The problem is the content of /etc/mtab, that Gparted objects to, claiming that it was unable to determine whether the partition that is to be made into an ext3 f.s. is mounted or not. The content of /etc/mtab looked fine to me, however I do know how to fix this problem -- by not having an /etc/mtab file at all and instead just make it a symlink to /proc/mounts.

The "mtab problem" goes back to some fundamental mismatches, that probably in the long term will have to be solved. Firstly, Busybox is configured to not use /etc/mtab (for historical reasons, back when I did configure it to use mtab, thngs went very wrong) for its 'mount' and 'umount' applets.
Secondly, I configured 'ntfs-3g' not to use /etc/mtab, as I use the same binary in the initial ramdisk (which has the Busybox mount and umount).

However, the full 'mount' and 'umount' programs do use /etc/mtab, and also some utilities (such as 'eject' and 'mke2fs' reference /etc/mtab).

In Puppy, /bin/mount and /bin/umount are scripts, so I was able to juggle the above conflicts. My scripts write to /etc/mtab and everything seemed to work okay ...except now we have Gparted unhappy with what it is finding in /etc/mtab for some reason.

In the initrd /etc/mtab is a symlink to /proc/mounts, as this works for the various utilities (eject, mke2fs, etc.). I have now done this for the main Puppy filesystem.

To implement this, I have modified /etc/rc.d/rc.sysinit, /bin/mount and /bin/umount.

This is a small but fundamental change, that could have subtle or not-so-subtle ramifications. Or it might just fix the Gparted bug and have no other negative repercussions (I am inclined to this view). I am reluctant to make this kind of fundamental change at this stage, but it is necessary to fix the bug. I will do extensive testing before releasing the 4.1-release-candidate.

Slow startup
There is something else that we should do. Gparted can be very very slow to startup on some PCs that have a floppy drive interface on the motherboard but no actual floppy drive. Gparted does a scan at startup and gets stuck on the floppy probe, but does eventually timeout. What we need is a little wrapper, call it 'gpartedwrapper', that runs 'probedisk2' and puts up a little GUI that asks which drive you want to work on, then executes Gparted like this:
gparted /dev/sda
...which constrains the startup scan to only that drive.

---

Comments

GParted 0.3.9
Username: coolpup
May we have an upgrade to the latest version 0.3.9? Puppy 4.1beta still using GParted 0.3.3 released in 2006.

Gparted
Username: B
éèm"This occurred already in a couple of earlier versions. If I remember well the detail msg said: mkfs.ext3 not found. I then formatted in ext2

Tags: puppy