but, as shown, this fails. Is there any fundamental problem
with mounting/remounting / readonly or am I just doing
it wrongly? I can imagine that the existence of files open
for writing might upset this, but “invalid argument” implies
there is more to it.
Must I do it at boot time perhaps? Are there any implications
to doing this apart from needing to move log and lock files
elsewhere (eg another disk or ramdisk)?
Some earlier versions of QNX6 (pre-6.2.1?) did not support
dynamically changing the read-only status of disk filesystems.
They did let you toggle things like noatime/nosuid etc.
mount: Possible reason: Invalid argument
The mount framework tends to munge the errnos (it really was ENOSYS
out of the filesystem to indicate that the read-only toggling wasn’t
supported).
Must I do it at boot time perhaps?
Either upgrade to 6.2.1 or mount read-only initially (if diskboot is
involved don’t ask me how to do this . This would involve splitting
files onto two different partitions (or perhaps procmgr_symlinking
those which you know you will write).
Some earlier versions of QNX6 (pre-6.2.1?) did not support
dynamically changing the read-only status of disk filesystems.
They did let you toggle things like noatime/nosuid etc.
mount: Possible reason: Invalid argument
The mount framework tends to munge the errnos (it really was ENOSYS
out of the filesystem to indicate that the read-only toggling wasn’t
supported).
Must I do it at boot time perhaps?
Either upgrade to 6.2.1 or mount read-only initially (if diskboot is
involved don’t ask me how to do this > > .
Actually, you can get an idea of remounting of / on QNX NC pre 6.2.1 release, looking here:
Those shell scripts do much more work - they do restart EIDE driver, but you can use that idea to
umount and after that mount /.
P.S. Of course, this could be a solution if you have only 6.2.0 NC release. 6.1 allows you to
rebuild start image and don’t use diskboot, 6.2.1 allows you to remount as John said.
Eduard.
This would involve splitting
files onto two different partitions (or perhaps procmgr_symlinking
those which you know you will write).
We have 6.2.1 coming next week so I will try that.
I would rather use the vanialla boot image as it
removes a variable when things go wrong. I imagine
that if I re-mount / as read-only first-thing in
/etc/system/sysinit there is no chance of anything
ever writing to the disk. Am I right?
Either upgrade to 6.2.1 or mount read-only initially (if diskboot is
involved don’t ask me how to do this > > . This would involve splitting
files onto two different partitions (or perhaps procmgr_symlinking
those which you know you will write).
This works with 6.2.1 on a disk where nothing is open
for writing. Trying it to remount / I get a resource busy
error and mount returns 1 to the shell. Since the /.swapfile
is open for writing I guess I cannot remount the root fs.
Or can I? I read that the swap file is only there to support
GCC and we won’t have that on our targets. Can it be disabled?
When I put options in /.diskroot as suggested by kabe, I get
a readonly fs and I can recover write permission by booting
from another disk/partition. I can also issue a
mount -ru /dev/hd0t79 /
on the readonly mount and it appears to succeed: mount
returns 0 to the shell and prints no error. But the fs
is still readonly. Is this intended?
This works with 6.2.1 on a disk where nothing is open
for writing. Trying it to remount / I get a resource busy
error and mount returns 1 to the shell. Since the /.swapfile
is open for writing I guess I cannot remount the root fs.
Or can I? I read that the swap file is only there to support
GCC and we won’t have that on our targets. Can it be disabled?
The only EBUSY check for the read/write remount is that you not
have another filesystem mounted on top of the targeted remount
(because it then too would be forced read-only, and I didn’t
think the change should be recursively applied). If you’re using
the syntax below, then the problem is that you’re applying the
read-only change to the t79 partition, which is EBUSY because
it has “/” mounted on it … target it directly at “/” instead:
“mount -ur /” (yes, this is different from QNX4). Any files
open for write during this phase will EROFS if/when you try to
write them (I figured this was more usable than doing an EBUSY
at the re-mount).
When I put options in /.diskroot as suggested by kabe, I get
a readonly fs and I can recover write permission by booting
from another disk/partition. I can also issue a
mount -ru /dev/hd0t79 /
on the readonly mount and it appears to succeed: mount
returns 0 to the shell and prints no error. But the fs
is still readonly. Is this intended?
Yes. You’ve asked that it be remounted as read-only … try:
“mount -u /” (ie ‘-r’ is a state, not a toggle, and again note
that I target the filesystem and not the partition).
When I put options in /.diskroot as suggested by kabe, I get
a readonly fs and I can recover write permission by booting
from another disk/partition. I can also issue a
mount -ru /dev/hd0t79 /
on the readonly mount and it appears to succeed: mount
returns 0 to the shell and prints no error. But the fs
is still readonly. Is this intended?
Yes. You’ve asked that it be remounted as read-only … try:
“mount -u /” (ie ‘-r’ is a state, not a toggle, and again note
that I target the filesystem and not the partition).
Sorry, silly mistake. I meant -wu; I just tried that and it did
fail so I must really have used -ru before.
I guess this is because of what else is mounted, as you described.
The first line here looks a likely candidate:
mount
/pkgs/repository/waukes/htdoc/core-1.0 on / type pkg
/dev/hd0t77 on / type qnx4
/dev/hd2t77 on /tmp/ram type qnx4
/dev/hd1t77 on /flash type qnx4
saturn:/home on /home type NFSv2
/boot/fs/qnxbase.qfs on /pkgs/base type qnx4
Interestingly, if I mount the root filesystem read-only and then
mount another filesystem read-write on /fs, for example /fs/ram,
then the following fails:
mkdir -p /fs/ram/a/b
mkdir: /fs: No such file or directory
mkdir: /fs/ram/a/b: No such file or directory
but
mkdir /fs/ram/a
mkdir /fs/ram/a/b
works.
. This would involve splitting