fstab mounting is borked in v5.25

[MikeF]

It appears that a regression to bad behavior has happened.

In 2009 someone reported (version unknown) that attempting to mount an NTFS partition resulted in an 'unknown option -n' error.

Relevant lines from my /etc/fstab are:

/dev/sda7 /temp ntfs ro 0 0
/dev/sr0 /cd auto ro,noauto 0 0

Also, the optical drive mount is a null action - nothing happens.
When I use pmount or the mount command line, everything works fine.

I went back to v5.11, fstab mounting works fine there.

TIA, Mike!

EDIT: sorry, I meant to append this to the v5.25 bug thread ...
EDIT2: Instant Update 001 is installed btw ...

[Karl Godt]

This is 511 , don't know anything about later Puppy5 :

ntfs[TABTAB]
ntfs-3g ntfscluster ntfsfix ntfsls ntfsundelete
ntfscat ntfscmp ntfsinfo ntfsmount
ntfsclone ntfscp ntfslabel ntfsresize

mount[TABTAB]
mount mount-FULL mount.ntfs-3g mount.aufs mount.ntfs-fuse
mount-BB-NOTUSED-DIRECTLY
mount.cifs

Q : Are the executables ---version the same ?
Q : Are the executables in the same directories ?
Q : I am guessing you use fstab for `mount -a` ?

[Bruce B]

MikeF,

ntfs-3g rather than ntfs might be what you want in fstab

mount is probably a script. open it and see if you can see where the odd -n option error is originating from and how it originates

Bruce

~

[Karl Godt]

from man mount :

-n Mount without writing in /etc/mtab. This is necessary for example when /etc is on a read-only file system.

busybox mount --help does not say anything about the -n option but seems to accept it .

Code: Select all

mount-FULL -n /dev/hdb4 /mnt/hdb4

writes still into /etc/mtab :

Code: Select all

cat /etc/mtab | tail -n 1

/dev/hdb4 /mnt/hdb4 ntfs rw,relatime,uid=0,gid=0,fmask=0177, dmask=077,nls=iso8859-1,errors=continue,mft_zone_multiplier=1 0 0

my fstab file is simply this :

Code: Select all

none          /proc        proc     defaults               0 0
none          /sys         sysfs    defaults               0 0
none          /dev/pts     devpts   gid=2,mode=620         0 0
/dev/fd0      /mnt/floppy  auto     noauto,rw              0 0

and I have had no problems until now mounting anything .

As far as I can see 525 seems to have additionally "ntfs-3g.probe" in /bin and "libntfs-3g.so" in /usr/lib and "libntfs-3g.so.75" , "libntfs-3g.so.75.0.0" in /lib

[Bruce B]

from man mount :

-n Mount without writing in /etc/mtab. This is necessary for example when /etc is on a read-only file system.

man mount doesn't apply to puppy's mount

my fstab file is simply this :

Code: Select all

none          /proc        proc     defaults               0 0
none          /sys         sysfs    defaults               0 0
none          /dev/pts     devpts   gid=2,mode=620         0 0
/dev/fd0      /mnt/floppy  auto     noauto,rw              0 0

and I have had no problems until now mounting anything .

The subject here is fstab mounting. You haven't filled in fstab or used it for mounting as far as I can see.

~

[MikeF]

MikeF,
ntfs-3g rather than ntfs might be what you want in fstab
mount is probably a script. open it and see if you can see where the odd -n option error is originating from and how it originates
Bruce
~

Tried ntfs-3g in fstab, same error.

Anyone else running 5.25 who can duplicate this symptom?

[Bruce B]

MikeF,
ntfs-3g rather than ntfs might be what you want in fstab
mount is probably a script. open it and see if you can see where the odd -n option error is originating from and how it originates
Bruce
~

Tried ntfs-3g in fstab, same error.

Anyone else running 5.25 who can duplicate this symptom?

Did you open the mount script?

~

[Bruce B]

In 2009 someone reported (version unknown) that attempting to mount an NTFS partition resulted in an 'unknown option -n' error.

This bug report is verified by me (Lupu 5.20)

The date on the mount script is 2009-11-19 as shown below. This corresponds with the date MikeF cites

root 5387 2009-11-19 09:03 mount

Probably most Puppy users don't use fstab. I suppose this is why it took long to be identified.

I worked around the problem by replacing the mount script with the mount binary

~

Attached to this post is a screen shot showing the bug. It is as reported in 2009 and as reported in this topic. The mount script was used in the test. If the mount binary is used, everything works as expected.

~

[MikeF]

Did you open the mount script?

Yes, but I'm not sure what I would learn since I'm not a Puppy internals expert. Just thinking about layered file systems almost makes my head explode.

