Jan
09

PC-BSD 9.0 Users Handbook

The PC-BSD 9.0 Users Handbook is complete and available in several formats:

  • as an icon on the 9.0-RELEASE desktop (which should be announced as available in the next day or so)
  • in HTML, PDF, and epub formats from the handbook page of the ftp server
  • as a Kindle version which should be available from Amazon some time this week
  • FreeBSD Mall will be selling a “dead tree” version; more details on pricing and ordering should be available on their website in a few days

Let me know if you are interested in translating this version of the Handbook so I can send you the source and make sure that the translations mailing list is aware of the pending translation.

Share This Post:
  • Digg
  • Facebook
  • Twitter
  • email
  • LinkedIn
  • Slashdot

Written by dru. Posted in 9.0, handbook

Trackback from your site.

Comments (25)

  • former ubuntu user
    January 9, 2012 at 1:17 pm |

    Cool, Thanks a lot everyone! :)

    • January 9, 2012 at 1:23 pm |

      You’re welcome :-)

  • Alternator
    January 10, 2012 at 12:36 pm |

    Thank you very much:)

  • Anders
    January 11, 2012 at 5:24 am |

    This is a bit off-topic about the handbook, but since you mentioned the 9.0-RELEASE desktop, I went ahead and downloaded the latest version of PC-BSD 9 (the 9.0-RELEASE) from pcbsd​.org. I started the installation, but a problem soon occurred:
    The installation halts in the beginning, before running the newfs commands, with the following message: “gpart bootcode –b /boot/boot ada0sX: no such geom.” The installer seems to generate (in my case) the command
    “gpart bootcode –b /boot/boot ada0s3” when the correct command should be
    “gpart bootcode –b /boot/boot ada0p3”.
    The only way to continue installation is to copy the /usr/share/pc-sysinstall/ directory to i.e. /root/pcbsd/, modify /root/pcbsd/backend/functions.sh and comment out all if statements containing exit_err, then modify /root/pcbsd/backend/functions-bsdlabel.sh and comment out line 408 (rc_halt “gpart bootcode –b /boot/boot ${_wSlice}”). This line creates the “gpart bootcode –b /boot/boot ada0s3” which halted the installation. The next thing to do is to copy the /usr/sbin/pc-sysinstall script to i.e. /root/pc-sysinstall_script.sh and modify it by changing PROGDIR (on line 41) to /root/pcbsd, save the changes, change the “mode” of /root/pc-sysinstall_script.sh so that root can execute the script, and you SHOULD be good to go. At least that’s how I got it to work. It’s far from an ideal solution, but as a temporary solution it SHOULD work.

    • January 11, 2012 at 6:43 am |

      Thanks for the report! A bug was located and fixed in SVN. In the mean time, this workaround is valid.

      • January 11, 2012 at 7:07 am |

        Just to clarify: this bug will be fixed for RELEASE. If you’re using Mac, you should not download from the ftp site until RELEASE is announced in order to make sure all of the mirrors have the correct ISOs.

        • Anders
          January 11, 2012 at 10:10 am |

          Okay. Yes, I am using a Mac.
          One other small thing: The battery indicator doesn’t seem to work. It says “Laptop battery discharging (0.0%), even though my computer is connected to a power source and is fully charged. This also applied for (at least) RC2 and RC3 as well. It’s not a big problem, but I just wanted to make aware of it.

          • January 11, 2012 at 10:13 am |

            That sounds specific to a desktop. In which window manager(s) does this occur?

            • Anders
              January 11, 2012 at 10:19 am |

              Right now I am using GNOME. I chose not to install other window mangers as of right now. I’ll install KDE and the other supported window managers later on today and check if the battery indicator works on the other window managers.

              • Anders
                January 11, 2012 at 12:32 pm |

                My battery problem seems to exist for KDE as well.

                • January 16, 2012 at 5:58 am |

                  Thanks for the update. It may be ACPI related which, being hardware specific, requires a bit of experimentation. There are pointers to get you started at http://​wiki​.pcbsd​.org/​i​n​d​e​x​.​p​h​p​/​L​a​p​t​ops.

                  • Anders
                    January 16, 2012 at 9:54 am |

                    Thanks for the help. I suspect it has something to do with APCI.

                    I ran the acpiconf command to get some information from the system, and here’s the output:
                    Design capacity: 0 mWh
                    Last full capacity: 0 mWh
                    Technology: primary (non-rechargeable)
                    Design voltage: 0 mV
                    Capacity (warn): 0 mWh
                    Capacity (low): 0 mWh
                    Low/warn granularity: 0 mWh
                    Warn/full granularity: 0 mWh
                    Model number:
                    Serial number:
                    Type:
                    OEM info:
                    State: not present
                    Present voltage: 12477 mV

                    I’ve spent the last few days looking around in different forums, and one of the advices I saw regarding ACPI problems, was to try

                    panic: no usable event timers found!
                    cpuid = 0
                    KDB: stack backtrace
                    #0 0xffffffff808680fe at kdb_backtrace+0x5e
                    #1 0xffffffff80832cb7 at panic+0x107
                    #2 0xffffffff80b5284b at cpu_initclocks_bsp+0x3cb
                    #3 0xffffffff807ea0c0 at initclocks+0x20
                    #4 0xffffffff807e7707 at mi_startup+0x77
                    #5 0xffffffff8029f71c at btext+0x2c
                    Uptime: 1s
                    Automatic reboot in 15 seconds — press a key on the console to abort

                  • Anders
                    January 19, 2012 at 11:24 am |

                    Just for the record, I installed FreeBSD 8 on my mid 2009 MacBook Pro just to see if my battery problem existed there. But once I booted FreeBSD 8, it seemed like the battery indicator and almost everything else (except my wireless bwn driver) was working as expected. I then tried to upgrade to FreeBSD 9, but then my problem seemed to come back. So I don’t know if my ACPI driver isn’t fully supported on FreeBSD 9 or something.

              • goran
                January 14, 2012 at 12:32 pm |

                I have XFCE and battery indicator is ok.

          • January 24, 2012 at 7:53 am |

            Replying here as a bit more room. Let us know if you have a chance to experiment with ACPI sysctl settings and which ones improved the situation. Info to get you started is at the beginning of this page: http://​wiki​.pcbsd​.org/​i​n​d​e​x​.​p​h​p​/​L​a​p​t​ops.

            • Anders
              January 24, 2012 at 9:03 am |

              Yesterday, I opened up a forum post on the FreeBSD forums and described my problem there. A tip another user sent me was to add the following to /boot/loader.conf: “debug.acpi.max_tasks=“128”. It worked to some extent; when I boot up PC-BSD on battery source, the system behaves the way it should, it displays the time until empty, XX% remaining, etc. However, if I connect a power source, the system does not necessarily notice it, so the battery icon, as well as acpiconf –i 0 says “discharging” (with the “Remaining capacity” increasing). If I happen to connect my Mac to a power source and then boot PC-BSD, the battery indicator (on GNOME, KDE, XFCE, etc) and acpiconf –i 0 say charging, as they are supposed to. But if I then disconnect the Mac from the power source, the battery indicator on GNOME, KDE, and so on says “Laptop is fully charged”, while acpiconf –i 0 says:

              Design capacity: 65000 mWh
              Last full capacity: 65700 mWh
              Technology: secondary (rechargeable)
              Design voltage: 10950 mV
              Capacity (warn): 250 mWh
              Capacity (low): 100 mWh
              Low/warn granularity: 10 mWh
              Warn/full granularity: 10 mWh
              Model number: bq20z451077VCDEF0123456789ABCDE
              Serial number:
              Type: LIONz451077VCDEF0123456789ABCDE
              OEM info: SMPNz451077VCDEF0123456789ABCDE
              State: high
              Remaining capacity: 95%
              Remaining time: unknown
              Present rate: 24127 mW
              Present voltage: 12161 mV

              which is a whole lot better than it would be without the
              debug.acpi.max_tasks=“XXXX” in /boot/loader.conf.

              My sysctl now reads (with results affected by the debug.acpi.max_tasks=“128”):
              hw.acpi.supported_sleep_state: S3 S4 S5
              hw.acpi.power_button_state: S5
              hw.acpi.sleep_button_state: S3
              hw.acpi.lid_switch_state: NONE
              hw.acpi.standby_state: NONE
              hw.acpi.suspend_state: S3
              hw.acpi.sleep_delay: 1
              hw.acpi.s4bios: 0
              hw.acpi.verbose: 0
              hw.acpi.disable_on_reboot: 0
              hw.acpi.handle_reboot: 1
              hw.acpi.reset_video: 0
              hw.acpi.cpu.cx_lowest: C1
              hw.acpi.acline: 1
              hw.acpi.battery.life: 93
              hw.acpi.battery.time: –1
              hw.acpi.battery.state: 0
              hw.acpi.battery.units: 1
              hw.acpi.battery.info_expire: 5

              So, to make a long story short, all I’ve really done is to add
              bebug.acpi.max_tasks=“128” to /boot/loader.conf. (I’ve tried to increase that number to 2048 without much visible effect).

              • Anders
                March 23, 2012 at 2:00 pm |

                Hey! I know this is an old post, but the other day I browsed around, still looking for a more “professional” solution to my ACPI problem, and I came across this website, where the probable cause of the problem is described: http://osdir.com/ml/freebsd-bugs/201109/msg00170.html. According to this site, “The problem should occur on any system with a battery using the cmbat
                interface, which dispatches a large number of calls via AcpiOsExecute during
                initialization. This fills up the task queue, which results in the call to
                acpi_cmbat_init_battery getting dropped due to the queue being full, which
                results in the bif information not being properly initialized. Because the
                cmbat driver only reads this information at initalization, the driver will
                incorrectly report the battery as not being present.

                Similar issues with other ACPI features may have a similar root cause.
                >Fix:
                Setting debug.acpi.max_tasks to a high value (I used 128) is a stable
                workaround, and will restore functionality.”

                • March 26, 2012 at 6:17 am |

                  Thanks for posting the link!

  • sura-j
    January 14, 2012 at 5:47 pm |

    Thank you!

  • Mich
    January 27, 2012 at 11:19 pm |
    • January 30, 2012 at 5:56 am |

      No, the correct location includes the pub directory.

  • Zplay
    February 2, 2012 at 8:46 am |

    Many thanks for publishing this handbook with an epub format ! So I can read the handbook on my Kobo ebook reader !

    • February 2, 2012 at 9:18 am |

      You’re welcome. Let us know if it renders well in the Kobo.

    • May 28, 2012 at 4:31 am |

      Is this still occurring for you?

Leave a comment

*

Please leave these two fields as-is:

Help the Project, Donate Today!