FreeBSD 7.1 RC1

Yamagi

Possessed With Psi Powers
Teammitglied
So, lange erwartet, nun ist er da: Der erste Release Candidate zu FreeBSD 7.1. Wir immer ist die Bitte, diesen ausführlich zu testen und Bugs an das FreeBSD Projekt zu melden. Dies gilt insbesondere für Probleme mit USB im loader, siehe dazu auch die E-Mail weiter unten. Das Update auf den RC1 ist per freebsd-update möglich und natürlich auch per make buildworld. Vor dem Release wird noch mindestens ein weiterer Release Candidate folgen.

Code:
From: Ken Smith <kensmith@cse.Buffalo.EDU>
To: freebsd-stable <freebsd-stable@freebsd.org>
Date: Tue, 09 Dec 2008 21:39:26 -0500
X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port
Subject: FreeBSD 7.1-RC1 Available...

[-- PGP Ausgabe folgt (aktuelle Zeit: Mi 10 Dez 17:28:16 2008) --]
Warning: using insecure memory!
gpg: Unterschrift vom Mi 10 Dez 03:39:14 2008 CET mittels DSA-Schlüssel ID
+29AEA7F6
gpg: Korrekte Unterschrift von "Ken Smith <kensmith@cse.buffalo.edu>"
gpg:                     alias "Ken Smith <kensmith@freebsd.org>"
gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur!
gpg:          Es gibt keinen Hinweis, daß die Signatur wirklich dem vorgeblichen
+Besitzer gehört.
Haupt-Fingerabdruck  = 4AB7 D302 0753 8215 31E7  F1AD FC6D 7855 29AE A7F6
[-- Ende der PGP-Ausgabe --]

[-- Die folgenden Daten sind signiert --]


So...  Two show-stoppers, one Security Advisory, and one "Gee.  Did we
really implement that new interface that way?  That needs a bit more
work." later...

FreeBSD 7.1-RC1 is now available, the first of the Release Candidates.
There will be at least one more Release Candidate before the release so
the release itself is likely around 3 weeks from now IF no new
show-stoppers are uncovered during testing.

In addition to general testing we're looking for information about
potential problems with the boot loader.  There has been traffic here
about problems but the reports haven't helped narrow down the causes
yet.  So far it seems to be related to USB keyboards and at least so far
systems with more than one processor in them.  More data points like
cases where a USB keyboard was not involved as well as if possible
things like which motherboard it is might help us narrow down the cause.
Testing on a variety of motherboards, of varying ages and manufacturers
would help.

And a late arrival that's not possible to test without the packages,
sysinstall's issues with excessive disc swapping when installing large
sets of packages off the CDROMs should be fixed.  Given the package
layout it should ask for a disc no more than once.  Testing to make sure
that's working would be appreciated.

NOTE: If updating from a 7.0 or earlier system due to a change in the
Vendor's drivers certain Intel NICs will now come up as igb(4) instead
of em(4).  We normally try to avoid changes like that in stable branches
but the vendor felt it necessary in order to support the new adapters.
See the UPDATING entry dated 20080811 for details.  There are only 3 PCI
ID's that should have their name changed from em(4) to igb(4): 0x10A7,
0x10A9, and 0x10D6.  You should be able to determine if your card will
change names by running the command "pciconf -l", and for the line
representing your NIC (should be named em on older systems, e.g. em0 or
em1, etc) check the fourth column.  If it says "chip=0x10a7" (or one of
the other two IDs given above) you will have the adapter's name change.

The ISO images and FTP install trees are available on the FreeBSD Mirror
sites.  Using the primary site as an example:

  ftp://ftp.freebsd.org/pub/FreeBSD/releases/${arch}/ISO-IMAGES/7.1/

where ${arch} is one of amd64, i386, ia64, pc98, powerpc, or sparc64.
The ISOs for amd64, i386, and sparc64 include what is expected to be the
final package set.  For all architectures the ISOs with "disc" in their
names are CDROM-sized, if you intend to install a variety of packages
during installation you will need all three.  For amd64 and i386 there
is a gzip-ed iso with "dvd" in its name which is DVD-sized.  It contains
everything (install bits, livefs, docs, and packages) and can be used if
your machine has a DVD drive in it.

If you would like to do a source-based update to 7.1-RC1 from an already
installed machine you can update your tree to RELENG_7_1 using normal
cvsup/csup methods.  Note that due to an unfortunate side-effect of the
"real" source code repository now being in SVN it will look like all
files have a new version so mergemaster may be a bit tedious.