It appears to call 'mount-FULL -n', not sure if that's the mount binary you were referring to.

Also the script does mention not working with fstab. Uh, oh.

Also noticed that NTFS R/W defaults corrupts the file system when files are written there, another uh-oh. Haven't had that happen on other distros recently.

I must partially retract some of my original report, v5.11 fstab didn't 'mount all' for my current login. Hmmm.

Unfortunately I'm not likely to use Puppy as intended until the script maintainer gets this sorted out (I hope I hope). TIA to all!

[Bruce B]

MikeF,

I'm not sure what you want. As far as a bug report, it's a done deal.

Do you want to work around the existing problem? Which of course means modifying things. We can do that. I did it.

Bruce

~

[Bruce B]

Also noticed that NTFS R/W defaults corrupts the file system when files are written there, another uh-oh. Haven't had that happen on other distros recently.

If true, I'd regard this as a very serious and high priority problem. Something to make a new bug report on.

Note: I'm not on the developers team anymore than you are.

~

[MikeF]

As far as formal bug reporting, I'm a little puzzled. Other that this forum, some other topic links to an external web site (Bugzilla?) that seems to be inactive or maybe just poorly organized.

I'm going to try to pin down the NTFS corruption a little more. One thing I've noticed is that different distros/versions have different defaults that show up when listing current mounts. Perhaps someone else has discovered some important default options that can be changed.

As far as a workaround, I'm think of just mounting r/o from rc.local or something.

[Bruce B]

MikeF,

Defaults are just that and not necessarily optimal.

When I install Puppy or any distro, one of the first things I do is fill in fstab. After which everything which fstab is designed for as a configuration file is optimized by me according to what I want.

From this perspective it doesn't matter what distro for me, they all work the same.

In Puppy, if you fill in fstab for all your mountable devices, then you don't need Puppy's mount utilities. ROX-Filer uses fstab and any or all of your favorite mount points can be dragged and dropped to the desktop.

Here is a simple list of what I am doing

1) fill in fstab completely
2) copy /bin/mount-FULL to /bin/mount (or symlink)

That's all there is to it.

Bruce

~

[MikeF]

MikeF,
Defaults are just that and not necessarily optimal.
When I install Puppy or any distro, one of the first things I do is fill in fstab. After which everything which fstab is designed for as a configuration file is optimized by me according to what I want.
From this perspective it doesn't matter what distro for me, they all work the same.
In Puppy, if you fill in fstab for all your mountable devices, then you don't need Puppy's mount utilities. ROX-Filer uses fstab and any or all of your favorite mount points can be dragged and dropped to the desktop.
Here is a simple list of what I am doing
1) fill in fstab completely
2) copy /bin/mount-FULL to /bin/mount (or symlink)
That's all there is to it.
Bruce
~

Hi Bruce, you're preaching to the choir
I too like to set up my defaults in fstab so I'll try the above suggestion 2.
Hopefully the mounting situation will be cleaned up eventually so we don't have to hack it.
BTW I just discovered that mount from the command line will not mount NTFS partitions r/o - it ignores that option and mounts them r/w anyway. Sigh.

[Karl Godt]

The Puppy mount script is 50% to act as a helper for the drive icons on desktop to show the mount icon maintained by "pup_event_frontend_d" , and 50% to split the mount commands into the various mount commands , that come with Puppy .

After mounting the ntfs partition using 'ntfsmount /dev/sda4 /mnt/sda4 -o ro'
I got me some strange messages :
"shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory"

but 'busybox mount' showed :
"/dev/sda4 on /mnt/sda4 type fuseblk (ro,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)"
so it was mounted ro , though .

I had added " echo '$@='"$@" " on top of the mount script and that showed , that ntfsmount calls /bin/mount regardless if it is a link to busybox or standard (-FULL) binary from coreutils or whatever :

$@ =-i -f -t fuseblk -o ro,nosuid,nodev,default_permissions,allow_other,blksize=4096,user=root /dev/sda4 /mnt/sda4

The mount script sources /etc/rc.d/functions4puppy4 , which uses the '/bin/df' -script , which uses 'df-FULL' in the 'icon_mounted_func' , which is written to determine the root partition by the device to be in line with various other scripts to be compliant with frugal installs and full installs ; which showed this message :
"df-FULL: `/mnt/sda4': Transport endpoint is not connected"

At the end I had a dozen 'df-FULL' running in the background and was only able to kill them by
`busybox ps | grep df-FULL | cut -f 1 -d ' ' | while read line ; do kill -9 $line ;done`

I have looked into the .sfs and it seems , that the df script had been accidentally replaced by df-FULL .
I might be wrong , because I haven't yet DL the official 5.2 and 5.25 but some .iso from the development threat in Puppy Projects .

