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.
Trackback from your site.
Comments (25)
Cool, Thanks a lot everyone!
You’re welcome
Thank you very much:)
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.
Thanks for the report! A bug was located and fixed in SVN. In the mean time, this workaround is valid.
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.
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.
That sounds specific to a desktop. In which window manager(s) does this occur?
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.
My battery problem seems to exist for KDE as well.
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/index.php/Laptops.
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+0×107
#2 0xffffffff80b5284b at cpu_initclocks_bsp+0x3cb
#3 0xffffffff807ea0c0 at initclocks+0×20
#4 0xffffffff807e7707 at mi_startup+0×77
#5 0xffffffff8029f71c at btext+0x2c
Uptime: 1s
Automatic reboot in 15 seconds – press a key on the console to abort
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.
I have XFCE and battery indicator is ok.
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/index.php/Laptops.
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).
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/2011-09/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.”
Thanks for posting the link!
Thank you!
There’s an error in the link to the handbook page at the ftp server should be :
ftp://ftp.pcbsd.org/handbook/9.0/
instead of
ftp://ftp.pcbsd.org/pub/handbook/9.0/
No, the correct location includes the pub directory.
Many thanks for publishing this handbook with an epub format ! So I can read the handbook on my Kobo ebook reader !
You’re welcome. Let us know if it renders well in the Kobo.
Unable to load page
Problem occurred while loading the URL ftp://ftp.pcbsd.org/pub/handbook/9.0/handbook_en_ver9.0.pdf
Links are down?!
Is this still occurring for you?