FreeBSD 11.0 beadm works as advertised

Oko

Oko

Some of you know that I run bunch of FreeBSD based file servers and jail hosts. For the past several years I have preferred TrueOS (server PC-BSD release) over vanilla FreeBSD for the following reasons

  1. Installer could utilize ZFS for root partition
  2. pc-sysinstall script and customizable configuration files were superior for automatics, installation.
  3. sysutils/beadm was integrated with the Grub bootloader used by TrueOS and selecting different boot kernel/userland was trivial.
  4. update/upgrade manager
  5. Life Preserver (management tool for ZFS snapshots and replication)
  6. Warden (Jail management)
  7. Sane[r] defaults
Life Preserver turned to be very buggy so I ended up using sysutils/zfsnap. Warden was suddenly dropped in favour of superior software sysutils/iocage but other than that TrueOS worked as advertised. Really pretty darn good product. Unfortunately IXSystem decided to kill it. Updates are no longer build quarterly and IXSystem is trying to push people to the pre-alpha quality product build on top of 12.0 current. Consequently I started planning migration to vanilla FreeBSD 11.0.

A few days ago I came across surprisingly useful

https://distrowatch.com/weekly.php?issue=20161107#freebsd

but largely negative review of FreeBSD. Most of DWW reviews are very low quality and not very useful. I didn't take DWW statements at face value. I just did my typical root on ZFS mirror installation of FreeBSD and I can say that I am pretty disappointed.

Yes FreeBSD installer has now ability to install on the ZFS mirror but it is not really taking advantage of it as sysutils/beadm is not the part of the base. I manually installed it but I realized that there is no integration with upgrading process. Namely one will have to take snapshot manually before the upgrade. Even worse. I don't see how would one select an earlier snapshot during the booting process which means that beadm has no effect on the boot loader. I don't need graphical menu which PC-BSD had but curses menu selection during boot is more or less industry standard (Red Hat exposes Grub menu during boot and enables you to select older versions of the kernel). Of course if the boot process completes I could possibly set different booting snapshot using beadm command line but what if the booting can't be completed with updated kernel.

This is pretty disappointing. I have not had a chance to test the second DWW which claimed that binary updating is actually broken but if that is the case than 11.0 is really not mature product.

I also see zero documentation about this in the official Handbook. IMHO having a section on beadm and LDAP is far more important than having the documentation about PDF viewers or even printer installation.
 
On my FreeBSD 10.3 and 11.0 boxes the boot loader offers switching the BE as a menu item (7 IIRC), so this works exactly like on TrueOS. (and saved my butt 2 weeks ago when I fat-fingered some updates on a gateway...)

The automated creation of BEs when updating is implemented by the TrueOS updater (pc-updatemanager) - which is only a wrapper script around beadm, freebsd-update and pkg. Nobody is stopping you from writing a small shellscript that first creates a BE and then starts updates. Should be no more than a one-liner for a quick&dirty solution...

As for TrueOS:
I'm using the "new" TrueOS with Lumina on my desktop machines at work and home. Apart from some glitches with parts of Lumina which are under heavy development, I haven't had any major Issues.
Both my systems are skylake-based with no additional graphics card in the work machine, so having Graphics working OOTB is _very_ convenient.
LifePreserver is still quite limited and TBH I haven't looked much at it and just used the same zfSnap-setup I'm using on my servers. For replication/backup I'm using AMANDA, so no need for any additional backup solution on the client.

The quality of the CURRENT-branch is still quite high, especially compared e.g. to testing branches on most linux-distros. Especially since systemd you are fighting fires left and right and end up with a broken system every few weeks. Even debian stable (which i was running for >10 years on my servers) broke several times after the introduction of systemd...
On servers I might stay with vanilla FreeBSD, even if it's just for consistency and because I'm also a bit paranoid about stability (I like to sleep well..), but for desktop usage the switch to CURRENT was the right step IMHO, especially when it comes to hardware support.
 
  • Thanks
Reactions: Oko
sko said:
On my FreeBSD 10.3 and 11.0 boxes the boot loader offers switching the BE as a menu item (7 IIRC), so this works exactly like on TrueOS. (and saved my butt 2 weeks ago when I fat-fingered some updates on a gateway...)
Click to expand...
I can confirm this. Thank you so much for a very useful answer! I edited the title of my question accordingly and left a negative comment on DWW about their review.
 