I am on an older Puppy atm (430) , but wanted to add this .

And of course man mount works for Puppy mount , because it uses the mount command .

But perhaps the '-n' option only works on a regular file , and not to a link to /proc/mounts .

[Karl Godt]

Furthermost I want to add , that the mount script had not changed from pup430 to luci254 , which I think had been the third last release candidate for 525 .

[Bruce B]

And of course man mount works for Puppy mount , because it uses the mount command .

But perhaps the '-n' option only works on a regular file , and not to a link to /proc/mounts .

Puppy's mount command is a script and doesn't behave like the mount binary utility. In this particular case it passes the -n switch to ntfs-3g. The -n switch is an invalid parameter for ntfs-3g and you get the following error message.

In 2009 someone reported (version unknown) that attempting to mount an NTFS partition resulted in an 'unknown option -n' error.

If one replaces the script with the binary, no more error message and it works.

~

[Bruce B]

Furthermost I want to add , that the mount script had not changed from pup430 to luci254 , which I think had been the third last release candidate for 525 .

That is quite likely but apart from the problem.

The behavior is demonstrable. Did you test it?

~

[Karl Godt]

I used diff command and no output , so they are equal .

I have put some echo into the mount script and functions4puppy4 here @MacPup_F3
and

Code: Select all

mount -n -t ntfs /dev/sda4 /mnt/sda4

returned OK :

$@ =-n -t ntfs /dev/sda4 /mnt/sda4
$1 =-n
$2 =-t
$3 =ntfs
$4 =/dev/sda4
$5 =/mnt/sda4
$6 =
$7 =
$8 =
$9 =
home=/root
CMDPRMS=/dev/sda4 /mnt/sda4
ntfs-3g$RETVAL=0
ntfs-3g_after_check_error_code$RETVAL=0
final$RETVAL=0
$DISPLAY =:0.0
$DEVNAME =sda4
DRVNAME =sda
xDRVNAME =sda
DRVNAME =sda4
/root/.pup_event/derive_sda4 exists
dnPATTERN=/dev/sda| DRV_CATEGORY=drive
starting icon_mounted_func ...
icon_mounted_func BEGIN
1: sda4 2: drive 3:
line 100 DRVICON drive_mntd48.png
line 102 imPATTERN ^/dev/sda4
line 104 now finding the boot partition
... returned from icon mounted func
finishing now /bin/mount ...
$RETVAL=0
.../bin/mount finished

actually there is a

#screen out all the options...

by

CMDPRMS="`echo -n "$*" | tr '\t' ' ' | tr -s ' ' | tr ' ' '\n' | grep '^/' | tr '\n' ' '`"

so everything not starting with '/' like '/dev/sda4' and '/mnt/sda4' gets eliminated
before

ntfs-3g $CMDPRMS -o umask=0,no_def_opts 2>/tmp/ntfsmnterr${MYPID}.txt

and /tmp/ntfsmnterr is empty .

So any option you pass to puppy mount script attempting to mount a ntfs fs gets lost and replaced by the standard option you find in there .

But the mount-FULL binary seems to do the job to mount ntfs also by calling directly

Code: Select all

mount-FULL -n -o ro /dev/sda4 /mnt/sda4

and mounts also 'ro' , but of course the mount ball does not appear on the drive icon .

I don't know if mount-FULL uses ntfs-3g like ntfsmount uses mount .

The ntfs-3g -V on MacPup_F3 is "ntfs-3g 2009.4.4 integrated FUSE 27" and on 511 "ntfs-3g 2010.1.16 integrated FUSE 27" and works also on on Glibc-2.6.1 but
Puppy 52er ntfs-3g needs Glibc>=2.7 and does not work on 4series , but so I cant test this further , but mount-FULL is everywhere the same version and works on 4series .

I would try to get rid of the 52 ntfs-3g and its libs and replace it with 511 ntfs-3g .

If you are only applying frugal installs you can leave /bin/df as it is , but for full installations the `rdev` substitution for /dev/root might be necessary .

[Karl Godt]

another type of code might be

Code: Select all

mount -a -t ntfs
mount -a -t ext2
mount -a -t ext3 

because the Puppy mount script only runs ntfs-3g if it finds the exact term 'ntfs' in "$@" , otherwise it would run mount-FULL , which works with the '-n' option but calling directly ntfs-3g -n /dev/sda4 /mnt/sda4 does not work , but the mount script takes care to delete anything else than starting with '/' from "$@"|"$*" before calling ntfs-3g .

To me it seems to be a bug of the newer ntfs-3g , might have changed the reading of the fstab file .

And googling throw up this page:

ntfs-3g does not respect fstab options

with some fstab examples for the option 'user' and setuids and correct blkid , maybe there is a problem with the LOCALE ...