Installing packages on nanoBSD?

[rcfa]

I guess I can answer my own question, sort of:

The thing I'm experiencing I seem to experience because I run the pfHacom variant of pfSense, because I need the VGA console on a nanoBSD system. And pfHacom seems to be somewhat modified as per this statement found here: http://www.hacom.net/kb/pfsense-2-rc3

We remount the root filesystem as read-only, sync, noatime. The default pfSense nanobsd mounts the filesystems as write-able, sync, noatime.
This changes the "normal" behavior pf pfSense. Any write (update) operations require the root filesystem to be remounted as write-able by the shell command: "mount -u -ow /". After the changes, just reboot the system or execute the command: "sh /usr/local/etc/rc.d/hacom.sh" to mount the root filesystem back as read-only.
This is a precaution since during early testing of pfSense 2.0: both BETA5 and RC1, we have experienced major flash corruptions.

So needless to say, this answer leads to the next question: Are these precautionary measures still required? Has it been tracked down and fixed what caused these issues?

[cmb]

they're working around http://redmine.pfsense.org/issues/1279  which is apparently masking something else, or else they've broken the mount/remount that's part of the package process (which should work as it shouldn't be diff from 1.2.3 where that works and isn't impacted by #1279, but hard to say for sure offhand).

[rcfa]

OK, so then their workaround actually at "worst" restores the way things should be: read-only mount of the file system.
But then my original question pops back up: why do I get error messages all over the place about the file system being read-only, if it's supposed to be read-only. In other words, not only is there a bug where the root file system is left rw without their workaround, there one or more other bugs, in that the file system isn't remounted rw when settings are changed or the user tries to install packages. Or am I missing something here?

[stephenw10]

The problem is that the usual functions used for remounting the file system:

/etc/rc.conf_mount_rw
and
/etc/rc.conf_mount_ro

no longer work. Thus if you have mounted the file system read only manually, using the mount command, then the system can't remount it RW.

Steve

[rcfa]

@stephenw10:

The problem is that the usual functions used for remounting the file system:

/etc/rc.conf_mount_rw
and
/etc/rc.conf_mount_ro

no longer work. Thus if you have mounted the file system read only manually, using the mount command, then the system can't remount it RW.

Thanks for the answer. I'm not quite clear about something, though: the two functions you mention, they don't work anymore due to changes made by the hacom people in their version of pfSense, or due to a bug in the current nanoBSD distribution?

[stephenw10]

It's because of the bug in pfSense.
Hacom have done a workaround because they apparently experienced a lot of file system corruption during testing but that has broken the package system.

Steve

[mhotel]

So just to be clear as I'm about to try this:  Can we install packages on current nanoBSD builds of pfSense 2.0?

[cmb]

@mhotel:

So just to be clear as I'm about to try this:  Can we install packages on current nanoBSD builds of pfSense 2.0?

Yes. If you're using Hacom's version, no.

[rcfa]

Is the the underlying bug going to be fixed by the time 2.0 is released, or is this something we're going to have to deal with until 2.1 or so?
On the surface, this sounds like it should be trivial to fix, unless there's a complex backstory to this whole thing.
Heck, makes me wonder why the Hacom people do a workaround, rather than just fixing the bug. Of course I also wonder why I need to use the Hacom version to get a VGA console on a nanoBSD version  ;)

Ronald

[jimp]

@rcfa:

Is the the underlying bug going to be fixed by the time 2.0 is released, or is this something we're going to have to deal with until 2.1 or so?

Hopefully.

@rcfa:

On the surface, this sounds like it should be trivial to fix […]

It's not.

@rcfa:

[…] unless there's a complex backstory to this whole thing.

There is.

@rcfa:

Heck, makes me wonder why the Hacom people do a workaround, rather than just fixing the bug. Of course I also wonder why I need to use the Hacom version to get a VGA console on a nanoBSD version  ;)

You don't.

[rcfa]

@jimp:

@rcfa:

Heck, makes me wonder why the Hacom people do a workaround, rather than just fixing the bug. Of course I also wonder why I need to use the Hacom version to get a VGA console on a nanoBSD version  ;)

You don't.

Wow. Nobody mentioned these in the context of the thread that eventually pointed me to the hacom versions… (unless I was asleep).
...of course, the one thing the hacom versions have: an amd64 variety, any plans for that? Things like crypto, etc. should be quite a bit faster when using the amd64 processor model, due to the compiler's ability to use more registers, and since the biggest CPU hogs on the system will be VPN and VoIP, and since my Lanner box has a 64-bit Atom CPU, that makes it somewhat desirable to go with the amd64 setup.

The other question I have: how are updates handled if I install these? Theoretically, I only need the VGA for initial setup, unless something goes wrong, but then it always does when it can ;)

[stephenw10]

@rcfa:

Wow. Nobody mentioned these in the context of the thread that eventually pointed me to the hacom versions… (unless I was asleep).

First I've heard of them. Nice one Jim.  ;D

Steve

[jimp]

Actually a commercial support customer requested that one so I made it and uploaded them upon their request.

