fstab mounting is borked in v5.25
fstab mounting is borked in v5.25
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 ...
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 ...
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` ?
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` ?
Re: fstab mounting is borked in v5.25
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
~
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
~
from man mount :
writes still into /etc/mtab :
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
busybox mount --help does not say anything about the -n option but seems to accept it .-n Mount without writing in /etc/mtab. This is necessary for example when /etc is on a read-only file system.
Code: Select all
mount-FULL -n /dev/hdb4 /mnt/hdb4
Code: Select all
cat /etc/mtab | tail -n 1
my fstab file is simply this :/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
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
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
man mount doesn't apply to puppy's mountKarl Godt wrote:from man mount :-n Mount without writing in /etc/mtab. This is necessary for example when /etc is on a read-only file system.
The subject here is fstab mounting. You haven't filled in fstab or used it for mounting as far as I can see.my fstab file is simply this :and I have had no problems until now mounting anything .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
~
Re: fstab mounting is borked in v5.25
Tried ntfs-3g in fstab, same error.Bruce B wrote: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
~
Anyone else running 5.25 who can duplicate this symptom?
Re: fstab mounting is borked in v5.25
Did you open the mount script?MikeF wrote:Tried ntfs-3g in fstab, same error.Bruce B wrote: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
~
Anyone else running 5.25 who can duplicate this symptom?
~
Re: fstab mounting is borked in v5.25
This bug report is verified by me (Lupu 5.20)MikeF wrote:In 2009 someone reported (version unknown) that attempting to mount an NTFS partition resulted in an 'unknown option -n' error.
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.
~
- Attachments
-
- bug-validated.jpg
- 'unknown option -n' error.
- (80.2 KiB) Downloaded 2398 times
Last edited by Bruce B on Wed 22 Jun 2011, 08:48, edited 2 times in total.
Re: fstab mounting is borked in v5.25
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.Bruce B wrote: Did you open the mount script?
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!
Re: fstab mounting is borked in v5.25
If true, I'd regard this as a very serious and high priority problem. Something to make a new bug report on.MikeF wrote: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.
Note: I'm not on the developers team anymore than you are.
~
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.
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.
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
~
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 choirBruce B wrote: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
~
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.
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 :
"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 .
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 :
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 :$@ =-i -f -t fuseblk -o ro,nosuid,nodev,default_permissions,allow_other,blksize=4096,user=root /dev/sda4 /mnt/sda4
"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 .
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.Karl Godt wrote: 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 .
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.
~
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
returned OK :
before
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
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 .
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
actually there is a$@ =-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
by#screen out all the options...
so everything not starting with '/' like '/dev/sda4' and '/mnt/sda4' gets eliminatedCMDPRMS="`echo -n "$*" | tr '\t' ' ' | tr -s ' ' | tr ' ' '\n' | grep '^/' | tr '\n' ' '`"
before
and /tmp/ntfsmnterr is empty .ntfs-3g $CMDPRMS -o umask=0,no_def_opts 2>/tmp/ntfsmnterr${MYPID}.txt
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
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 .
another type of code might be
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 ...
Code: Select all
mount -a -t ntfs
mount -a -t ext2
mount -a -t ext3
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 ...