Submitted by The third beta of FreeBSD 7.0 has been released. I cannot seem to find any information on changes between the second beta and this one. Additionally, the release schedule doesn’t even list a third beta.
The third beta of FreeBSD 7.0 has been released. I cannot seem to find any information on changes between the second beta and this one. Additionally, the release schedule doesn’t even list a third beta.
“I cannot seem to find any information on changes between the second beta and this one.”
Download and install BETA2, then use csup to update to the newest version, believe me, many things have been changed/fixed.
“Additionally, the release schedule doesn’t even list a third beta.”
Yes, sometimes schedule does not show much while things continue to happen behind the curtains, always check FreeBSD mailing lists for that: http://lists.freebsd.org
6.3-RELEASE will be released shortly after 7.0-RELEASE, its actually in BETA2 stage, but the schedule page for 6.3-RELEASE does not even exist: http://www.freebsd.org/releases/6.3R/schedule.html
Download and install BETA2, then use csup to update to the newest version, believe me, many things have been changed/fixed.
If I csup BETA3 and buildworld fails, will I still have a working system?
Edited 2007-11-20 19:09
Yes. As long as build installworld doesn’t fail or installkernel
Yes. As long as build installworld doesn’t fail or installkernel
Isn’t it “make installworld” and “make buildkernel” ?
“Isn’t it “make installworld” and “make buildkernel” ?”
Not exactly. Following the recommended update procedure, its
# make buildworld buildkernel
first, then
# make installkernel
followet by a restart and boot -s to start with the new kernel in single user mode, and then
# make installworld
to complete the installation.
Refer to the FreeBSD handbook because I didn’t mention mergemaster, KERNCONF etc. here.
While the build* target may fail without any impact on the system, the install* ones can, allthough after “make installkernel” you can reboot with your previous kernel (kernel.old). If “make installworld” fails… good luck. 🙂
You forgot something just before and after “# make installworld”
The correct steps are:
1) # make buildworld buildkernel
2) # make installkernel
3) Reboot in Single User Mode, either pressing F4 or boot -s
4) # mergemaster -p
5) # cd /usr/src
6) # make installworld
7) # mergemaster
Then reboot
Greets!
“You forgot something just before and after “# make installworld”
“
No no Sir, I didn’t forget it, I just didn’t mention it. 🙂
Your listing is more complete than mine, but it would be nessessary to insert
0) # cd /usr/src
at the first place. 🙂
I just wanted to show where the critical stages of the installation are located (most critical at installworld). Forgetting the mergemaster could result in outdated configuration files, for example. Furthermore, there is the option of having KERNCONF= set to a custom kernel configuration file. Reading the handbook before starting the update procedure is highly recommended in any way.
“0) # cd /usr/src
at the first place. :-)”
Indeed!
An I should point out a typo I wrote on step 3.
It should be “either pressing number 4, or boot -s”
And not pressing F4 🙂
The last minute import of a few things caused RELENG_7 to regress in alot of places. The quick builds are because it’s still not known if 6.3 or 7.0 will be released first. The goal being to get 7.0-RELEASE out before January 1st, if showstoppers keep popping up out of nowhere like they have been, it won’t be the case.
Nice story, but did you actually read any of the mailing lists?
>The last minute import of a few things caused RELENG_7 to regress in alot of places.
This is absolute nonsense! Neither there were last minute imports nor is there regress in *a lot* of places.
Everybody can read it of course,
http://lists.freebsd.org/pipermail/freebsd-stable/
http://lists.freebsd.org/pipermail/freebsd-current/
http://lists.freebsd.org/pipermail/cvs-src/
> if showstoppers keep popping up out of nowhere like they have been, it won’t be the case.
Huh? Maybe you should start your urband legends in kindergarten. There are of course *bugs* but hardly showstoppers. If you’re a tester, you should maybe check your hardware first.
I for one, have been using beta’s 1 ==> 3 with little or no problems whatsoever…
Smok’in fast and stable for me.
yes, and I have talked to a number of freebsd developers and core team members; it’s normal for people to import things into HEAD just before a new -STABLE branch is made.. There’s a rush of developers importing things from their perforce branches so it can make it into 7-STABLE and not be stuck in 8-STABLE (when it gets branched.)
The gcc 4 import set things back considerably, this is a fact. There were enough breakages to cause re@ to wait until another version was released that would fix the bigger bugs.
There are regressions in various drivers, particularly the NIC drivers (as they were removed from being under the GIANT lock), and some with regards to interrupt filtering. There is also strange panic and segfault conditions that arise at seemingly random times. As an example, a panic on sysctl, panics with acpi states. If you’d like, look at the pr database.
The biggest problems seem to be the ones that can’t be reproduced after they happen. Since dumpdev is off by default there is no kernel dump so nothing to go on other then ‘it paniced’.
They are being fixed, of course, when they come up, but 6.3 is still a possibility for being released before 7.0.
So will FreeBSD-6 be faster in terms of -RELEASE date than FreeBSD-7? 🙂
“They are being fixed, of course, when they come up, but 6.3 is still a possibility for being released before 7.0.”
I want to setup a new FreeBSD system for my home use and I’m not sure if I should install 6.2 now (and update to 6.3 when it’s released) or wait until 7.0, or wait until 6.3 to avoid the system update… hard decision. I’m not sure if 7.0-BETA3 is already a good point to start.
I’m running 7-beta2 on 2 servers at home that get moderate workouts and I had it running on my desktop without issue, but needed some Linux only apps and the nvidia driver doesn’t support 7 yet. That being said, it worked without issue for a couple of weeks.
Edited 2007-11-21 00:54
the nvidia driver doesn’t support 7 yet
I am running nvidia-driver (from ports) in RELENG_7 with no problem.
[/i] the nvidia driver doesn’t support 7 yet. [/i]
I beg to differ.
odin[47]% uname -r
7.0-BETA2
odin[48]% pkg_info | grep nvidia
nvidia-driver-100.14.19 NVidia graphics card binary drivers for hardware OpenGL ren
I’m using FreeBSD 7 since some months (current) together with nVidia driver without any problems.
just curious, i know there were some requests from nvidia in order to implement the 64bit drivers. how’s the status on this one? any news?
>The gcc 4 import set things back considerably
Again nonsense, the gcc import did occure ‘long’ time ago.
>There were enough breakages to cause re@ to wait until another version was released that would fix the bigger bugs.
(November 16th, 2007)
Ports: 17746
Ports without maintainer : 4204 (23.7%)
Build errors (total): 1034 (5.8%)
So again nonsense, there are some ports of course which do not compile properly with GCC4, but it’s hardly a problem.
>There are regressions in various drivers, particularly the NIC drivers
There are *some* regressions in *some* NIC drivers.
Btw. I’m reading the mailinglists and I’m using FreeBSD 7. Furthermore I do know some developers. It’s of course beta, it’s in development, but it’s in fact a very mature development so far without any bigger showstoppers at all.
>There is also strange panic and segfault conditions that arise at seemingly random times. As an example, a panic on sysctl, panics with acpi states. If you’d like, look at the pr database.
There is nothing strange in faulty hardware imho. You will have those kind of PRs all the time on one or two machines, so what? Panic with acpi states? Try a different bios, oh wait … it’s the bios. There will be always a *minority* of people with some problems especially those with exotic hardware like laptops.
Real problems: e.g. some stability issues in ZFS, but then again ZFS isn’t ready for prime time so it’s no showstopper at all.
There is nothing strange in faulty hardware imho.
Geeh, blaming it on the hardware or posters? Sticking your head in the sand is *not* going to solve bugs. I have seen many iterations of release cycles of various BSD systems, and regressions do happen. That’s why there are beta releases. Even good systems have their share of bugs in the beta stages. Get over it.
If you look in GNATS or the lists, you’ll see there still are plenty of serious bugs. Fortunately, the developers prefer to fix these bugs, rather than fighting with the bug reporters or their users. Users provide viable feedback, because they have hardware that you do not have and do things that you do not do. Don’t flame them away.
Edited 2007-11-21 12:48
FreeBSD has been such a pleasure to use. I have never found it so easy before to setup wireless.
Windows or Linux have both required me to install drivers for my card, it just eases the pain when its out-of-the-box compatible, like my Atheros card. I know that Linux now has it natively but it’s in alpha form at best… from what I can tell it doesn’t work with many cards yet… and unfortunately mine doesnt work.
I’m glad to see FreeBSD is moving along nicely.
“Windows or Linux have both required me to install drivers for my card, it just eases the pain when its out-of-the-box compatible, like my Atheros card.”
Personally, I have the opinion thatt the OS should support the hardware (not the other way round: the hardware’s manufacturer providing drivers for choosen OSes), but this will only work where the hardware is compliant to a certain standard or where the hardware’s manufacturer provides the specifications neccessary for the OS developers to create drivers by their own. You may think I’m a bit extreme, but I tend to say: Hardware that is not supported by standard means is not worth to be used (atleast by myself), so I got very picky about what I’m going to buy. With this philosophy in mind, I never had a problem with a hardware component not working as expected.