native mnttool does not show my boot partition

[nick65go]

I use a HHD drive, not USB stick; (but the problem is the same with any of my fresh partitioned
EXT2/EXT4 USB pendrives, I used fdisk -H 32 -S 32);

TC native mnttool, either from control panel, or started from wbar icon, does not show my boot partition, but shows all others; this is not specific to TC3.3 was here from TC2.x, I think; It is not a big problem, as I can run the an aterm command successfully (even not as root)

mount /dev/sda1

mount | grep sda1 shows
/dev/sda11 on /mnt/sda11 type ext2 (rw,relatime,barrier=1,data=writeback)
/dev/sda1 on /mnt/sda1 type ext2 (rw,relatime,barrier=1,data=writeback)

sda1 is my EXT2 boot partition
sda11 is my EXT4 tinycore partition for TCZ extensions (formated with out journal)

Even after close/restart mnttool it will not ever show sda1 partition; but /mnt/sda1 is working in any command line or explorer like fluff.

Please advise if is bug or design wish, Thank you.

[tinypoodle]

I had made the same observation here with a FAT32 partition on /dev/sda1 on a USB hdd.
However, with a pendrive it works here.

[ixbrian]

This is a bug in /usr/bin/mountables.sh that occurs any time you have more than 10 partitions on a single disk.   If you change the "!~" to a "!=" in this script, it fixes the bug.   The problem is it is doing a comparison by regular expression (!~), and sda1 matches the sda11 expression, so sda1 is not included.  Changing it to != does a direct comparison so that sda1 will not match sda11. 

Brian

[tinypoodle]

Thanks a lot ixbrian, I had always wondered about that.
I guess this is a bug which can very easily slip through, as it would only show with a disk with more than 9 (plus 1 extended) partitions.
At first I was afraid something could be wrong with either the partition or the partition table, but thoriugh checking showed everything was ok, so I didn't really bother about the minor inconvenience with mount tool any longer.

[nick65go]

thanks ixbrian, but after I corrected the script, from aterm inside TC with
sudo editor /usr/bin/montables.sh
still problem NOT solved; because the script /usr/bin/montables.sh

#!/bin/sh
cat /etc/fstab | awk -F '/' '/\/mnt\// {print $3}' | awk '{ sub(/[ \t]+$/, ""); print }' | sort -r | awk 'a != $0; { a = $0 }' | sort > /tmp/mountables

just read the /etc/fstab and write correct file /tmp/montables, so mnttool can detect sda1
But in fluff exporer will never be mounted; also in mnttool sda1 stay on green  always now, so it is just cosmetic show on sda1 in list of mnttool;

Anyway, you did the first step in right direction; now the bug is inside TC mnttool? or the way fstab is created?
regards, Nick

[ixbrian]

thanks ixbrian, but after I corrected the script, from aterm inside TC with
sudo editor /usr/bin/montables.sh

still problem NOT solved; because the script /usr/bin/montables.sh
#!/bin/sh
cat /etc/fstab | awk -F '/' '/\/mnt\// {print $3}' | awk '{ sub(/[ \t]+$/, ""); print }' | sort -r | awk 'a != $0; { a = $0 }' | sort > /tmp/mountables
just read the /etc/fstab and write correct file /tmp/montables, so mnttool can detect sda1
But in fluff exporer will never be mounted; also in mnttool sda1 stay on green  always now, so it is just cosmetic show on sda1 in list of mnttool;

Can you manually umount sda1 from the command line (umount /mnt/sda1)?   I'm guessing that sda1 is in use so you will not be able to unmount it.   If this is the case, it explains why you are seeing sda1 staying green in mnttool (mnttool can only unmount a filesystem if it is not in use)  

Brian

[nick65go]

I run this 3 commnds:
mount /dev/sda1 #fluff can access sda1, then close fluff
umont /dev/sda1 #fluff can not access sda1, then close fluff
umont /dev/sda1 #error msg in console, ofcourse, check with control panel, sda1 not mounted

now, mnttool shows sda1 on green, forever, but sda1 is not mounted, is not accessible even i togle on/off from mnttool, no change;

[tinypoodle]

What if you close mount tool and then open it again?

[ixbrian]

I run this 3 commnds:
mount /dev/sda1 #fluff can access sda1, then close fluff
umont /dev/sda1 #fluff can not access sda1, then close fluff
umont /dev/sda1 #error msg in console, ofcourse, check with control panel, sda1 not mounted

now, mnttool shows sda1 on green, forever, but sda1 is not mounted, is not accessible even i togle on/off from mnttool, no change;

I see what you're saying.   I was able to reproduce this on my system.  Here is a patch for mnttool.fl that will fix this.  

This change has mnttool run "grep '/mnt/sda1 ' /etc/mtab" instead of  "grep /mnt/sda1 /etc/mtab" to detect if a filesystem is mounted.   This prevents grep from returning a match when it finds sda10 when it is checking sda1.

Code: [Select]

--- mnttool.fl_orig
+++ mnttool.fl_updated
@@ -40,8 +40,8 @@
 
 ifstream fin("/tmp/mountables");
 string line;
-string commandHead = "grep /mnt/";
-string commandTail = " /etc/mtab >/dev/null";
+string commandHead = "grep '/mnt/";
+string commandTail = " ' /etc/mtab >/dev/null";
 
 while ( getline(fin,line) )
 {


[nick65go]

mount tool is close; command in a aterm only
mount /dev/sda1
ls /mnt/sda1 #ok, it work
umont /dev/sda1
ls /mnt/sda1 #empty, so sda1 unmount
umont /dev/sda1 # invalid argument, confirm sda1 unmount
mntools # start from atrem, invalid argument, confirm sda1 unmount, but is on green ever

PS: hi ixbrian, you replay too quickly; so I wait for new version to be compiled as I had not installed FLK kit
initial in /etc/mtab was not sda1; after mount /dev/sda1 now mnttool is working great red/green and fluff confirms it;
So now all reduce to have /etc/mtab file correct populated;
IF I run manualy umont /mnt/sda1, then /etc/mtab is depopulated and again mnttool wil not work;
THANK YOU

[roberts]

I have never needed such or even thought of such but I guess with terabyte drives comes 10 or more partitions on a single drive. I cannot keep up with such new hardware. Glad someone, Brian, has such hardware. Patch applied. Thanks.

[tinypoodle]

I have never needed such or even thought of such but I guess with terabyte drives comes 10 or more partitions on a single drive. I cannot keep up with such new hardware. Glad someone, Brian, has such hardware. Patch applied. Thanks.

Hmm, that made me remember when several years ago I had hit a non standard limit of libpata (or was it libata) of only max. 15 partitions which violates standards. Not having a clue it took me quite a while to find out why the last few partitions were not accessible under Linux, when the disk had been partitioned under DOS without any problem.
That was a 80GB USB hdd with about 17 partitions.
Different users, different habits and ways of use