Full Install: Select Partition Type



  • Hi, guys.

    I was trying to find that via docs, forum and google with no success.

    When you are doing Full Install, there are several options available to choose:

    FreeBSD
    OpenBSD
    NetBSD
    MS-DOS
    Linux
    Plan9

    I guess FreeBSD is for UFS. I don`t want to guess and unable to find what exactly FS Type is for every option.

    My general goal is to choose most stable filesystem, especially against frequent power outages.


  • Banned

    Uhm? What? Where? The only supported filesystem is UFS and sounds like you got to places where you should not be in the first place in the installer.



  • @doktornotor:

    Uhm? What? Where? The only supported filesystem is UFS and sounds like you got to places where you should not be in the first place in the installer.

    Really? Are you sure about that?

    I had done nothing special, its standard menu for partionioning (see attach).



  • Banned

    Yeah really. The installer normally wipes and partitions the drive automatically, really no need to go there at all.



  • If you dont need that it doesnt means that no one needs. There are options, I need explanations.
    If you don`t know - you can just pass.


  • Banned

    Hell. Let me put it bluntly - asking similar questions strongly suggests you should back out of the advanced whatever and never go there again. Totally unsupported, totally on your own and making wrong selection will just make the installer kaboom. This is a router/firewall appliance, not a generic distro where you are free to play with partitions/slices/filesystems.



  • Thank you for you attention.
    Are there any other opinions?

    BTW, I just made test installation with "OpenBSD" option. Seems like there is no any difference, UFS with SYNC and Journaled Soft-Updates as result in fstab file.



  • You are poking a bear…

    @misant:

    If you dont need that it doesnt means that no one needs. There are options, I need explanations.
    If you don`t know - you can just pass.



  • @doktornotor:

    Totally unsupported, totally on your own and making wrong selection will just make the installer kaboom. This is a router/firewall appliance, not a generic distro where you are free to play with partitions/slices/filesystems.

    misant is right here a bit - if those options are truly unsupported, they should not appear in the setup.
    PfSense is an appliance software, doktornotor is right here, things are pre-configured by default to be optimized to run as a router/firewall.

    But - as many other appliance software developers do - options not supported are hidden from the installation menus. Look at VmWare ESXi for example. That also has a customized similar installation routine, but it's been narrowed down to access only the options basically needed to install or debug that appliance. At the end, the user is directed to the web interface for further configuration. Nothing else is even possible from the console installation.


  • Rebel Alliance Developer Netgate

    Those options are there because that installer supports them, not because they work well with pfSense specifically.

    That installer is going away soon anyhow so for now, just use FreeBSD (or better yet, use the quick/easy install rather than making custom changes) and ignore the others.


  • Banned

    There.

    As for the other question here, I rather won't comment on UFS SU+J, it's currently the ONLY choice on full installs. If you don't want SU+J, get 2.2.2 or earlier install media, you'll get plain UFS. If you don't want UFS, search this forum for ZFS howto, again - not possible with current install media any more.

    P.S. Final advise - get an UPS.



  • Is this true across the board? My SG units have not had SU enabled on the mSATA drives.

    I'll admit I haven't payed enough attention to this…

    @doktornotor:

    I rather won't comment on UFS SU+J, it's currently the ONLY choice on full installs.



  • Thank you, thats complete answer for my question.

    In that case I am going to hardcode fsck -y for every boot procedure.
    I already saw doc about hot to do it for one boot, I guess there will be no problems to do it everytime.

    PS: A have a location, where electricity supply is really awfull. We got UPS there, but its not too big. I got unreachable pfSense in 100 kms now.


  • Banned

    @dennypage:

    Is this true across the board? My SG units have not had SU enabled on the mSATA drives.

    SU+J was introduced on 2.2.3 to "fix" the filesystem corruption. If your install is older, you won't have it, and frankly you are not missing out on anything. It did not help at all with the original issues which was eventually fixed properly. The SU+J thing made complete kaboom on embedded where it was reverted in 2.2.4. Why it was left on full, no idea.


  • Rebel Alliance Developer Netgate

    @dennypage:

    Is this true across the board? My SG units have not had SU enabled on the mSATA drives.

    I'll admit I haven't payed enough attention to this…

    @doktornotor:

    I rather won't comment on UFS SU+J, it's currently the ONLY choice on full installs.

    It gets turned on at install time. If it's been upgraded that won't change.


  • Rebel Alliance Developer Netgate

    @doktornotor:

    @dennypage:

    Is this true across the board? My SG units have not had SU enabled on the mSATA drives.

    SU+J was introduced on 2.2.3 to "fix" the filesystem corruption. If your install is older, you won't have it, and frankly you are not missing out on anything. It did not help at all with the original issues and made completely kaboom on embedded where it was reverted in 2.2.4.

    It wasn't used as a fix for the corruption it was used to lessen the fallout. Without SU+J the files were corrupted (had other file contents inside) with SU+J they were truncated to 0 bytes, which was safer. Though the real problems that caused the corruption have now been solved on 2.2.4, SU+J is still more reliable in the long term now.


  • Banned

    @jimp:

    SU+J is still more reliable in the long term now.

    We'll agree to disagree… :P


  • Rebel Alliance Developer Netgate

    @doktornotor:

    @jimp:

    SU+J is still more reliable in the long term now.

    We'll agree to disagree… :P

    Well you're right it was a bad move for NanoBSD, but for full installs it's been good. :-)


  • Banned

    Well, as said above… Dunno, did someone move the unusable fsck issue upstream? B/c I somehow got the impression that the fsck handling after the shitload of related commits now pretty much matches upstream FreeBSD -- and still cannot see how such behaviour is usable on remotely administered boxes.



  • @jimp:

    It wasn't used as a fix for the corruption it was used to lessen the fallout. Without SU+J the files were corrupted (had other file contents inside) with SU+J they were truncated to 0 bytes, which was safer. Though the real problems that caused the corruption have now been solved on 2.2.4, SU+J is still more reliable in the long term now.

    I got totally unusable instance 100 kms away after serie of power outages. It was 2.2.3.
    I was able to restore config (using "remote arms" of my non IT colleagues), but is just answering pings. Nor WEB, nor ssh could be used to manage it.
    As it was on picture ther sent - it was with zero config after power recovery, no WAN\LAN defined, nothing.

    So what is best strategy to avoid corruptions?  I am going to force "fsck -y" every time it boots.


  • Rebel Alliance Developer Netgate

    Best strategy is to run 2.2.4, 2.2.3 didn't have complete fixes for the problems. 2.2.4 has fixes for the passwd/group issue as well as times when the config.xml could be zero/empty.



  • If the unit is on a UPS, wouldn't SU be preferable to SU+J? Particularly for flash based storage (mSATA)?



  • Asking it a different way… What is the advantage of SU+J over SU with pfSense?


  • Banned

    If there was a working fsck, the journaling would help with some cases of unclean unmount/hard reset. Sadly, the fsck is totally borked and produces a giant kaboom in that case. So, from my POV, there is absolutely no advantage whatsoever.

    https://redmine.pfsense.org/issues/4822



  • @doktornotor:

    If there was a working fsck, the journaling would help with some cases of unclean unmount/hard reset. Sadly, the fsck is totally borked and produces a giant kaboom in that case.

    Only with crap flash (though it's certainly very bad in that case). On a SanDisk CF in an ALIX, and a SanDisk SD in an APU, they survived a thousand power cycles each left rw mounted, SU+J, with some writing happening when power was lost.

    I took an affected CF card that fsck couldn't fix, dd'ed it to an img and booted it up in KVM, and fsck cleaned it just fine. Same when dd'ing it to another CF, was fine. Something screwy going on there with the problem flash, but didn't bother digging any further after confirming it doesn't happen minus SU+J.