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.
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:
...which constrains the startup scan to only that drive.
Would anyone like to whip up such a little GUI?
Comments:Posted on 21 Sep 2008, 5:04 by 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.
Posted on 23 Sep 2008, 18:28 by 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
Posted on 23 Sep 2008, 19:02 by vattimo
Gparted - faster startup
No idea if this will help anyone, but for me Gparted will start up faster if you access it by beginning to install Puppy to a USB flash drive (universal installer) - use Gparted, then cancel the install. BTW, I downloaded/tested Gparted as a rescue live-cd, and it did the same delay. My system is a Compaq N400C and has no HD, and no Floppy -- Yay Puppy!!!! Hope this helps and Good Luck to all !!!