The freebsd-update(8) utility supports binary upgrades of i386 and amd64
systems running earlier FreeBSD releases.  Systems running 7.0-RELEASE,
7.1-BETA, or 7.1-BETA2 can upgrade as follows:

# freebsd-update upgrade -r 7.1-RC1

During this process, FreeBSD Update may ask the user to help by merging
some configuration files or by confirming that the automatically performed
merging was done correctly.

# freebsd-update install

The system must be rebooted with the newly installed kernel before continuing.
# shutdown -r now

After rebooting, freebsd-update needs to be run again to install the new
userland components, and the system needs to be rebooted again:

# freebsd-update install
# shutdown -r now

Users of Intel network interfaces which are changing their name from "em" to
"igb" should make necessary changes to configuration files BEFORE running
freebsd-update, since otherwise the network interface will not be configured
appropriately after rebooting for the first time.

Users of earlier FreeBSD releases (FreeBSD 6.x) can also use freebsd-update to
upgrade to FreeBSD 7.1, but will be prompted to rebuild all third-party
applications (e.g., anything installed from the ports tree) after the second
invocation of "freebsd-update install", in order to handle differences in the
system libraries between FreeBSD 6.x and FreeBSD 7.x.

--
                                                Ken Smith
- From there to here, from here to      |       kensmith@cse.buffalo.edu
  there, funny things are everywhere.   |
                      - Theodore Geisel |


[-- Ende der signierten Daten --]
 
Uh, das mit dem USB-Zeuges klingt, als sollte ich mal testen. Ich hoff, dass ich am WE dazu komme...
 
Wie lang ist der Portstree jetzt im Freeze/Slush? 2 monate oder 3? Noch drei Wochen Warten? Mindestens?

PkgSrc macht da einen ganzen Vierterljahreszyklus durch...
 
Der Portstree ist schon seit August im Freeze und anschließenden Slush. Drei Wochen wird er es auch sicher noch bleiben, denke ich. Langsam nervt das wirklich ein wenig.
 
Bei mir will freebsd-update beim Update meine Benutzer aus /etc/passwd loeschen, wenn ich sag der solls lassen bricht die Installation ab. ??????????
Ich probiers jetzt noch ein 2.es mal.
 
Ein Glück sind meine Ports keine sweeping commits. Ich kann mein Zeug ohne Probleme aktualisieren.

Schön, dass es jetzt wirklich auf's Release zugeht.
 
Da laut http://www.freebsd.org/releng/index.html 7.2 schon im Februar erscheinen soll, müssten sie ihn ja dann gleich wieder einfrieren.
Wobei ich mal denke, dass die Info veraltet ist, denn bei einem Release gegen Weihnachten von 7.1, ist Februar für 7.2 ein bisschen optimistisch (und auch nicht mehr sinnvoll).
 
Da laut http://www.freebsd.org/releng/index.html 7.2 schon im Februar erscheinen soll, müssten sie ihn ja dann gleich wieder einfrieren.
Wobei ich mal denke, dass die Info veraltet ist, denn bei einem Release gegen Weihnachten von 7.1, ist Februar für 7.2 ein bisschen optimistisch (und auch nicht mehr sinnvoll).

Ich bin mir sicher, dass "releases alle 6Monaten" sich gerade bewährt und man bestimmt an dieser Regelung festhalten wird. Die neue Idee, den Portstree gleich ein halbes Jahr mit einzufrieren trägt auch bestimmt zu einem stabileren Betriebsystem bei. Der Fortschritt ist nicht aufzuhalten!
 