BTW: About the TrueOS Handbook:
This is supposed to be a Handbook for J. Random Users aunt Irma, not for the experienced FreeBSD Admin who runs TrueOS on his Desktop because he is too lazy/busy to build a desktop installation from scratch.
If I'd tell my Mother to read the FreeBSD Handbook to figure out how to use her TrueOS or better say the Lumina DE, she wold probably disinherit me... The TrueOS handbook covers a lot of the basics that are taken as granted in the FreeBSD handbook, and goes into just enough detail on most topics to provide a good starting point for the interested (new) user to get something running manually, configure the system/DE, fix minor problems and use/understand (at least enough of) the manpages to carry on.
I think this is exactly the right way. More experienced users will resolve to the quite comprehensive and excellent FreeBSD handbook, but for someone who just wants to get to his/her "real" work and not be bothered with every tiny detail of the OS, the TrueOS handbook is a perfect entry point.
 
sko said:
BTW: About the TrueOS Handbook:
Click to expand...
I never made any comments about PC-BSD/TrueOS Handbook. I was criticizing FreeBSD handbook and made that criticism public on many occasions. The gist of my critique is that FreeBSD handbook is way too ambitious for the size of the project and the current ever declining man power in BSD world which has very adverse affect to its quality. Everyone has to learn to leave within her/his means. FreeBSD community is not an exception.
 
Sorry, I assumed in the last paragraph of your initial posting you were referring to the TrueOS handbook.
My experience with the FreeBSD handbook was quite positive so far. Even for more special edge cases at least I got some hints where to get the Information I needed. But I have to admit also I often ran into outdated information. I think this might be mainly caused by the sheer size of the handbook and the fact that, as you stated, the manpower seems to be declining (at least relative to the size of the ever-growing handbook). Maybe it would be wise to get rid of sections that haven't been updated or reviewed within a reasonable time to prevent the accumulation of more and more outdated information just because nobody dares to just delete something.


Another addition to the reservations regarding the CURRENT branch: In the just released "BSD Now" Episode, Scott Long from Netflix states, that they will be running 12-CURRENT on all FreeBSD servers in their Network [1]. Mainly because they want/need to track the latest changes to Networking improvements (network stack, hardware support), to fulfill their bandwidth needs. If Netflix relies on it for its whole CDN, it cant be that bad ;)


[1] http://www.jupiterbroadcasting.com/104596/playing-the-long-game-bsd-now-167/ (@ ~26 mins into the video)
 
sko said:
Another addition to the reservations regarding the CURRENT branch: In the just released "BSD Now" Episode, Scott Long from Netflix states, that they will be running 12-CURRENT on all FreeBSD servers in their Network [1]. Mainly because they want/need to track the latest changes to Networking improvements (network stack, hardware support), to fulfill their bandwidth needs. If Netflix relies on it for its whole CDN, it cant be that bad ;)
Click to expand...

Netflix is pushing packets 100 Gigabit per second and higher. They also have an army of full time paid engineers working for them. I am a one man IT department for the research group of 60 people trying to spend as little time as possible fixing computers and more time doing science.
For us even 10 Gigabit is more than we currently have so I don't need to be alpha tester neither for Netflix nor for IXSystems.
 
Oko said:
A few days ago I came across surprisingly useful

https://distrowatch.com/weekly.php?issue=20161107#freebsd

but largely negative review of FreeBSD. Most of DWW reviews are very low quality and not very useful. I didn't take DWW statements at face value. I just did my typical root on ZFS mirror installation of FreeBSD and I can say that I am pretty disappointed.
Click to expand...
A snarky comment I make when installing a lot of software (inside and outside of FreeBSD) is "Who the heck tested this? Anybody?"

That is probably a bit harsh sometimes, but I see 4 separate issues:

1) For a specific piece of hardware, it is possible nobody tested it because nobody running the release had that hardware. Mostly, this is systems that either do something wrong before handing control over to FreeBSD (ACPI errors seem to be a popular spot, though systems with broken BIOS and/or UEFI booting are gaining ground rapidly) or because the system implements something properly, but in a way different from the vast majority of other systems and FreeBSD never encountered that and doesn't know how to deal with it. This is probably the ones that lose us the most users, because they downloaded FreeBSD to try it and couldn't get it to work. Without a developer with the same hardware, this is very hard to debug remotely. Adding some data-gathering tools to diagnose boot problems and get useful info to the developer(s) would probably help.

