The first release candidate of the 9.1-RELEASE release cycle is now
available on the FTP servers for amd64, i386, and powerpc64. The
MD5/SHA256 checksums are at the bottom of this message. The ISO images
and, for architectures that support it, the memory stick images are
available here:
ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.1/
(or any of the FreeBSD mirror sites).
Current plans are for there to be one more RC build, followed by the
release itself. The current target schedule is here:
http://www.freebsd.org/releases/9.1R/schedule.html
If you notice any problems you can report them through the normal Gnats
PR system or here on the -stable mailing list.
With both the doc and ports repositories now moved to SVN it has been
decided to not export the 9.1 release branch activity to CVS. So
csup/cvsup update mechanisms are not available for updating to 9.1-RC1.
If you would like to use SVN the branch to use is releng/9.1.
The freebsd-update(8) utility supports binary upgrades of i386 and amd64
systems running earlier FreeBSD releases. Systems running 9.0-RELEASE
can upgrade as follows:
# freebsd-update upgrade -r 9.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 earlier FreeBSD releases (FreeBSD 7.X, 8.X) can also use
freebsd-update to upgrade to FreeBSD 9.1-RC1, 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 7.X
or FreeBSD 8.X and FreeBSD 9.X.
Checksums:
MD5 (FreeBSD-9.1-RC1-amd64-bootonly.iso) = 370b1c7b5a816289c6822f577fbf59d5
MD5 (FreeBSD-9.1-RC1-amd64-disc1.iso) = a6d6bd8c47509e71af2b74a39d1ed6be
MD5 (FreeBSD-9.1-RC1-amd64-memstick.img) = 320bbcb382bd335e835636278cdb168d
MD5 (FreeBSD-9.1-RC1-i386-bootonly.iso) = 0e3bf9d6f233b0502bac54b45d8a8fe9
MD5 (FreeBSD-9.1-RC1-i386-disc1.iso) = 2d911a7c7e3ed6f93bf0a03d0696aab7
MD5 (FreeBSD-9.1-RC1-i386-memstick.img) = 64608c316269f38390501b331b954b44
MD5 (FreeBSD-9.1-RC1-powerpc64-bootonly.iso) = 4ea17dc932dad7632d7bea70af5e16a7
MD5 (FreeBSD-9.1-RC1-powerpc64-memstick) = f28d44cd7fec655d6944cdeabeca2d6c
MD5 (FreeBSD-9.1-RC1-powerpc64-release.iso) = 08742f914353300917c92b339728b80e
SHA256 (FreeBSD-9.1-RC1-amd64-bootonly.iso) =
f080e8c7cecd9bb44240a52e17827a94ad178f040b16526d339c8d0f2f1cdfd7
SHA256 (FreeBSD-9.1-RC1-amd64-disc1.iso) =
27bc85ec853f590f19ece8ddd672d62bfe58f6d8de874afd71958bd42b48f8c9
SHA256 (FreeBSD-9.1-RC1-amd64-memstick.img) =
d8312855a32dba9b22fd208c2426d136640421ccca459ce429f8a70edee9398c
SHA256 (FreeBSD-9.1-RC1-i386-bootonly.iso) =
1c8c555aa700d2b3bda77748436a1a6c2497521aae0974a7cd97451a27a9e3e4
SHA256 (FreeBSD-9.1-RC1-i386-disc1.iso) =
f16a310fe80a01555f5d3dd108bae3b8e08d01db18d7dd7d4e70e13f0bc0a7a8
SHA256 (FreeBSD-9.1-RC1-i386-memstick.img) =
0799b8efd6f8678c474fe8048a265e21b487665f70c6e4172087e3c76b28a798
SHA256 (FreeBSD-9.1-RC1-powerpc64-bootonly.iso) =
e183acb6cbb5cdbba3b3830e773c4e49ecb315eb07bde5d91d2e9595ba679d5f
SHA256 (FreeBSD-9.1-RC1-powerpc64-memstick) =
afc19a57f8d7e8b8a49f863f817221d7639f1b78288cdb0a7b8ffa5b60632d64
SHA256 (FreeBSD-9.1-RC1-powerpc64-release.iso) =
71c8a2965ff1198894e84ce0260e801b9e7f234c560bbbe95bf49274d399166d
--
Ken Smith
- From there to here, from here to | kensmith@buffalo.edu
there, funny things are everywhere. |
- Theodore Geisel |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: This is a digitally signed message part
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120823/f7aa59d9/attachment.pgp
On Thu, 23 Aug 2012 00:50:46 -0400, Ken Smith wrote: > With both the doc and ports repositories now moved to SVN it has been > decided to not export the 9.1 release branch activity to CVS. So > csup/cvsup update mechanisms are not available for updating to 9.1-RC1. > If you would like to use SVN the branch to use is releng/9.1. Assuming the stupid question is the one you didn't ask, just to clarify: does this mean that c*sup won't work with these RCs in particular, or that CVS is dead and SVN becomes mandatory from 9.1-RELEASE? cheers, Ian
On Thu, 23 Aug 2012 00:50:46 -0400, Ken Smith wrote:> The first release candidate of the 9.1-RELEASE release cycle is now > available on the FTP servers for amd64, i386, and powerpc64. The > MD5/SHA256 checksums are at the bottom of this message. The ISO images > and, for architectures that support it, the memory stick images are > available here: > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.1/ > > (or any of the FreeBSD mirror sites).<snip> I have just upgraded (an x86_64 VM) from 9.0-RELEASE to 9.1-RC1, using freebsd-update. Very smooth, and no apparent hitches at all. Thanks to all concerned, and well done. One thing (welcome, but puzzling) which surprised me was that my vboxguest.ko did *not* need to be recompiled. How did the upgrade manage that?
On Thu, 23 Aug 2012 12:37:04 -0500, Walter Hurry <walterhurry@gmail.com> wrote:> One thing (welcome, but puzzling) which surprised me was that my > vboxguest.ko did *not* need to be recompiled. How did the upgrade manage > that?FreeBSD has a stable ABI unlike Linux. A kernel module compiled for any 9.x release should work on any other 9.x release without needing to be recompiled.
On Thu, 23 Aug 2012 17:41:49 -0500, Mark Felder wrote:> On Thu, 23 Aug 2012 12:37:04 -0500, Walter Hurry <walterhurry@gmail.com> > wrote: > >> One thing (welcome, but puzzling) which surprised me was that my >> vboxguest.ko did *not* need to be recompiled. How did the upgrade >> manage that? > > FreeBSD has a stable ABI unlike Linux. A kernel module compiled for any > 9.x release should work on any other 9.x release without needing to be > recompiled.Ah right, thanks. I am indeed a refugee fom Linux <ducks for cover>.
Excerpt from announcement by Ken Smith <kensmith@buffalo.edu>:> With both the doc and ports repositories now moved to SVN it has been > decided to not export the 9.1 release branch activity to CVS. So > csup/cvsup update mechanisms are not available for updating to 9.1-RC1. > If you would like to use SVN the branch to use is releng/9.1.I read your message and followup messages and have questions about how to switch from csup to svn. System source is in /usr/src obtained by csup, apparently now being deprecated. Do I need to delete (rm -R /usr/src/*) before running svn co svn://svn.freebsd.org/base/stable/9 /usr/src I don't want an out-of-sync mess resulting from mixing two versions, assume that wouldn't work well. I guess I need to switch the doc (/usr/doc) also to svn. What about the ports? Would I need to switch the ports tree from "portsnap fetch update", or is portsnap still the proper way? Tom
On Thu, Aug 23, 2012 at 05:41:49PM -0500, Mark Felder wrote:> On Thu, 23 Aug 2012 12:37:04 -0500, Walter Hurry <walterhurry@gmail.com> > wrote: > > >One thing (welcome, but puzzling) which surprised me was that my > >vboxguest.ko did *not* need to be recompiled. How did the upgrade manage > >that? > > FreeBSD has a stable ABI unlike Linux. A kernel module compiled for any > 9.x release should work on any other 9.x release without needing to be > recompiled.This is a statement that is false at least two times, if not three. This was a question about Kernel Binary Inteface, not Application Binary Interface. First, we have zero guarantees about ability to load or have a system survive loading of the module compiled against the later kernel. Second, we do not have real KBI definition, and KBI stability is managed only ad-hock. E.g. VFS quite often breaks, while network or disk controllers drivers are usually fine. YMMV. Snobby false statements hurt the project. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120824/ae3bdf78/attachment.pgp
On Sat, 2012-08-25 at 04:42 -0700, David Wolfskill wrote:> On Fri, Aug 24, 2012 at 10:19:36PM -0700, Dennis Glatting wrote: > > ... > > There are two things that I am confused about "base." > > > > 1) What, exactly, is base? When I do a co, what tree branch is that? > > Using CVS, failure to specify a tag would get you HEAD. > > Using SVN, failure to specify a branch will get you head. > > This may help. As noted previously, I have a local private mirror of > the FreeBSD SVN src repository located in /svn/freebsd/src/base; so: > > g1-227(9.1-P)[1] svn ls file:///svn/freebsd/src/base > ROADMAP.txt > cvs2svn/ > head/ > projects/ > release/ > releng/ > stable/ > svnadmin/ > user/ > vendor/ > vendor-crypto/ > vendor-sys/ > g1-227(9.1-P)[2] svn ls file:///svn/freebsd/src/base/releng > 2.0.5/ > 4.10/ > 4.11/ > 4.3/ > 4.4/ > 4.5/ > 4.6/ > 4.7/ > 4.8/ > 4.9/ > 5.0/ > 5.1/ > 5.2/ > 5.3/ > 5.4/ > 5.5/ > 6.0/ > 6.1/ > 6.2/ > 6.3/ > 6.4/ > 7.0/ > 7.1/ > 7.2/ > 7.3/ > 7.4/ > 8.0/ > 8.1/ > 8.2/ > 8.3/ > 9.0/ > 9.1/ > ALPHA_2_0/ > BETA_2_0/ > g1-227(9.1-P)[3] svn ls file:///svn/freebsd/src/base/stable > 2.0.5/ > 2.1/ > 2.2/ > 3/ > 4/ > 5/ > 6/ > 7/ > 8/ > 9/ > g1-227(9.1-P)[4] svn ls file:///svn/freebsd/src/base/head > COPYRIGHT > LOCKS > MAINTAINERS > Makefile > Makefile.inc1 > ObsoleteFiles.inc > README > UPDATING > bin/ > cddl/ > contrib/ > crypto/ > etc/ > games/ > gnu/ > include/ > kerberos5/ > lib/ > libexec/ > release/ > rescue/ > sbin/ > secure/ > share/ > sys/ > tools/ > usr.bin/ > usr.sbin/ > g1-227(9.1-P)[5] > > > Does that help? > > > 2) Base /appears/ not to contain releng/9.1 or stable/8. How do I mirror > > those? > > As shown above, they are there. >Thanks for the clue.> Peace, > david
On Thu, Aug 23, 2012 at 6:50 AM, Ken Smith <kensmith@buffalo.edu> wrote:> ....The freebsd-update(8) utility supports binary upgrades of i386 and amd64> systems running earlier FreeBSD releases. Systems running 9.0-RELEASE > can upgrade as follows: > > # freebsd-update upgrade -r 9.1-RC1 > > This has not been working for me on i386 for the last few days. It failswith: [root@mist /usr/home/andrnils]# freebsd-update upgrade -r 9.1-RC1 Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching public key from update4.FreeBSD.org... failed. Fetching public key from update5.FreeBSD.org... failed. Fetching public key from update3.FreeBSD.org... failed. No mirrors remaining, giving up. Best regards Andreas ...> -- > Ken Smith > - From there to here, from here to | kensmith@buffalo.edu > there, funny things are everywhere. | > - Theodore Geisel | >
David Wolfskill
2012-Aug-31 18:26 UTC
9.1-RC1 installer [was: FreeBSD 9.1-RC1 Available...]
I had occasion yesterday to install FreeBSD on a machine (an HP Compaq
dx7200 Slim Tower) that had never (AFAIK) had FreeBSD installed on it.
Since I don't often use the installer, I thought it might be good to try
the 9.1-RC1 installer.
While the exercise was ultimately successful, I needed to make use of
additional hardware (including a second FreeBSD machine -- my laptop) to
complete it. Had I been trying to install with just the target machine
and the USB drive (memstick), as far as I can tell, I would have ended
up with a brick.
I like to set up machines with a minimum of 3 slices -- e.g.:
albert(8.3-S)[2] df -ht ufs
Filesystem Size Used Avail Capacity Mounted on
/dev/ad4s1a 1.5G 363M 1G 27% /
/dev/ad4s1d 3.4G 378M 2.8G 12% /usr
/dev/ad4s3d 7.8G 3.9G 3.3G 54% /var
/dev/ad4s3e 96G 45G 42G 52% /common
albert(8.3-S)[3]
While that only shows 2 of the slices, slice 2 is set up like slice 1
is; an excerpt from fstab:
albert(8.3-S)[3] grep ufs /etc/fstab
/dev/ad4s1a / ufs rw 1 1
/dev/ad4s1d /usr ufs ro 2 2
/dev/ad4s2a /S2 ufs rw,noauto 2 2
/dev/ad4s2d /S2/usr ufs rw,noauto 2 2
/dev/ad4s3d /var ufs rw 2 2
/dev/ad4s3e /common ufs rw 2 2
albert(8.3-S)[4]
When I am about to upgrade such a machine -- albert, there, generally
gets updated weekly -- I "clone" the / and /usr file systems from
the currently-booted slice to the other one, reboot from the copy, and
upgrade it in place. If I have a problem, I can boot from the slice that
it had been booted from before I started the upgrade, lick my wounds,
and figure out what to do next. (Granted, it's very rare that I need to
do that -- but I very much like having the ability to do so.)
Accordingly, when I was to install 9.1-RC1 on the HPaq, the first slient
(to the above) thing I recall noticing was that the installer was
referring to "partitions" (in the context of reserving space for
"other
Operating Systems") which confused me a great deal: I thought those were
"slices".
It was fairly obvious (even to me) that the "automatic" option
wouldn't
suit my purposes; after a false start, I managed to use the Manual
approach & set up the 3 slices; here's what "gpart show" says
about it
(now that it works):
=> 63 156249937 ada0 MBR (74G)
63 20971503 1 freebsd [active] (10G)
20971566 20971503 2 freebsd (10G)
41943069 113246154 3 freebsd (54G)
155189223 1060777 - free - (518M)
=> 0 20971503 ada0s1 BSD (10G)
0 4194304 1 freebsd-ufs (2.0G)
4194304 16777198 2 freebsd-ufs (8G)
20971502 1 - free - (512B)
=> 0 20971503 ada0s2 BSD (10G)
0 4194304 1 freebsd-ufs (2.0G)
4194304 16777198 2 freebsd-ufs (8G)
20971502 1 - free - (512B)
=> 0 113246154 ada0s3 BSD (54G)
0 12582912 1 freebsd-swap (6.0G)
12582912 41943040 2 freebsd-ufs (20G)
54525952 58720201 4 freebsd-ufs (28G)
113246153 1 - free - (512B)
The first fairly major problem occurred once the installation was
complete: I rebooted the system... or tried to. It wouldn't boot, and I
couldn't even get the machine to go into BIOS "setup" mode (still
can't,
for that matter).
I pulled the disk drive, then connected it to my laptop via one of
those UCB <=> SATA adaptors; "gpart show" showed that slice 3
(ada0s3)
was marked "active".
Oops.
I don't recall a point during the install where I had a chance to
actually mention which slice I might want active. And absent other
clues, I would have expected the slice that contained the file system
that was to be mounted on / to get that honor.
So using my laptop, I set slice 1 (ada0s1) as "active", then replaced
the drive and tried again.
No go.
It seems that the boot0 code wasn't written to the disk, either.
So I re-attached the drive to my laptop & ran "boot0cfg" to set to
boot
code -- and, while I was there, told the MBR that slice 1 would be a good
place from which to boot.
That finally worked.
I was, however, a bit surprised to find that my script to accomplish the
"cloning" didn't work without some ... exercise: it uses a
"dump |
restore" pipeline to read the (mounted) / and /usr & restore them
(after
newfs, of course) on the target slice. Well, dump wants to make a
snapshot if it's reading from a FS mounted read/write, and that's
apparently not (currently?) compatible with SU+J, which is the default
that the installer used. (I was subsequently able to manually disable
the journaling, clone the slice, and re-enable the journaling. A
subsequent test verified that I could then boot from either slice 1 or
slice 2, and that I could control this by running a script before
rebooting.)
So I got there, though I did encounter a bit of turbulence. :-}
Peace,
david
--
David H. Wolfskill david@catwhisker.org
Depriving a girl or boy of an opportunity for education is evil.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20120831/22d4f067/attachment.pgp
Yes, freebsd-update is the way to go... I got it done on my home/test server. back in the office where I have one machine on it thou. # uname -a FreeBSD rhino.matrix 9.1-BETA1 FreeBSD 9.1-BETA1 #0 r239929M: Fri Aug 31 12:42:47 EST 2012 root@rhino.matrix:/usr/obj/usr/src/sys/GENERIC amd64 # freebsd-update -v debug -r 9.1-RC1 upgrade Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching public key from update5.FreeBSD.org... fetch: http://update5.FreeBSD.org/9.1-BETA1/amd64/pub.ssl: Not Found failed. Fetching public key from update4.FreeBSD.org... fetch: http://update4.FreeBSD.org/9.1-BETA1/amd64/pub.ssl: Not Found failed. Fetching public key from update3.FreeBSD.org... fetch: http://update3.FreeBSD.org/9.1-BETA1/amd64/pub.ssl: Not Found failed. No mirrors remaining, giving up. browse to: http://update5.FreeBSD.org/ Someone has removed the whole 9.1-BETA1 directory/folder/branch making it impossible for anyone from beta1 to upgrade to rc1 using freebsd-update even thou I got one server upgraded. Can we get that restored? If not what is the CVS tag or as I noted what are the SVN details for rc1? Thanks On 24/08/12 03:37, Walter Hurry wrote:> On Thu, 23 Aug 2012 00:50:46 -0400, Ken Smith wrote: > >> The first release candidate of the 9.1-RELEASE release cycle is now >> available on the FTP servers for amd64, i386, and powerpc64. The >> MD5/SHA256 checksums are at the bottom of this message. The ISO images >> and, for architectures that support it, the memory stick images are >> available here: >> >> ftp://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.1/ >> >> (or any of the FreeBSD mirror sites). > <snip> > > I have just upgraded (an x86_64 VM) from 9.0-RELEASE to 9.1-RC1, using > freebsd-update. Very smooth, and no apparent hitches at all. Thanks to > all concerned, and well done. > > One thing (welcome, but puzzling) which surprised me was that my > vboxguest.ko did *not* need to be recompiled. How did the upgrade manage > that? > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"-- Jurgen Weber Systems Engineer IT Infrastructure Team Leader THE ICONIC | E jurgen.weber@theiconic.com.au | www.theiconic.com.au
On Thu, 23 Aug 2012, Ken Smith wrote: Hi, let me reply to the very initial email in this monster of public thread.> With both the doc and ports repositories now moved to SVN it has been > decided to not export the 9.1 release branch activity to CVS. So > csup/cvsup update mechanisms are not available for updating to 9.1-RC1. > If you would like to use SVN the branch to use is releng/9.1.RELENG_9_1 is now exported the CVS as well and will be for as long as things will be exported to CVS. It will take another few hours to get near your local mirror as they'll all be chewing on each other the next 12 hours. Enjoy! Any further discussions on src export I'll leave to other people wearing hats. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family.