Also, wenn 7.1 nun fertig ist - sagen wir der Einfachheit halber mal am 01.01.2009 - wird 7.2 erst frühestens 6 Monate später erscheinen. Also Beginn des Releaseprozesses etwa Anfang Juni 2009. Das Grundproblem an diesen Terminen ist das "Debian Syndrom". -STABLE läuft lustig vor sich hin, alle denken es sei Stabil daher macht man nunmal ein Release. Also friert man es ein, erste Beta kommt. Die Nutzer stürzen sich wie die Geier auf die Beta und prompt tauchen seltsame Fehler auf, die man vorher nicht kannte. Sie werden halt erst dann durch die erweiterte Nutzerbasis entdeckt. So, sind es einfache Fehler ist alles kein Problem. Aber wenn es fischige, schwer zu lokalisierende Fehler sind, dauert das ganze halt. Teilweise lange, sehr lange. Interessant wird es erst besonders, wenn die zuständigen Entwickler plötzlich an dringlicheren Sachen arbeiten müssen, wir hier geschehen. Security geht vor, daher hat man erst die Lücke in arc4random() analysiert und geschlossen.
Aber bei allem Verständnis, der Prozess könnte transparenter sein. Was auch angemerkt wurde und wohl in Zukunft von Ken Smith auf umgesetzt werden wird. Von wöchentlichen Statusmeldungen war dort die Rede. Dazu würde ich - sagte ich auch schon im IRC - dem FreeBSD Projekt sehr nahe legen die immer häufiger genutzte "3D Realms Methode" zu nutzen, Es gibt keine Termine nur, nur noch "when it's done". Selbst Microsoft handhabt es inzwischen weitgehend so. Was keinen Termin hat, kann sich nicht verzögern.
Davon einmal abgesehen frage ich mich ganz im Ernst, wieso dieser Port Slush not tut. Die Pakete sind längst gebaut, das Tar des Baumes hätte man schon packen können. Fall erledigt. Aber andererseits sind wir hier auch nicht in der Position uns drüber zu beschweren oder gar aufzuregen, denn wir sind keine Entwickler sondern nur Nutzer. Als solche ist es für uns ein Priveleg FreeBSD nutzen zu dürfen, nicht mehr und nicht weniger. Was nun nicht heißen soll, dass Kritik grundsätzlich verboten wäre. Im Gegenteil. :)
 
ganz mutig hatte ich bereits der Tage einen Update gemacht. Bei mir war noch ein Browser-Fenster geöffnet und zeigte http://update1.freebsd.org/ und dort war ohne weiteren Kommentar plötzlich RC1 erschienen. Dachte, na, wenn es da ist, nimm es und habe mit freebsd-update dieses aus der BETA2 hochgerüstet. Dabei machte ich Fehler, weil ich nicht aufpasste. Es wurden zahlreiche Dateien, Konfigurationen, nicht automatisch umgeändert, sondern es wurden nur Vorschläge zur Änderung vorgelegt und diese sollten manuell mittel VI bearbeitet werden. Das hatte ich falsch verstanden, dachte, daß die Vorschläge dann so eingebaut würden, falls ich nichts daran ändere. Somit habe ich nun in etlichen Dateien (ich wollte, ich wüßte noch in welchen) Zeilen mit Fehlerhafter Syntax drin stehen. Zum Beispiel legt mit der HAL nun mit KDE einen Ordner in /media an, wohin Wechselmedien auch richtig gemounted werden, kann diesen Ordner aber später nicht mehr entfernen. Wenn ich hinsehe, finde ich: drwx------ 1 pit <<<<<<< current 32768 1 Jan 1980 da0s1 und das ist genau ein typischer Beitrag aus so einem Vorschlag, was in einer der Konfigurationsdateien nun falsch drinnen steht. Da werde ich wohl noch etwas suchen müssen, bis ich die wieder alle finde.
Trotzdem funktionierte der Update auf Anhieb auf amd64 und ich arbeite mit dem System ohne Schwierigkeiten.
Das mehrmalige Booten war etwas ungewohnt für mich.
An meinem System hängen USB-Maus und Keyboard und funktionierte auch schon vorher damit und es gab auch keine Unverträglichkeiten mit dem Netzwerkchip, der ist immer noch em0 und geht.
 
BTW: Gibt es irgendwo eine List mit Update-Servern? Ich versuche hier von China aus ein Systemupdate auf 7.1 RC1, werde mit eine Server update1.FreeBSD.org verbunden, der aber grauenhaft langsam ist und nach endlosen Versuchen an verschiednen Stellen abbricht. Wenn ich das Ganze hier in China bzw. Taiwan oder einem sonstigen asiatischen Land machen kann, wäre es weitaus schneller. Google hat leider keine passende Antwort parat, da finde ich nur die CVS-Server.
 
Genau das Problem meinte ich in dem USB-Keyboard-Thread ;)

Leider keine Veränderung. Weder mit 7.1, noch mit dem Loader von 6.3.
Ich stöpsel einfach für den Rest meines armseligen Fricklerlebens die Maus nach dem Start von X ein :D

[EDIT] P.S. Ich muss mit 7.1 den Rechner für einen Kaltstart wenigstens nicht mehr stromlos machen.
Runterfahren und dannach neu anmachen klappt jetzt
 
Wie lange dauert ungefähr ein "make buildworld" upgrade von 7.0 auf 7.1RC1 mit einem alten Duron 1800mhz?
Reicht da eine Nacht?
 
Zurück
Oben