2) All of the kits that come out before an X.0 release is declared STABLE, or before a version bump from version X.A to X.B, come with a warning saying "don't use this in production". For a company that can afford a test / staging system, that makes sense - but many of those people also have the experience to locate where a particular bug might be if they run into a problem. The user with a single system, whether hobbyist or commercial, takes that warning to heart and doesn't install the kits and thus doesn't find bugs. So when they run into a problem and go "Who tested this?", again the answer may well be "nobody". And then they run into problems like this, where a very popular controller is no longer detected in 11.0.

3) A company wanting to deploy an upcoming product usually doesn't have the ability to slip their schedule because the FreeBSD release schedule slips. Slips are a fact of life and generally happen for very good reasons, and the situation here in FreeBSD seems a lot better than what I've read about Linux releases. RC9? If it takes 9 tries to get to a point where something is of enough quality to be released, I think it went from Alpha -> Beta -> RC way too fast. But maybe they start with RC1 - I don't know. But again, some hardware doesn't get tested.

4) Companies with loads of servers and hundreds of gigabits of traffic certainly have both the hardware and manpower to spare to find and fix problems that affect them - they may even be committers themselves. But at that scale, hardware, operating system, and application software are a monoculture (or pretty darn close). Again, this covers only a small part of the supported hardware, and if they don't have that hardware or don't use a specific FreeBSD feature, they won't find problems in things they don't use.

Unfortunately, I don't have any solutions. I do have some ideas:

A) As I mentioned above, some pre-boot and boot-time tools that gathered information in a format that would help developers understand a no-boot issue or missing device issue might be useful, if there was buy-in from both users and developers.

B) Perhaps the "Don't use this in production" warning could be changed to a "We do not recommend this for production and cannot guarantee correct operation, but if you have any way at all to test this, even on different hardware, we would appreciate any feedback so we can provide a high-quality release that will meet your needs and exceed your expectations".

C) Have some way of getting the feedback from the above paragraph express-routed to the developers. In bugzilla, maybe a box for "Important problem with an upcoming release" could trigger mailing a summary to a list of developers? This would depend on the function not being abused, but if it is only selectable for the lifetimes of specific snapshot / Alpha / Beta / RC releases, that would limit it. This will need the support of the maintainers of the FreeBSD bugzilla to make sure all of those versions are available for bug reports (sometimes they're not in there, even for a little while after a RELEASE).

D) Have some "Hands-on with the latest FreeBSD" sessions to have people (ideally existing FreeBSD users with varying amounts of experience, as well as some with no FreeBSD experience) install / upgrade / exercise the upcoming release at the RC point. Even better would be if there could be a developer "on call" via video chat or something if problems are encountered. It is important to passively watch as well as solicit opinions, because people often won't say anything if they think they know how something should work, while watching will show where they're running into issues and getting frustrated. I'd be glad to host a lab with a half dozen or so systems for people to play with, but I'm in New York, so there's almost definitely someone with many more systems they could make available, in a nicer space. But this ties in with pinning down the schedule, as getting the space / hardware / on-site people / developer(s) scheduled will probably take months. Remember, users of some other operating systems pay for this kind of thing - the FreeBSD selling point is that it's free and helps improve the software.
 
Oko said:
I also see zero documentation about this in the official Handbook. IMHO having a section on beadm and LDAP is far more important than having the documentation about PDF viewers or even printer installation.
Click to expand...
You could press for the OpenBSD "no commit without documentation" policy. Or you could write some. Or you could ask others to write some. Or lobby the Foundation.

As far as the stuff that is there, others saw a need and did something about it. Volunteers cannot be assigned to a piece of work, and nobody has seen fit to write those sections. Benedict Reuschling aptly said that the fact that it is not there probably means it is a difficult job. Consequently, the last job might require more commitment. As I've said before, when the phrase "somebody should do something" comes up, I ask "What about you? You're somebody."
 
wblock@ said:
You could press for the OpenBSD "no commit without documentation" policy. Or you could write some.
Click to expand...
Yes I am a big believer in OpenBSD's "no commit without documentation" policy. I also subscribe to the mantra shut up and hack or in this case write the documentation which is missing and submit it to Warren :)
 
You must log in or register to reply here.
Back
Top