Re: OpenBSD Readonly File System
Hey, I read that message about Freeradius not being able to access /dev/null in a setup where /dev is mounted on an mfs -based filesystem.I'm running similar setup (for years now) - OpenBSD on a USB stick. EVERYTHING is mounted read-only, except /var, /tmp, /dev and /jails, which are mfs - based. Now what I've noticed in particular about /dev is this: for this mfs-based /dev to work I HAD TO leave the initial /dev directory populated with dev files just as it was from the installation. Or else, run MAKEDEV in there -- but make sure it is filled with devices with original permissions etc. When I tried to mount mfs over EMPTY /dev directory, the resulting devices were not accessible. The same proved true about /var. So in order to install packages, I had to remount /usr /var read-write, then install && remount ro. Otherwise it won't work. Hope that helps With kindest regards, Kostya Berger
Re: OpenBSD Readonly File System
And if the FS is mounted rw, do you have the issue ?
Best Regards,
Strahil Nikolov
На 11 юли 2020 г. 10:22:53 GMT+03:00, Vertigo Altair
написа:
> Hello Again,
>I followed Stuart's recommendations,
>
>in fstab, / has read-write permissions;
>also, I mounted /dev as ramdisk, ( I executed "MAKEDEV all" in
>/dev_src
>directory for once)
>
>vertigo# cat /etc/fstab
>5e045fec2af2ab03.b none swap sw
>5e045fec2af2ab03.a / ffs rw 1 1
> 5e045fec2af2ab03.e /mydir ffs rw 1 1
>5e045fec2af2ab03.d /usr ffs ro,wxallowed,nodev 1 2
>swap /dev mfs rw,async,noatime,nosuid,dev,-s32M,-i8,-P/dev_src 0 0
>
>and I'm updating / as readonly in rc.local;
>
>vertigo# cat /etc/rc.local
>mount -fur /
>
>Everything is OK right now. However, when I try to run radiusd, I'm
>getting
>"failed to opening /dev/null: permission denied" error.
>All configs, and files related with radiusd are in read-write /mydir
>directory.
>I tried to change the permission for /dev/ as 776 and /dev/null as 777
>but
>this didn't work.
>
>vertigo# /usr/local/sbin/radiusd -X -d /mydir/etc/raddb
>FreeRADIUS Version 3.0.21
>Copyright (C) 1999-2019 The FreeRADIUS server project and contributors
>There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
>PARTICULAR PURPOSE
>You may redistribute copies of FreeRADIUS under the terms of the
>GNU General Public License
>For more information about these matters, see the file named COPYRIGHT
>Starting - reading configuration files ...
>including dictionary file /usr/local/share/freeradius/dictionary
>including dictionary file /usr/local/share/freeradius/dictionary.dhcp
>including dictionary file /usr/local/share/freeradius/dictionary.vqp
>including dictionary file /mydir/etc/raddb/dictionary
>including configuration file /mydir/etc/raddb/radiusd.conf
>including configuration file /mydir/etc/raddb/proxy.conf
>including configuration file /mydir/etc/raddb/clients.conf
>including files in directory /mydir/etc/raddb/mods-enabled/
>including configuration file /mydir/etc/raddb/mods-enabled/always
>including configuration file /mydir/etc/raddb/mods-enabled/attr_filter
>including configuration file /mydir/etc/raddb/mods-enabled/cache_eap
>including configuration file /mydir/etc/raddb/mods-enabled/chap
>including configuration file /mydir/etc/raddb/mods-enabled/date
>including configuration file /mydir/etc/raddb/mods-enabled/detail
>including configuration file /mydir/etc/raddb/mods-enabled/detail.log
>including configuration file /mydir/etc/raddb/mods-enabled/digest
>including configuration file
>/mydir/etc/raddb/mods-enabled/dynamic_clients
>including configuration file /mydir/etc/raddb/mods-enabled/eap
>including configuration file /mydir/etc/raddb/mods-enabled/echo
>including configuration file /mydir/etc/raddb/mods-enabled/exec
>including configuration file /mydir/etc/raddb/mods-enabled/expiration
>including configuration file /mydir/etc/raddb/mods-enabled/expr
>including configuration file /mydir/etc/raddb/mods-enabled/files
>including configuration file /mydir/etc/raddb/mods-enabled/linelog
>including configuration file /mydir/etc/raddb/mods-enabled/logintime
>including configuration file /mydir/etc/raddb/mods-enabled/mschap
>including configuration file /mydir/etc/raddb/mods-enabled/ntlm_auth
>including configuration file /mydir/etc/raddb/mods-enabled/pap
>including configuration file /mydir/etc/raddb/mods-enabled/passwd
>including configuration file /mydir/etc/raddb/mods-enabled/preprocess
>including configuration file /mydir/etc/raddb/mods-enabled/radutmp
>including configuration file /mydir/etc/raddb/mods-enabled/realm
>including configuration file /mydir/etc/raddb/mods-enabled/replicate
>including configuration file /mydir/etc/raddb/mods-enabled/soh
>including configuration file /mydir/etc/raddb/mods-enabled/sradutmp
>including configuration file /mydir/etc/raddb/mods-enabled/unix
>including configuration file /mydir/etc/raddb/mods-enabled/unpack
>including configuration file /mydir/etc/raddb/mods-enabled/utf8
>including files in directory /mydir/etc/raddb/policy.d/
>including configuration file /mydir/etc/raddb/policy.d/abfab-tr
>including configuration file /mydir/etc/raddb/policy.d/accounting
>including configuration file /mydir/etc/raddb/policy.d/canonicalization
>including configuration file /mydir/etc/raddb/policy.d/control
>including configuration file /mydir/etc/raddb/policy.d/cui
>including configuration file /mydir/etc/raddb/policy.d/debug
>including configuration file /mydir/etc/raddb/policy.d/dhcp
>including configuration file /mydir/etc/raddb/policy.d/eap
>including configuration file /mydir/etc/raddb/policy.d/filter
>including configuration file
>/mydir/etc/raddb/policy.d/moonshot-targeted-ids
>including configuration file /mydir/etc/raddb/policy.d/operator-name
>including configuration file /mydir/etc/raddb/policy.d/rfc7542
>including files in directory /mydir/etc/raddb/sites-enabled/
>including configuration file
>/mydir/etc/raddb/sites-enabled/inner-tunnel
>main {
> security {
>
Re: OpenBSD Readonly File System
On 2020/07/11 10:22, Vertigo Altair wrote: > Hello Again, > I followed Stuart's recommendations, > > in fstab, / has read-write permissions; > also, I mounted /dev as ramdisk, ( I executed "MAKEDEV all" in /dev_src > directory for once) > > vertigo# cat /etc/fstab > 5e045fec2af2ab03.b none swap sw > 5e045fec2af2ab03.a / ffs rw 1 1 > 5e045fec2af2ab03.e /mydir ffs rw 1 1 > 5e045fec2af2ab03.d /usr ffs ro,wxallowed,nodev 1 2 > swap /dev mfs rw,async,noatime,nosuid,dev,-s32M,-i8,-P/dev_src 0 0 > > and I'm updating / as readonly in rc.local; > > vertigo# cat /etc/rc.local > mount -fur / > > Everything is OK right now. However, when I try to run radiusd, I'm getting > "failed to opening > /dev/null: permission denied" error. > All configs, and files related with radiusd are in read-write /mydir > directory. > I tried to change the permission for /dev/ as 776 and /dev/null as 777 but > this didn't work. /dev should be mode 755 owned by root:wheel, and /dev/null should be mode 666. Permissions on the mfs are copied from permissions on the mount point (so boot in single user mode and check /dev permissions before it's mounted, they should be as above). This doesn't explain the "permission denied" from freeradius though... > vertigo# /usr/local/sbin/radiusd -X -d /mydir/etc/raddb > FreeRADIUS Version 3.0.21 > Copyright (C) 1999-2019 The FreeRADIUS server project and contributors > There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A > PARTICULAR PURPOSE > You may redistribute copies of FreeRADIUS under the terms of the > GNU General Public License > For more information about these matters, see the file named COPYRIGHT > Starting - reading configuration files ... > including dictionary file /usr/local/share/freeradius/dictionary > including dictionary file /usr/local/share/freeradius/dictionary.dhcp > including dictionary file /usr/local/share/freeradius/dictionary.vqp > including dictionary file /mydir/etc/raddb/dictionary > including configuration file /mydir/etc/raddb/radiusd.conf > including configuration file /mydir/etc/raddb/proxy.conf > including configuration file /mydir/etc/raddb/clients.conf > including files in directory /mydir/etc/raddb/mods-enabled/ > including configuration file /mydir/etc/raddb/mods-enabled/always > including configuration file /mydir/etc/raddb/mods-enabled/attr_filter > including configuration file /mydir/etc/raddb/mods-enabled/cache_eap > including configuration file /mydir/etc/raddb/mods-enabled/chap > including configuration file /mydir/etc/raddb/mods-enabled/date > including configuration file /mydir/etc/raddb/mods-enabled/detail > including configuration file /mydir/etc/raddb/mods-enabled/detail.log > including configuration file /mydir/etc/raddb/mods-enabled/digest > including configuration file /mydir/etc/raddb/mods-enabled/dynamic_clients > including configuration file /mydir/etc/raddb/mods-enabled/eap > including configuration file /mydir/etc/raddb/mods-enabled/echo > including configuration file /mydir/etc/raddb/mods-enabled/exec > including configuration file /mydir/etc/raddb/mods-enabled/expiration > including configuration file /mydir/etc/raddb/mods-enabled/expr > including configuration file /mydir/etc/raddb/mods-enabled/files > including configuration file /mydir/etc/raddb/mods-enabled/linelog > including configuration file /mydir/etc/raddb/mods-enabled/logintime > including configuration file /mydir/etc/raddb/mods-enabled/mschap > including configuration file /mydir/etc/raddb/mods-enabled/ntlm_auth > including configuration file /mydir/etc/raddb/mods-enabled/pap > including configuration file /mydir/etc/raddb/mods-enabled/passwd > including configuration file /mydir/etc/raddb/mods-enabled/preprocess > including configuration file /mydir/etc/raddb/mods-enabled/radutmp > including configuration file /mydir/etc/raddb/mods-enabled/realm > including configuration file /mydir/etc/raddb/mods-enabled/replicate > including configuration file /mydir/etc/raddb/mods-enabled/soh > including configuration file /mydir/etc/raddb/mods-enabled/sradutmp > including configuration file /mydir/etc/raddb/mods-enabled/unix > including configuration file /mydir/etc/raddb/mods-enabled/unpack > including configuration file /mydir/etc/raddb/mods-enabled/utf8 > including files in directory /mydir/etc/raddb/policy.d/ > including configuration file /mydir/etc/raddb/policy.d/abfab-tr > including configuration file /mydir/etc/raddb/policy.d/accounting > including configuration file /mydir/etc/raddb/policy.d/canonicalization > including configuration file /mydir/etc/raddb/policy.d/control > including configuration file /mydir/etc/raddb/policy.d/cui > including configuration file /mydir/etc/raddb/policy.d/debug > including configuration file /mydir/etc/raddb/policy.d/dhcp > including configuration file /mydir/etc/raddb/policy.d/eap > including configuration file /mydir/etc/raddb/policy.d/filter > including configuration file
Re: OpenBSD Readonly File System
Hello Again,
I followed Stuart's recommendations,
in fstab, / has read-write permissions;
also, I mounted /dev as ramdisk, ( I executed "MAKEDEV all" in /dev_src
directory for once)
vertigo# cat /etc/fstab
5e045fec2af2ab03.b none swap sw
5e045fec2af2ab03.a / ffs rw 1 1
5e045fec2af2ab03.e /mydir ffs rw 1 1
5e045fec2af2ab03.d /usr ffs ro,wxallowed,nodev 1 2
swap /dev mfs rw,async,noatime,nosuid,dev,-s32M,-i8,-P/dev_src 0 0
and I'm updating / as readonly in rc.local;
vertigo# cat /etc/rc.local
mount -fur /
Everything is OK right now. However, when I try to run radiusd, I'm getting
"failed to opening /dev/null: permission denied" error.
All configs, and files related with radiusd are in read-write /mydir
directory.
I tried to change the permission for /dev/ as 776 and /dev/null as 777 but
this didn't work.
vertigo# /usr/local/sbin/radiusd -X -d /mydir/etc/raddb
FreeRADIUS Version 3.0.21
Copyright (C) 1999-2019 The FreeRADIUS server project and contributors
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License
For more information about these matters, see the file named COPYRIGHT
Starting - reading configuration files ...
including dictionary file /usr/local/share/freeradius/dictionary
including dictionary file /usr/local/share/freeradius/dictionary.dhcp
including dictionary file /usr/local/share/freeradius/dictionary.vqp
including dictionary file /mydir/etc/raddb/dictionary
including configuration file /mydir/etc/raddb/radiusd.conf
including configuration file /mydir/etc/raddb/proxy.conf
including configuration file /mydir/etc/raddb/clients.conf
including files in directory /mydir/etc/raddb/mods-enabled/
including configuration file /mydir/etc/raddb/mods-enabled/always
including configuration file /mydir/etc/raddb/mods-enabled/attr_filter
including configuration file /mydir/etc/raddb/mods-enabled/cache_eap
including configuration file /mydir/etc/raddb/mods-enabled/chap
including configuration file /mydir/etc/raddb/mods-enabled/date
including configuration file /mydir/etc/raddb/mods-enabled/detail
including configuration file /mydir/etc/raddb/mods-enabled/detail.log
including configuration file /mydir/etc/raddb/mods-enabled/digest
including configuration file /mydir/etc/raddb/mods-enabled/dynamic_clients
including configuration file /mydir/etc/raddb/mods-enabled/eap
including configuration file /mydir/etc/raddb/mods-enabled/echo
including configuration file /mydir/etc/raddb/mods-enabled/exec
including configuration file /mydir/etc/raddb/mods-enabled/expiration
including configuration file /mydir/etc/raddb/mods-enabled/expr
including configuration file /mydir/etc/raddb/mods-enabled/files
including configuration file /mydir/etc/raddb/mods-enabled/linelog
including configuration file /mydir/etc/raddb/mods-enabled/logintime
including configuration file /mydir/etc/raddb/mods-enabled/mschap
including configuration file /mydir/etc/raddb/mods-enabled/ntlm_auth
including configuration file /mydir/etc/raddb/mods-enabled/pap
including configuration file /mydir/etc/raddb/mods-enabled/passwd
including configuration file /mydir/etc/raddb/mods-enabled/preprocess
including configuration file /mydir/etc/raddb/mods-enabled/radutmp
including configuration file /mydir/etc/raddb/mods-enabled/realm
including configuration file /mydir/etc/raddb/mods-enabled/replicate
including configuration file /mydir/etc/raddb/mods-enabled/soh
including configuration file /mydir/etc/raddb/mods-enabled/sradutmp
including configuration file /mydir/etc/raddb/mods-enabled/unix
including configuration file /mydir/etc/raddb/mods-enabled/unpack
including configuration file /mydir/etc/raddb/mods-enabled/utf8
including files in directory /mydir/etc/raddb/policy.d/
including configuration file /mydir/etc/raddb/policy.d/abfab-tr
including configuration file /mydir/etc/raddb/policy.d/accounting
including configuration file /mydir/etc/raddb/policy.d/canonicalization
including configuration file /mydir/etc/raddb/policy.d/control
including configuration file /mydir/etc/raddb/policy.d/cui
including configuration file /mydir/etc/raddb/policy.d/debug
including configuration file /mydir/etc/raddb/policy.d/dhcp
including configuration file /mydir/etc/raddb/policy.d/eap
including configuration file /mydir/etc/raddb/policy.d/filter
including configuration file /mydir/etc/raddb/policy.d/moonshot-targeted-ids
including configuration file /mydir/etc/raddb/policy.d/operator-name
including configuration file /mydir/etc/raddb/policy.d/rfc7542
including files in directory /mydir/etc/raddb/sites-enabled/
including configuration file /mydir/etc/raddb/sites-enabled/inner-tunnel
main {
security {
user = "_freeradius"
group = "_freeradius"
allow_core_dumps = no
}
name = "radiusd"
prefix = "/usr/local"
localstatedir = "/mydir/var"
logdir = "/mydir/var/log/radius"
run_dir =
Re: OpenBSD Readonly File System
On 6/27/20 10:57 AM, Stuart Henderson wrote: On 2020-06-26, Marko Cupać wrote: On 2020-06-24, Aaron Mason wrote: Auto filesystem repair is bad juju. On 2020-06-25 11:17, Stuart Henderson wrote: Nonsense. For many, the possible downsides of automatically running fsck -y are much less a problem than the downsides of *not* running it. Some time ago I wrote here on misc@ about read-only setup, where I intended to modify rc(8) in order to be able to relink kernel before mounting filesystems read-only, and - if I remember correctly - I was warned never to modify rc(8) directly as it's considered as part of base system, and I should only affect it with rc.local, which I did. Is there a way to run fsck -y automatically without modifying rc(8)? Is modifying rc(8) now supported? No, you still need to modify rc to do that, so you need to remember to reinstate it after updating. It would be nice if that wasn't needed but diffs to make it configurable have never been approved. 20 years or so I worked on a network appliance based on FreeBSD. It was required to come up after power failures no matter what. We thought that this was the simplest way to harden the system enough for our requirements: We separated the boot environment from the runtime environment. The initial root filesystem was never writable except during updates. It was populated with the absolute minimumnecessary for the system to come up capable of calling home. During the transition to normal operation filesystems containing the usual files were mounted over it making it invisible and inaccessible. The runtime filesystems could fail fsck during boot and the system could be remotely repaired. They could be refreshed via newfs and tarballs during boot if desired. best, Geoff Steckel
Re: OpenBSD Readonly File System
On 2020-06-26, Marko Cupać wrote: >>> On 2020-06-24, Aaron Mason wrote: >>> Auto filesystem repair is bad juju. > >> On 2020-06-25 11:17, Stuart Henderson wrote: >> Nonsense. For many, the possible downsides of automatically running >> fsck -y are much less a problem than the downsides of *not* running it. > > Some time ago I wrote here on misc@ about read-only setup, where I > intended to modify rc(8) in order to be able to relink kernel before > mounting filesystems read-only, and - if I remember correctly - I was > warned never to modify rc(8) directly as it's considered as part of base > system, and I should only affect it with rc.local, which I did. > > Is there a way to run fsck -y automatically without modifying rc(8)? Is > modifying rc(8) now supported? No, you still need to modify rc to do that, so you need to remember to reinstate it after updating. It would be nice if that wasn't needed but diffs to make it configurable have never been approved.
Re: OpenBSD Readonly File System
On 2020-06-24, Aaron Mason wrote: Auto filesystem repair is bad juju. On 2020-06-25 11:17, Stuart Henderson wrote: Nonsense. For many, the possible downsides of automatically running fsck -y are much less a problem than the downsides of *not* running it. Some time ago I wrote here on misc@ about read-only setup, where I intended to modify rc(8) in order to be able to relink kernel before mounting filesystems read-only, and - if I remember correctly - I was warned never to modify rc(8) directly as it's considered as part of base system, and I should only affect it with rc.local, which I did. Is there a way to run fsck -y automatically without modifying rc(8)? Is modifying rc(8) now supported? -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
Re: OpenBSD Readonly File System
Hi, Thanks to Stuart's recommendations, I made progress but got stuck at another point: When i mount /dev on fstab as this: swap /dev mfs rw,async,noatime,nosuid,-s2M,-i8,-P/dev_src 0 0 Freeradius doesn't work. Here error message: Error opening /dev/null: Permission denied I've changed /dev/null permissions to _freeradius even made it 777. But nothing changed. Any thoughts? On Thu, 25 Jun 2020 at 12:19, Stuart Henderson wrote: > > On Mon, Jun 22, 2020 at 4:24 PM Mogens Jensen > > wrote: > >> +# NOTE: The do_fsck() function has been patched to run 'fsck -y' if an > >> +# automatic file system check fails with exit code 8. > > I have quite a few machines patched like this. > > On 2020-06-24, Aaron Mason wrote: > > Auto filesystem repair is bad juju. > > Nonsense. For many, the possible downsides of automatically running > fsck -y are much less a problem than the downsides of *not* running it. > > Even if there is corruption, there's still a fair chance the machine > will come up far enough to fix things. > > What else is someone going to do other than OOB/drive/fly/whatever > to the machine, press enter and type "fsck -y"? They're not going to > suddenly try to backup a dirty fs where they wouldn't already have > backups. Someone who cares about the data will already have a way > to rebuild or restore from backups. > > >
Re: OpenBSD Readonly File System
> On Mon, Jun 22, 2020 at 4:24 PM Mogens Jensen > wrote: >> +# NOTE: The do_fsck() function has been patched to run 'fsck -y' if an >> +# automatic file system check fails with exit code 8. I have quite a few machines patched like this. On 2020-06-24, Aaron Mason wrote: > Auto filesystem repair is bad juju. Nonsense. For many, the possible downsides of automatically running fsck -y are much less a problem than the downsides of *not* running it. Even if there is corruption, there's still a fair chance the machine will come up far enough to fix things. What else is someone going to do other than OOB/drive/fly/whatever to the machine, press enter and type "fsck -y"? They're not going to suddenly try to backup a dirty fs where they wouldn't already have backups. Someone who cares about the data will already have a way to rebuild or restore from backups.
Re: OpenBSD Readonly File System
On Wednesday, June 24, 2020 10:58 PM, Aaron Mason wrote: > Auto filesystem repair is bad juju. Indeed, but an unbootable network appliance thousands of miles away, is much much worse. Regards, Mogens Jensen
Re: OpenBSD Readonly File System
On Mon, Jun 22, 2020 at 4:24 PM Mogens Jensen
wrote:
>
> Tuesday, June 9, 2020 7:59 AM, Vertigo Altair
> wrote:
>
> > Hi Misc,
> > I have a firewall device and I'm using OpenBSD on it.
>
> Last year I had to configure an OpenBSD 6.5 firewall for use in a
> remote location, and was concerned about power loss corrupting the
> filesystem and making the system unbootable without manual
> intervention. As I did not want to modify OpenBSD in unsupported ways,
> I decided to test what kind of damage power loss could do, by
> randomly removing and applying power to the firewall, many many times.
>
> What I found was that 99% of the time, the system would just repair the
> filesystem and boot without problems, but if by chance the power was
> removed at a short time window during kernel relinking, the kernel
> would become corrupt and leave the system completely unbootable and
> not easy to repair. It was suggested to me that I tried to mount root
> partition with the sync option, so I arranged the partition layout in a
> way that would make it feasible and added the option to fstab.
>
> Only other problem I found, was that a few times after removing power
> when writing a large file, the system would require me to run fsck -y
> manually, this is by design, but I decided it was more important to me
> that the system could boot unattended, with a minuscule risk of
> completely ruining the filesystem, so I wrote a small unsupported patch
> for the rc script (sorry if the formatting gets messed up by posting):
>
> The patch has only been tested on OpenBSD 6.5.
>
> ---
> Index: src/etc/rc
> ===
> RCS file: /cvs/src/etc/rc,v
> retrieving revision 1.536
> diff -u -p -u -p -r1.536 rc
> --- src/etc/rc 1 Apr 2019 11:39:46 - 1.536
> +++ src/etc/rc 20 Aug 2019 22:47:49 -
> @@ -1,5 +1,8 @@
> # $OpenBSD: rc,v 1.536 2019/04/01 11:39:46 tedu Exp $
>
> +# NOTE: The do_fsck() function has been patched to run 'fsck -y' if an
> +# automatic file system check fails with exit code 8.
> +
> # System startup script run by init on autoboot or after single-user.
> # Output and error are redirected to console by init, and the console is the
> # controlling terminal.
> @@ -271,8 +274,14 @@ do_fsck() {
> echo "Reboot failed; help!"
> exit 1
> ;;
> - 8) echo "Automatic file system check failed; help!"
> - exit 1
> + 8) echo "Automatic file system check failed; trying fsck -y"
> + fsck -y
> + case $? in
> + 0) ;;
> + *) echo "Could not repair file system unattended; help!"
> + exit 1
> + ;;
> + esac
> ;;
> 12) echo "Boot interrupted."
> exit 1
> ---
>
> After mounting root filesystem with sync option and applying the patch,
> I was no longer able to make the system unbootable by power loss in my
> test setup. It may be possible, but the risk is now so small that it is
> not a concern for me and the risk of something else breaking is
> probably bigger. During operation in remote location, the system has
> always been able to completely boot after a power loss so far.
>
> So while it was not possible for me to not make any unsupported
> modifications at all, I think it is a very small change compared to
> have read only filesystems. Anyone who knows OpenBSD, will be able to
> manage the firewall without special instructions.
>
>
> Regards,
> Mogens Jensen
>
Auto filesystem repair is bad juju.
--
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse
Re: OpenBSD Readonly File System
Tuesday, June 9, 2020 7:59 AM, Vertigo Altair wrote:
> Hi Misc,
> I have a firewall device and I'm using OpenBSD on it.
Last year I had to configure an OpenBSD 6.5 firewall for use in a
remote location, and was concerned about power loss corrupting the
filesystem and making the system unbootable without manual
intervention. As I did not want to modify OpenBSD in unsupported ways,
I decided to test what kind of damage power loss could do, by
randomly removing and applying power to the firewall, many many times.
What I found was that 99% of the time, the system would just repair the
filesystem and boot without problems, but if by chance the power was
removed at a short time window during kernel relinking, the kernel
would become corrupt and leave the system completely unbootable and
not easy to repair. It was suggested to me that I tried to mount root
partition with the sync option, so I arranged the partition layout in a
way that would make it feasible and added the option to fstab.
Only other problem I found, was that a few times after removing power
when writing a large file, the system would require me to run fsck -y
manually, this is by design, but I decided it was more important to me
that the system could boot unattended, with a minuscule risk of
completely ruining the filesystem, so I wrote a small unsupported patch
for the rc script (sorry if the formatting gets messed up by posting):
The patch has only been tested on OpenBSD 6.5.
---
Index: src/etc/rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.536
diff -u -p -u -p -r1.536 rc
--- src/etc/rc 1 Apr 2019 11:39:46 - 1.536
+++ src/etc/rc 20 Aug 2019 22:47:49 -
@@ -1,5 +1,8 @@
# $OpenBSD: rc,v 1.536 2019/04/01 11:39:46 tedu Exp $
+# NOTE: The do_fsck() function has been patched to run 'fsck -y' if an
+# automatic file system check fails with exit code 8.
+
# System startup script run by init on autoboot or after single-user.
# Output and error are redirected to console by init, and the console is the
# controlling terminal.
@@ -271,8 +274,14 @@ do_fsck() {
echo "Reboot failed; help!"
exit 1
;;
- 8) echo "Automatic file system check failed; help!"
- exit 1
+ 8) echo "Automatic file system check failed; trying fsck -y"
+ fsck -y
+ case $? in
+ 0) ;;
+ *) echo "Could not repair file system unattended; help!"
+ exit 1
+ ;;
+ esac
;;
12) echo "Boot interrupted."
exit 1
---
After mounting root filesystem with sync option and applying the patch,
I was no longer able to make the system unbootable by power loss in my
test setup. It may be possible, but the risk is now so small that it is
not a concern for me and the risk of something else breaking is
probably bigger. During operation in remote location, the system has
always been able to completely boot after a power loss so far.
So while it was not possible for me to not make any unsupported
modifications at all, I think it is a very small change compared to
have read only filesystems. Anyone who knows OpenBSD, will be able to
manage the firewall without special instructions.
Regards,
Mogens Jensen
Re: OpenBSD Readonly File System
On 2020-06-13 12:56, Todd C. Miller wrote: > On Sat, 13 Jun 2020 12:12:05 -0400, Nick Holland wrote: > >> On 2020-06-11 12:07, Strahil Nikolov wrote: >> > I always thought that 'sync' mount option is enough to avoid >> > corruption of the FS. Am I just "fooling" myself ? >> >> As "sync" is the default...yes, I think you are. > > Actually, by default only metadata is written synchronously. The > "sync" mount option causes data to be written synchronously too. > Of course, the disk *itself* has a cache so even with synchronous > writes you can't be sure the data has actually made it to the platter. > > So yes, I agree that sync mounts are not really enough to help here. > You are probably correct that softdep is better for this kind of > thing since it does a better job of keeping the filesystem in a > consistent state, at the cost of missing data when there is an > unclean shutdown. In theory, the on-device cache can still cause > issues when you lose power though. Thanks for the correction! The really embarrassing thing is I even checked the man page, but started from the incorrect assumption that "async" and "sync" were the only two choices and read what I expected, not what is actually on the page. Nick.
Re: OpenBSD Readonly File System
In Linux, the kernel can force flushing the disk cache (which also can be disabled ) via fsync() call . That feature is called 'write barrier'. As I'm not a developer, I never read that portion of the source of openBSD , so I got no idea if similar logic can be used in openBSD. Does 'softdep' represents the behaviour of 'write barriers' in Linux ? Best Regards, Strahil Nikolov На 13 юни 2020 г. 19:56:18 GMT+03:00, "Todd C. Miller" написа: >On Sat, 13 Jun 2020 12:12:05 -0400, Nick Holland wrote: > >> On 2020-06-11 12:07, Strahil Nikolov wrote: >> > I always thought that 'sync' mount option is enough to avoid >> > corruption of the FS. Am I just "fooling" myself ? >> >> As "sync" is the default...yes, I think you are. > >Actually, by default only metadata is written synchronously. The >"sync" mount option causes data to be written synchronously too. >Of course, the disk *itself* has a cache so even with synchronous >writes you can't be sure the data has actually made it to the platter. > >So yes, I agree that sync mounts are not really enough to help here. >You are probably correct that softdep is better for this kind of >thing since it does a better job of keeping the filesystem in a >consistent state, at the cost of missing data when there is an >unclean shutdown. In theory, the on-device cache can still cause >issues when you lose power though. > > - todd
Re: OpenBSD Readonly File System
On 2020-06-09 09:59, Vertigo Altair wrote: Hi Misc, I have a firewall device and I'm using OpenBSD on it. There is an electricity problem where the device runs. Therefore, I have to run the "fsck -y" command regularly at startup due to the electricity problem. To overcome this, I want to use readonly file system. I know there are some projects like "resflash", but I want to do that manually. ... On startup following errors comming from /etc/rc; I think errors about /etc/motd are not so important, but are the errors coming from /etc/tty* can cause any problems? If my method is not correct, what is the best way to do this? AFAIK, OpenBSD officially does not support read-only root file system. But I have a similar problem, and I have described my solution here: https://www.mimar.rs/blog/how-to-increase-openbsds-resilience-to-power-outages HTH, -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
Re: OpenBSD Readonly File System
On Sat, 13 Jun 2020 12:12:05 -0400, Nick Holland wrote: > On 2020-06-11 12:07, Strahil Nikolov wrote: > > I always thought that 'sync' mount option is enough to avoid > > corruption of the FS. Am I just "fooling" myself ? > > As "sync" is the default...yes, I think you are. Actually, by default only metadata is written synchronously. The "sync" mount option causes data to be written synchronously too. Of course, the disk *itself* has a cache so even with synchronous writes you can't be sure the data has actually made it to the platter. So yes, I agree that sync mounts are not really enough to help here. You are probably correct that softdep is better for this kind of thing since it does a better job of keeping the filesystem in a consistent state, at the cost of missing data when there is an unclean shutdown. In theory, the on-device cache can still cause issues when you lose power though. - todd
Re: OpenBSD Readonly File System
On 2020-06-11 12:07, Strahil Nikolov wrote:
> I always thought that 'sync' mount option is enough to avoid
> corruption of the FS. Am I just "fooling" myself ?
As "sync" is the default...yes, I think you are.
File systems are complicated. Making them work robustly is even
more complicated. And the ways hardware (including power) fails
is often difficult to comprehend from a high-level language
standpoint ("I just wrote fifty bytes to the end of the file,
what's the big deal?"). All things considered, FFS works
amazingly well.
Back to the OP's question -- I'm curious why he's having trouble
I just don't have. The vast majority of the time, my firewalls
and other OpenBSD systems just come back on their own without
intervention. When I'm moving or otherwise maintaining an
OpenBSD system, I often just yank the power cord and let the
thing fsck itself on reboot. I'm not going to say it ALWAYS
comes back without intervention, but I'd guess well over 90%
of the time, they just come up without help.)
So... I'd look at what's going on more than try to change the
basic operation of OpenBSD. Why are you writing to disk so much
that your file systems end up being trashed?
Some ideas I'd try before making a Franken-system:
* Log to another system over the network via syslog so less
writing happens locally.
* use the noatime mount option -- that reduces a lot of
unneeded writes.
* Faster disks -- How about a small SSD? They spend less
time writing, and often have enough on-board capacitance to
complete writes after a power interruption.
* experiment with softdeps. Supposedly, it helps keep the
/FILE SYSTEM/ consistent. My experience is it tends to
truncate files on unexpected power-downs, but in MOST cases,
I'd rather have a zero byte file that has obviously been
mangled than one that looks ok. I almost always use softdeps,
maybe that's why my systems almost always come back after a
power interruption?
I have no hard facts to back up any of those helping a
system come up on its own after a impolite powerdown, but
they all seem like they might. And I do most of them, and
my results seem to be better than the OP's, so maybe?
Nick.
Re: OpenBSD Readonly File System
On 2020-06-11 23:47, Dirk Coetzee wrote: > I always thought that 'sync' mount option is enough to avoid corruption of the FS. > Am I just "fooling" myself ? > I guess it boils down to a matter of preference and business requirements. > > "slow writes" vs "no writes". It's a good point, perhaps? Comments anyone? I think many went the RO route to avoid fsck and add an extra layer of security. Now that there is KARL and ffs2 means fsck is faster. The argument for RO being more of a problem than anything else, has gotten stronger, whilst ironically there seems to be more frequent reports of people using RO. Batteries/UPS are certainly still, the best answer. Database corruption for example. I also wonder how sync might affect disk churn during KARL. I'm not sure I care at all, about a one-off at boot though. Is there any mileage for root to be mounted sync in any case with so few writes, but maybe a problem for bsd.rd and live upgrades may want to re-mount? Though perhaps safety is more important, in any case?
Re: OpenBSD Readonly File System
I guess it boils down to a matter of preference and business requirements. "slow writes" vs "no writes". -Original Message- From: Strahil Nikolov Sent: Friday, 12 June 2020 12:08 AM To: Dirk Coetzee ; Joe Barnett ; Vertigo Altair Cc: Misc Subject: Re: OpenBSD Readonly File System I always thought that 'sync' mount option is enough to avoid corruption of the FS. Am I just "fooling" myself ? Best Regards, Strahil Nikolov На 10 юни 2020 г. 7:46:48 GMT+03:00, Dirk Coetzee написа: >I have been in a similar situation of power being unreliable and no >UPS, so I sympathize. > >This is how I have achieved RO filesystem (default partitions) > >1. Add to /etc/fstab > swap /dev mfs rw,-P=/dev,-s=32m 0 0 > >2. Create RO Script > #!/bin/sh > > UP=$(( $(date +%s) - $(sysctl -n kern.boottime) )) ## Date in >Seconds subtracted from OS boot time > > if [ $UP -lt 3600 ]; then ## > If less than 1 hour - >leave system as is. No modification of FS. You can add crontab for this >script to run every hour. > exit 1 > else > mount -uvr / > mount -uvr /usr > mount -uvr /usr/X11R6 > mount -uvr /usr/local > mount -uvr /usr/obj > mount -uvr /usr/src > fi > > exit 1 > > >Obviously this is a last resort. Default partitions, etc should remain >as devs intended. The Developers also assume a work (RW) filesystem. > >I have a RW script that I run before doing sysupgrade / syspatch etc. >Also make the Filesystems RW before rebooting. > > > > >-Original Message----- >From: owner-m...@openbsd.org On Behalf Of Joe >Barnett >Sent: Wednesday, 10 June 2020 8:02 AM >To: Vertigo Altair >Cc: Misc >Subject: Re: OpenBSD Readonly File System > >On 2020-06-09 00:59, Vertigo Altair wrote: >> Hi Misc, >> I have a firewall device and I'm using OpenBSD on it. There is an >> electricity problem where the device runs. Therefore, I have to run >> the "fsck -y" command regularly at startup due to the electricity >problem. >> To >> overcome this, I want to use readonly file system. >> I know there are some projects like "resflash", but I want to do >that >> manually. > >I have hacked and slashed my way to this kind of configuration for my >firewall/gateway and a few other machines -- and with what appears to >be good results. Please understand this is almost certainly not >supported by the project. I have outlined this at the following URL: > >https://www.mr72.com/readonlyfs.html > >I hope this helps. Any feedback will be greatly appreciated. > >Good luck! > >Joe > >> My partitions like this; >> >> vertigo# df -h >> Filesystem SizeUsed Avail Capacity Mounted on >> /dev/sd0a 3.9G489M3.2G13%/ >> /dev/sd0g 91.8G1.0G 86.2G 1%/mypartition >> /dev/sd0d 989M 12.0K940M 0%/tmp >> /dev/sd0f 3.9G1.7G2.0G46%/usr >> /dev/sd0e 3.9G 46.9M3.6G 1%/var >> >> I want to / and /usr as readonly, I updated /etc/fstab and I made / >> and /usr readonly; >> >> vertigo# cat /etc/fstab >> ec347fefe8d05509.b none swap sw >> ec347fefe8d05509.a / ffs ro 1 1 >> ec347fefe8d05509.g /mypartition ffs rw,nodev,nosuid 1 2 >> ec347fefe8d05509.d /tmp ffs rw,nodev,nosuid 1 2 ec347fefe8d05509.f >> /usr ffs ro,wxallowed,nodev 1 2 ec347fefe8d05509.e /var ffs >> rw,nodev,nosuid 1 2 >> >> >> On startup following errors comming from /etc/rc; I think errors >about >> /etc/motd are not so important, but are the errors coming from >> /etc/tty* >> can cause any problems? If my method is not correct, what is the best > >> way to do this? >> >>>> OpenBSD/amd64 BOOTX64 3.50 >> boot> >> booting hd0a:/bsd: 12957000+2753552+327712+0+708608 >> [807408+128+1024872+749630]=0x1271a18 >> entry point at 0x1001000 >> [ using 2583064 bytes of bsd ELF symbol table ] Copyright (c) 1982, >> 1986, 1989, 1991, 1993 >> The Regents of the University of California. All rights >> reserved. >> Copyright (c) 1995-2020 OpenBSD. All rights reserved. >> https://www.OpenBSD.org >> >> OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun 4 09:55:08 MDT 2020 >> >> >r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GEN >> ERIC.MP >> real mem = 4151607296 (3959MB) >> avail mem = 4013170688 (3827MB) >> mpath0 at root >> scs
Re: OpenBSD Readonly File System
I always thought that 'sync' mount option is enough to avoid corruption of the FS. Am I just "fooling" myself ? Best Regards, Strahil Nikolov На 10 юни 2020 г. 7:46:48 GMT+03:00, Dirk Coetzee написа: >I have been in a similar situation of power being unreliable and no >UPS, so I sympathize. > >This is how I have achieved RO filesystem (default partitions) > >1. Add to /etc/fstab > swap /dev mfs rw,-P=/dev,-s=32m 0 0 > >2. Create RO Script > #!/bin/sh > > UP=$(( $(date +%s) - $(sysctl -n kern.boottime) )) ## Date in >Seconds subtracted from OS boot time > > if [ $UP -lt 3600 ]; then ## > If less than 1 hour - >leave system as is. No modification of FS. You can add crontab for this >script to run every hour. > exit 1 > else > mount -uvr / > mount -uvr /usr > mount -uvr /usr/X11R6 > mount -uvr /usr/local > mount -uvr /usr/obj > mount -uvr /usr/src > fi > > exit 1 > > >Obviously this is a last resort. Default partitions, etc should remain >as devs intended. The Developers also assume a work (RW) filesystem. > >I have a RW script that I run before doing sysupgrade / syspatch etc. >Also make the Filesystems RW before rebooting. > > > > >-Original Message- >From: owner-m...@openbsd.org On Behalf Of Joe >Barnett >Sent: Wednesday, 10 June 2020 8:02 AM >To: Vertigo Altair >Cc: Misc >Subject: Re: OpenBSD Readonly File System > >On 2020-06-09 00:59, Vertigo Altair wrote: >> Hi Misc, >> I have a firewall device and I'm using OpenBSD on it. There is an >> electricity problem where the device runs. Therefore, I have to run >> the "fsck -y" command regularly at startup due to the electricity >problem. >> To >> overcome this, I want to use readonly file system. >> I know there are some projects like "resflash", but I want to do >that >> manually. > >I have hacked and slashed my way to this kind of configuration for my >firewall/gateway and a few other machines -- and with what appears to >be good results. Please understand this is almost certainly not >supported by the project. I have outlined this at the following URL: > >https://www.mr72.com/readonlyfs.html > >I hope this helps. Any feedback will be greatly appreciated. > >Good luck! > >Joe > >> My partitions like this; >> >> vertigo# df -h >> Filesystem SizeUsed Avail Capacity Mounted on >> /dev/sd0a 3.9G489M3.2G13%/ >> /dev/sd0g 91.8G1.0G 86.2G 1%/mypartition >> /dev/sd0d 989M 12.0K940M 0%/tmp >> /dev/sd0f 3.9G1.7G2.0G46%/usr >> /dev/sd0e 3.9G 46.9M3.6G 1%/var >> >> I want to / and /usr as readonly, I updated /etc/fstab and I made / >> and /usr readonly; >> >> vertigo# cat /etc/fstab >> ec347fefe8d05509.b none swap sw >> ec347fefe8d05509.a / ffs ro 1 1 >> ec347fefe8d05509.g /mypartition ffs rw,nodev,nosuid 1 2 >> ec347fefe8d05509.d /tmp ffs rw,nodev,nosuid 1 2 ec347fefe8d05509.f >> /usr ffs ro,wxallowed,nodev 1 2 ec347fefe8d05509.e /var ffs >> rw,nodev,nosuid 1 2 >> >> >> On startup following errors comming from /etc/rc; I think errors >about >> /etc/motd are not so important, but are the errors coming from >> /etc/tty* >> can cause any problems? If my method is not correct, what is the best > >> way to do this? >> >>>> OpenBSD/amd64 BOOTX64 3.50 >> boot> >> booting hd0a:/bsd: 12957000+2753552+327712+0+708608 >> [807408+128+1024872+749630]=0x1271a18 >> entry point at 0x1001000 >> [ using 2583064 bytes of bsd ELF symbol table ] Copyright (c) 1982, >> 1986, 1989, 1991, 1993 >> The Regents of the University of California. All rights >> reserved. >> Copyright (c) 1995-2020 OpenBSD. All rights reserved. >> https://www.OpenBSD.org >> >> OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun 4 09:55:08 MDT 2020 >> >> >r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GEN >> ERIC.MP >> real mem = 4151607296 (3959MB) >> avail mem = 4013170688 (3827MB) >> mpath0 at root >> scsibus0 at mpath0: 256 targets >> mainbus0 at root >> bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebf10 (14 entries) >> bios0: vendor American Megatrends Inc. version "BAR3NA05" date >> 07/23/2018 >> bios0: NF533 NF533 >> acpi0 at bios0: ACPI 5.0 >> acpi0: sleep states S0 S3 S4 S
Re: OpenBSD Readonly File System
I have been in a similar situation of power being unreliable and no UPS, so I sympathize. This is how I have achieved RO filesystem (default partitions) 1. Add to /etc/fstab swap /dev mfs rw,-P=/dev,-s=32m 0 0 2. Create RO Script #!/bin/sh UP=$(( $(date +%s) - $(sysctl -n kern.boottime) )) ## Date in Seconds subtracted from OS boot time if [ $UP -lt 3600 ]; then ## If less than 1 hour - leave system as is. No modification of FS. You can add crontab for this script to run every hour. exit 1 else mount -uvr / mount -uvr /usr mount -uvr /usr/X11R6 mount -uvr /usr/local mount -uvr /usr/obj mount -uvr /usr/src fi exit 1 Obviously this is a last resort. Default partitions, etc should remain as devs intended. The Developers also assume a work (RW) filesystem. I have a RW script that I run before doing sysupgrade / syspatch etc. Also make the Filesystems RW before rebooting. -Original Message- From: owner-m...@openbsd.org On Behalf Of Joe Barnett Sent: Wednesday, 10 June 2020 8:02 AM To: Vertigo Altair Cc: Misc Subject: Re: OpenBSD Readonly File System On 2020-06-09 00:59, Vertigo Altair wrote: > Hi Misc, > I have a firewall device and I'm using OpenBSD on it. There is an > electricity problem where the device runs. Therefore, I have to run > the "fsck -y" command regularly at startup due to the electricity problem. > To > overcome this, I want to use readonly file system. > I know there are some projects like "resflash", but I want to do that > manually. I have hacked and slashed my way to this kind of configuration for my firewall/gateway and a few other machines -- and with what appears to be good results. Please understand this is almost certainly not supported by the project. I have outlined this at the following URL: https://www.mr72.com/readonlyfs.html I hope this helps. Any feedback will be greatly appreciated. Good luck! Joe > My partitions like this; > > vertigo# df -h > Filesystem SizeUsed Avail Capacity Mounted on > /dev/sd0a 3.9G489M3.2G13%/ > /dev/sd0g 91.8G1.0G 86.2G 1%/mypartition > /dev/sd0d 989M 12.0K940M 0%/tmp > /dev/sd0f 3.9G1.7G2.0G46%/usr > /dev/sd0e 3.9G 46.9M3.6G 1%/var > > I want to / and /usr as readonly, I updated /etc/fstab and I made / > and /usr readonly; > > vertigo# cat /etc/fstab > ec347fefe8d05509.b none swap sw > ec347fefe8d05509.a / ffs ro 1 1 > ec347fefe8d05509.g /mypartition ffs rw,nodev,nosuid 1 2 > ec347fefe8d05509.d /tmp ffs rw,nodev,nosuid 1 2 ec347fefe8d05509.f > /usr ffs ro,wxallowed,nodev 1 2 ec347fefe8d05509.e /var ffs > rw,nodev,nosuid 1 2 > > > On startup following errors comming from /etc/rc; I think errors about > /etc/motd are not so important, but are the errors coming from > /etc/tty* > can cause any problems? If my method is not correct, what is the best > way to do this? > >>> OpenBSD/amd64 BOOTX64 3.50 > boot> > booting hd0a:/bsd: 12957000+2753552+327712+0+708608 > [807408+128+1024872+749630]=0x1271a18 > entry point at 0x1001000 > [ using 2583064 bytes of bsd ELF symbol table ] Copyright (c) 1982, > 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights > reserved. > Copyright (c) 1995-2020 OpenBSD. All rights reserved. > https://www.OpenBSD.org > > OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun 4 09:55:08 MDT 2020 > > r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GEN > ERIC.MP > real mem = 4151607296 (3959MB) > avail mem = 4013170688 (3827MB) > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebf10 (14 entries) > bios0: vendor American Megatrends Inc. version "BAR3NA05" date > 07/23/2018 > bios0: NF533 NF533 > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP APIC FPDT FIDT MCFG LPIT HPET SSDT SSDT SSDT > UEFI > acpi0: wakeup devices XHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.37 MHz, 06-37-09 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE3 > 6,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MW > AIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT > ,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP > ,ERMS,MD_CLEAR,IB
Re: OpenBSD Readonly File System
On 2020-06-09 00:59, Vertigo Altair wrote: Hi Misc, I have a firewall device and I'm using OpenBSD on it. There is an electricity problem where the device runs. Therefore, I have to run the "fsck -y" command regularly at startup due to the electricity problem. To overcome this, I want to use readonly file system. I know there are some projects like "resflash", but I want to do that manually. I have hacked and slashed my way to this kind of configuration for my firewall/gateway and a few other machines -- and with what appears to be good results. Please understand this is almost certainly not supported by the project. I have outlined this at the following URL: https://www.mr72.com/readonlyfs.html I hope this helps. Any feedback will be greatly appreciated. Good luck! Joe My partitions like this; vertigo# df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/sd0a 3.9G489M3.2G13%/ /dev/sd0g 91.8G1.0G 86.2G 1%/mypartition /dev/sd0d 989M 12.0K940M 0%/tmp /dev/sd0f 3.9G1.7G2.0G46%/usr /dev/sd0e 3.9G 46.9M3.6G 1%/var I want to / and /usr as readonly, I updated /etc/fstab and I made / and /usr readonly; vertigo# cat /etc/fstab ec347fefe8d05509.b none swap sw ec347fefe8d05509.a / ffs ro 1 1 ec347fefe8d05509.g /mypartition ffs rw,nodev,nosuid 1 2 ec347fefe8d05509.d /tmp ffs rw,nodev,nosuid 1 2 ec347fefe8d05509.f /usr ffs ro,wxallowed,nodev 1 2 ec347fefe8d05509.e /var ffs rw,nodev,nosuid 1 2 On startup following errors comming from /etc/rc; I think errors about /etc/motd are not so important, but are the errors coming from /etc/tty* can cause any problems? If my method is not correct, what is the best way to do this? OpenBSD/amd64 BOOTX64 3.50 boot> booting hd0a:/bsd: 12957000+2753552+327712+0+708608 [807408+128+1024872+749630]=0x1271a18 entry point at 0x1001000 [ using 2583064 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2020 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun 4 09:55:08 MDT 2020 r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4151607296 (3959MB) avail mem = 4013170688 (3827MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebf10 (14 entries) bios0: vendor American Megatrends Inc. version "BAR3NA05" date 07/23/2018 bios0: NF533 NF533 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG LPIT HPET SSDT SSDT SSDT UEFI acpi0: wakeup devices XHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.37 MHz, 06-37-09 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 1MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 83MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.01 MHz, 06-37-09 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.03 MHz, 06-37-09 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu2: 1MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.01 MHz, 06-37-09 cpu3:
Re: OpenBSD Readonly File System
On Tue, 9 Jun 2020 at 08:59, Vertigo Altair wrote: > > Hi Misc, > I have a firewall device and I'm using OpenBSD on it. There is an > electricity problem where the device runs. Therefore, I have to run the > "fsck -y" command regularly at startup due to the electricity problem. Isn't it just easier to buy a UPS? -- Ottavio Caruso
Re: OpenBSD Readonly File System
On 2020-06-09, Vertigo Altair wrote: > Hi Misc, > I have a firewall device and I'm using OpenBSD on it. There is an > electricity problem where the device runs. Therefore, I have to run the > "fsck -y" command regularly at startup due to the electricity problem. To > overcome this, I want to use readonly file system. > I know there are some projects like "resflash", but I want to do that > manually. The usual way to handle / is to have it RW during boot and remount it (mount -ur /) in rc.local. Use a ramdisk (MFS) for /dev. Create a directory on / to populate it from, e.g. cd / mkdir dev_src cp dev/MAKEDEV dev_src cd dev_src sh MAKEDEV all Mount /dev using the -P mount option to populate it from your source directory, it doesn't need much space but needs quite a few inodes, a line like this works: swap /dev mfs rw,async,noatime,nosuid,-s2M,-i8,-P/dev_src 0 0 The dev_src directory needs regenerating after OS updates. /tmp and /var/run probably also best done as ramdisk. Other parts of /var, especially /var/db, are tricky, you can use a ramdisk populated from a source directory as with /dev, but you need a way to sync it back to the source directory otherwise you run into problems (dhcp leases, /var/db/pkg, maybe others depending on what you run). logs: syslog memory buffers are useful. Normally OpenBSD relinks the kernel in a random order - at the end of running /etc/rc, and when you use syspatch to add kernel patches. With RO /usr and / this can't be done. If power is unstable it is often good to avoid the relinking at boot (I've had a few where power has gone, come back for long enough to start relinking, then gone again during relink - considering how circuit breakers work this isn't a big surprise).. but you'll need to be aware of this when applying patches. I have a number of VPN client routers in situations where they may have unstable power or people powering them down without halting first. I tried quite hard to use OpenBSD with them (usually on pcengines boards - alix, apu etc) with various run-from-ramdisk (flashboot, flashrd, resflash) or manual readonly+MFS setups, but came to the conclusion that it's just too much hassle wrangling these and keeping on top of OpenBSD updates. I had to add a bunch more earlier this year so now I have ~60 hapac2 running routeros. Definitely not perfect but seems a better fit to this situation.
OpenBSD Readonly File System
Hi Misc, I have a firewall device and I'm using OpenBSD on it. There is an electricity problem where the device runs. Therefore, I have to run the "fsck -y" command regularly at startup due to the electricity problem. To overcome this, I want to use readonly file system. I know there are some projects like "resflash", but I want to do that manually. My partitions like this; vertigo# df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/sd0a 3.9G489M3.2G13%/ /dev/sd0g 91.8G1.0G 86.2G 1%/mypartition /dev/sd0d 989M 12.0K940M 0%/tmp /dev/sd0f 3.9G1.7G2.0G46%/usr /dev/sd0e 3.9G 46.9M3.6G 1%/var I want to / and /usr as readonly, I updated /etc/fstab and I made / and /usr readonly; vertigo# cat /etc/fstab ec347fefe8d05509.b none swap sw ec347fefe8d05509.a / ffs ro 1 1 ec347fefe8d05509.g /mypartition ffs rw,nodev,nosuid 1 2 ec347fefe8d05509.d /tmp ffs rw,nodev,nosuid 1 2 ec347fefe8d05509.f /usr ffs ro,wxallowed,nodev 1 2 ec347fefe8d05509.e /var ffs rw,nodev,nosuid 1 2 On startup following errors comming from /etc/rc; I think errors about /etc/motd are not so important, but are the errors coming from /etc/tty* can cause any problems? If my method is not correct, what is the best way to do this? >> OpenBSD/amd64 BOOTX64 3.50 boot> booting hd0a:/bsd: 12957000+2753552+327712+0+708608 [807408+128+1024872+749630]=0x1271a18 entry point at 0x1001000 [ using 2583064 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2020 OpenBSD. All rights reserved. https://www.OpenBSD.org OpenBSD 6.7 (GENERIC.MP) #2: Thu Jun 4 09:55:08 MDT 2020 r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4151607296 (3959MB) avail mem = 4013170688 (3827MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xebf10 (14 entries) bios0: vendor American Megatrends Inc. version "BAR3NA05" date 07/23/2018 bios0: NF533 NF533 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG LPIT HPET SSDT SSDT SSDT UEFI acpi0: wakeup devices XHC1(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.37 MHz, 06-37-09 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu0: 1MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 83MHz cpu0: mwait min=64, max=64, C-substates=0.2.0.0.0.0.3.3, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.01 MHz, 06-37-09 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu1: 1MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.03 MHz, 06-37-09 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu2: 1MB 64b/line 16-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 2000.01 MHz, 06-37-09 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,RDRAND,NXE,RDTSCP,LONG,LAHF,3DNOWP,PERF,ITSC,TSC_ADJUST,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,SENSOR,ARAT,MELTDOWN cpu3: 1MB 64b/line 16-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 87 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 7 (RP02) acpiprt3 at acpi0: bus 8 (RP03) acpiprt4 at acpi0: bus 9 (RP04) acpiec0 at