If you setup you own builder vm(s) then you can make your own, too. The problem is that it never ends with requests. I made that one because they specifically requested 4gb i386… but then someone else will want amd64, and 2gb, and 1gb, and 8gb, etc, etc. and by then the originals are old enough that you need to make new ones, and so on, and so on... :-)

So due to time constraints, customer requests come first of course, always time for those. But if I have a few spare cycles I might fire up another VM and build amd64. Keep an eye on that URL, but it probably wouldn't be anytime really soon.

[rcfa]

@jimp:

Actually a commercial support customer requested that one so I made it and uploaded them upon their request.

Ah, I see.

@jimp:

If you setup you own builder vm(s) then you can make your own, too. The problem is that it never ends with requests. I made that one because they specifically requested 4gb i386… but then someone else will want amd64, and 2gb, and 1gb, and 8gb, etc, etc. and by then the originals are old enough that you need to make new ones, and so on, and so on... :-)

That may be an option. What VM are you using? VirtualBox? How does the VM update its code base? gitsync?
The newer VirtualBox releases support VM cloning, so it would be easy to clone the entire VM and upload it.
Then it would be easy for people to do custom builds.

@jimp:

So due to time constraints, customer requests come first of course, always time for those. But if I have a few spare cycles I might fire up another VM and build amd64. Keep an eye on that URL, but it probably wouldn't be anytime really soon.

I'll keep my eyes peeled…

[jimp]

@rcfa:

@jimp:

If you setup you own builder vm(s) then you can make your own, too. The problem is that it never ends with requests. I made that one because they specifically requested 4gb i386… but then someone else will want amd64, and 2gb, and 1gb, and 8gb, etc, etc. and by then the originals are old enough that you need to make new ones, and so on, and so on... :-)

That may be an option. What VM are you using? VirtualBox? How does the VM update its code base? gitsync?
The newer VirtualBox releases support VM cloning, so it would be easy to clone the entire VM and upload it.
Then it would be easy for people to do custom builds.

I believe GeekGod (@sullrich on twitter) had posted some builder .ova files that should work in vbox/esx. I use virtualbox. Just a plain FreeBSD 8.1 VM with the builder code on it. Check the dev wiki for the particulars. I also have VMware workstation, but the fastest box in my house is a FreeBSD workstation so no VMware there, VBox does a great job for me there.

[bao]

If you want the default behavior of pfSense on our Hacom images, just delete the file /usr/local/etc/rc.d/hacom.sh, then reboot.

…....
mount -u -ow /
rm /usr/local/etc/rc.d/hacom.sh
.......

[stephenw10]

That's good to know, thanks.  :)

Steve

[rcfa]

@jimp:

I believe GeekGod (@sullrich on twitter) had posted some builder .ova files that should work in vbox/esx. I use virtualbox. Just a plain FreeBSD 8.1 VM with the builder code on it. Check the dev wiki for the particulars. I also have VMware workstation, but the fastest box in my house is a FreeBSD workstation so no VMware there, VBox does a great job for me there.

Cool. Downloading as I write this…

Another question: why is http://redmine.pfsense.org/issues/1279 showing as "100% done" when we still have the bug?
Or is there another bug report for the current behavior? According to redmine, this was fixed 4 months ago...

[rcfa]

@bao:

If you want the default behavior of pfSense on our Hacom images, just delete the file /usr/local/etc/rc.d/hacom.sh, then reboot.

…....
mount -u -ow /
rm /usr/local/etc/rc.d/hacom.sh
.......

Thanks for the info. On the hacom.net page it lists the following changes to the standard distribution:

We have renamed the the nanobsd version of pfSense 2.0RC3 as pfHacom. Following are the some of the features of pfHacom:

1. Dual displays: VGA and serial console. The serial console is configured for 9600 8N1.

2. Adding support for USB keyboard to accompany the VGA mode.

3. Adding "kern.cam.boot_delay=10000" to the loader.conf, since some of our systems, specifically the OpenBrick-M family, are using the USB flash drive, instead of a compact flash.

4. We remount the root filesystem as read-only, sync, noatime. The default pfSense nanobsd mounts the filesystems as write-able, sync, noatime.
   This changes the "normal" behavior pf pfSense. Any write (update) operations require the root filesystem to be remounted as write-able by the shell command: "mount -u -ow /". After the changes, just reboot the system or execute the command: "sh /usr/local/etc/rc.d/hacom.sh" to mount the root filesystem back as read-only.
   This is a precaution since during early testing of pfSense 2.0: both BETA5 and RC1, we have experienced major flash corruptions.

Do any of these require patches to the code base, or are these simply build-time configuration options?
If these require patches, are they folded back into the standard code base?
Are there any other changes under the hood?
If this requires patches, are they available for download somewhere?

[jimp]

@rcfa:

Cool. Downloading as I write this…

Another question: why is http://redmine.pfsense.org/issues/1279 showing as "100% done" when we still have the bug?
Or is there another bug report for the current behavior? According to redmine, this was fixed 4 months ago...

Someone checked in a fix, which marked it 100% and feedback automatically, but the fix was reverted/changed because it broke other things, and the progress was never updated (by hand)