Re: freebsd-update upgrade -r 7.4-RELEASE-p12
On Wed, Oct 9, 2013, at 8:36, Eduardo Morras wrote: On Tue, 8 Oct 2013 21:32:39 -0600 (MDT) Mike Brown m...@skew.org wrote: alexus wrote: ok, I just did fetch install and got bumped from p5 to p9 # uname -a FreeBSD XX.X.org 7.4-RELEASE-p9 FreeBSD 7.4-RELEASE-p9 #0: Mon Jun 11 19:47:58 UTC 2012 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 # can I take it all the way to -p12? -p10 through -p12 probably didn't involve any kernel changes. Bumping the reported patchlevel isn't considered important enough to warrant building a new kernel. That there's no kernel changes doesn't mean that uname -a info is not updated. You are incorrect. The output of uname -a is taken from the kernel and cannot be updated without installing a new kernel. The good news is that FreeBSD 10 will ship with a new utility called freebsd-version which will provide a better way of identifying if your system is up to date. From the commit message: Introduce the /libexec/freebsd-version script, which is intended to be used by auditing tools to determine the userland patch level when it differs from what `uname -r` reports. This can happen when the system is kept up-to-date using freebsd-update and the last SA did not touch the kernel, or when a new kernel has been installed but the system has not yet rebooted. http://svnweb.freebsd.org/base/head/bin/freebsd-version/ By the way, it will be /bin/freebsd-version as it has been relocated since the import into head. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update upgrade -r 7.4-RELEASE-p12
On Tue, Oct 8, 2013, at 22:32, Mike Brown wrote: alexus wrote: ok, I just did fetch install and got bumped from p5 to p9 # uname -a FreeBSD XX.X.org 7.4-RELEASE-p9 FreeBSD 7.4-RELEASE-p9 #0: Mon Jun 11 19:47:58 UTC 2012 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 # can I take it all the way to -p12? -p10 through -p12 probably didn't involve any kernel changes. Bumping the reported patchlevel isn't considered important enough to warrant building a new kernel. If your sources are in /usr/src, do this: grep -v # /usr/src/sys/conf/newvers.sh | head -4 If he had sources on the box he probably would have just compiled the fixes himself. The version number shouldn't be embedded in the kernel like that so it's easier for people to audit their systems. I have VMs right now in Xen that report different FreeBSD versions and it's confusing for other sysadmins who aren't intimately familiar with FreeBSD. Some were updated by freebsd-update, some were updated by src. But they don't report the same OS version so I get asked why we haven't updated those servers yet ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update upgrade -r 7.4-RELEASE-p12
On Tue, 8 Oct 2013 21:32:39 -0600 (MDT) Mike Brown m...@skew.org wrote: alexus wrote: ok, I just did fetch install and got bumped from p5 to p9 # uname -a FreeBSD XX.X.org 7.4-RELEASE-p9 FreeBSD 7.4-RELEASE-p9 #0: Mon Jun 11 19:47:58 UTC 2012 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 # can I take it all the way to -p12? -p10 through -p12 probably didn't involve any kernel changes. Bumping the reported patchlevel isn't considered important enough to warrant building a new kernel. That there's no kernel changes doesn't mean that uname -a info is not updated. If you update the system from p5 to current (p12), and it shows p9 instead p12 the first thing you think is that something on the system update went wrong, not that everything was fine except the update of the file that uname -a reads. If release info patch is p12, it must update the whole system to p12. If you update an app from 2.24.1 to 2.24.2 and doing 'app -v' shows 2.24.1 it means something went wrong, not that update only modified config files and not the binary. If your sources are in /usr/src, do this: grep -v # /usr/src/sys/conf/newvers.sh | head -4 No, uname -a should give the correct answer. Has uname other utility than show information about the operating system implementation? No, and it must be accurate. --- --- Eduardo Morras emorr...@yahoo.es ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update upgrade -r 7.4-RELEASE-p12
Mike Brown: $ grep ^BRANCH /usr/src/sys/conf/newvers.sh BRANCH=RELEASE-p12 $ then again, I used freebsd-update and not /usr/src, but it makes sense what you said with kernel, so I guess I _AM_ on the latest -p12 and kernel is on -p9 as there was no changes after that to kernel. thank you. On Tue, Oct 8, 2013 at 11:32 PM, Mike Brown m...@skew.org wrote: alexus wrote: ok, I just did fetch install and got bumped from p5 to p9 # uname -a FreeBSD XX.X.org 7.4-RELEASE-p9 FreeBSD 7.4-RELEASE-p9 #0: Mon Jun 11 19:47:58 UTC 2012 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 # can I take it all the way to -p12? -p10 through -p12 probably didn't involve any kernel changes. Bumping the reported patchlevel isn't considered important enough to warrant building a new kernel. If your sources are in /usr/src, do this: grep -v # /usr/src/sys/conf/newvers.sh | head -4 -- http://alexus.org/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update upgrade -r 7.4-RELEASE-p12
Eduardo Morras wrote: [...] uname -a should give the correct answer. Has uname other utility than show information about the operating system implementation? No, and it must be accurate. That's what I thought, but when I asked about it here last year, I was told that this is the way things are; our expectations of uname are at fault. I believe if he were to compile his own kernel, it would say -p12. Suggestions were made for how to deal with it, but I don't know if they were ever followed up on. They wouldn't affect 7.x in any case. Start reading the thread here: http://lists.freebsd.org/pipermail/freebsd-questions/2012-May/240666.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update upgrade -r 7.4-RELEASE-p12
alexus wrote: ok, I just did fetch install and got bumped from p5 to p9 # uname -a FreeBSD XX.X.org 7.4-RELEASE-p9 FreeBSD 7.4-RELEASE-p9 #0: Mon Jun 11 19:47:58 UTC 2012 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 # can I take it all the way to -p12? -p10 through -p12 probably didn't involve any kernel changes. Bumping the reported patchlevel isn't considered important enough to warrant building a new kernel. If your sources are in /usr/src, do this: grep -v # /usr/src/sys/conf/newvers.sh | head -4 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
freebsd-update upgrade -r 7.4-RELEASE-p12
bash-4.2# freebsd-update upgrade -r 7.4-RELEASE-p12 Looking up update.FreeBSD.org mirrors... 5 mirrors found. Fetching metadata signature for 7.4-RELEASE from update4.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/generic src/base src/bin src/cddl src/contrib src/crypto src/etc src/games src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin world/base world/dict world/doc world/games world/info world/lib32 world/manpages world/proflibs The following components of FreeBSD do not seem to be installed: world/catpages Does this look reasonable (y/n)? y Fetching metadata signature for 7.4-RELEASE-p12 from update4.freebsd.org... failed. Fetching metadata signature for 7.4-RELEASE-p12 from update5.freebsd.org... failed. Fetching metadata signature for 7.4-RELEASE-p12 from update6.freebsd.org... failed. Fetching metadata signature for 7.4-RELEASE-p12 from update2.freebsd.org... failed. Fetching metadata signature for 7.4-RELEASE-p12 from update3.freebsd.org... failed. No mirrors remaining, giving up. bash-4.2# uname -a FreeBSD XX.X.org 7.4-RELEASE-p5 FreeBSD 7.4-RELEASE-p5 #0: Fri Dec 23 17:36:54 UTC 2011 r...@xx.x.org:/usr/obj/usr/src74/sys/GENERIC amd64 bash-4.2# Is there a way to upgrade 7.4-RELEASE-p5 to 7.4-RELEASE-p12 using freebsd-update now? -- http://alexus.org/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update upgrade -r 7.4-RELEASE-p12
On Mon, 7 Oct 2013 15:22:17 -0400 alexus ale...@gmail.com wrote: bash-4.2# freebsd-update upgrade -r 7.4-RELEASE-p12 Is there a way to upgrade 7.4-RELEASE-p5 to 7.4-RELEASE-p12 using freebsd-update now? What about: # freebsd-update fetch # freebsd-update install http://www.freebsd.org/security/ Andreas -- Andreas Rudisch a...@sectorbyte.de ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update upgrade -r 7.4-RELEASE-p12
On Mon, Oct 7, 2013, at 14:22, alexus wrote: bash-4.2# freebsd-update upgrade -r 7.4-RELEASE-p12 Just freebsd-update fetch freebsd-update install is all you should have to run. The -r flag is for jumping major releases (from 7.x to 8.x, for example). I can't comment on whether or not the freebsd-update data for 7.x is still on the servers, though. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update upgrade -r 7.4-RELEASE-p12
ok, I just did fetch install and got bumped from p5 to p9 # uname -a FreeBSD XX.X.org 7.4-RELEASE-p9 FreeBSD 7.4-RELEASE-p9 #0: Mon Jun 11 19:47:58 UTC 2012 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 # can I take it all the way to -p12? (I'm running fetch again, hoping it will do that) On Mon, Oct 7, 2013 at 4:16 PM, Mark Felder f...@freebsd.org wrote: On Mon, Oct 7, 2013, at 14:22, alexus wrote: bash-4.2# freebsd-update upgrade -r 7.4-RELEASE-p12 Just freebsd-update fetch freebsd-update install is all you should have to run. The -r flag is for jumping major releases (from 7.x to 8.x, for example). I can't comment on whether or not the freebsd-update data for 7.x is still on the servers, though. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org -- http://alexus.org/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update upgrade -r 7.4-RELEASE-p12
it didn't help.. # freebsd-update fetch Looking up update.FreeBSD.org mirrors... 5 mirrors found. Fetching metadata signature for 7.4-RELEASE from update6.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. The following files are affected by updates, but no changes have been downloaded because the files have been modified locally: /var/db/mergemaster.mtree No updates needed to update system to 7.4-RELEASE-p12. WARNING: FreeBSD 7.4-RELEASE-p9 HAS PASSED ITS END-OF-LIFE DATE. Any security issues discovered after Fri Mar 1 00:00:00 UTC 2013 will not have been corrected. # freebsd-update install No updates are available to install. Run '/usr/sbin/freebsd-update fetch' first. # On Mon, Oct 7, 2013 at 5:13 PM, alexus ale...@gmail.com wrote: ok, I just did fetch install and got bumped from p5 to p9 # uname -a FreeBSD XX.X.org 7.4-RELEASE-p9 FreeBSD 7.4-RELEASE-p9 #0: Mon Jun 11 19:47:58 UTC 2012 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 # can I take it all the way to -p12? (I'm running fetch again, hoping it will do that) On Mon, Oct 7, 2013 at 4:16 PM, Mark Felder f...@freebsd.org wrote: On Mon, Oct 7, 2013, at 14:22, alexus wrote: bash-4.2# freebsd-update upgrade -r 7.4-RELEASE-p12 Just freebsd-update fetch freebsd-update install is all you should have to run. The -r flag is for jumping major releases (from 7.x to 8.x, for example). I can't comment on whether or not the freebsd-update data for 7.x is still on the servers, though. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org -- http://alexus.org/ -- http://alexus.org/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Help! Cannot boot after freebsd-update update to 9.1-p5
Help! I just used freebsd-update to upgrade a system to FreeBSD 9.1-RELEASE-p5 to close the latest security holes. I then rebuilt my custom kernel and tried to reboot. I'm now getting the message Can't work out which disk we are booting from. Guessed BIOS device 0x not found by probes, defaulting to disk0: at boot time. The strange thing is that when I boot the system from a FreeBSD 9.1 (AMD64) USB key, I can mount and read the file system on the hard drive that will not boot. There doesn't seem to be any problem with it. I've tried copying /boot/loader over from the USB key; still can't boot. Tried moving the GENERIC kernel over from the USB key into /boot/kernel, just in case there was a problem with my custom one; still can't boot. Not sure what to try next. Any ideas would be much appreciated! --Brett Glass ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Should I be able to use mergemaster with freebsd-update?
Hi all, A small followup: Looks like freebsd-update does try to rebuild the password database but does not quite succeed, leaving binary files in somewhat corrupted state, this leading to some problems when trying to add new users later. This is discussed here: http://www.freebsd.org/cgi/query-pr.cgi?pr=180241 However the master.passwd is fine, thus as a workaround you can simply run vipw to resave master.passwd, then vipw regenerates binary password databases correctly and everything works quite nicely. Best wishes Eugene -Original Message- From: Eugene Sent: Tuesday, July 02, 2013 8:37 PM To: freebsd-questions@freebsd.org Subject: Re: Should I be able to use mergemaster with freebsd-update? Hi all, In case anybody was following this discussion, I have successfully upgraded the system from 8.2 to 8.4 using freebsd-update. The process did have some glitches (in retrospect, minor ones) but mostly they were not related to freebsd-update (like some issues with gmirror and firewall configurations). The data merging phase was quite bearable and reasonable (if a bit tedious) and all the databases got properly updated. Thanks to everyone involved! Eugene -Original Message- From: Mike Brown Sent: Wednesday, June 26, 2013 6:22 AM To: freebsd-questions@freebsd.org Subject: Re: Should I be able to use mergemaster with freebsd-update? On Tue, Jun 25, 2013, at 15:29, Eugene wrote: I do not quite understand. Is the freebsd-update upgrade process completely broken? IMHO it is partially broken; I'm not doing anything special. How broken it is depends on what's getting changed. Most of what the system is designed to do, it indeed does very well. It also overlaps some of the functionality of mergemaster in that it automatically merges as many files as it can, which is nice. Where it is under-designed and under-implemented is in its rudimentary handling of un-mergeable files, and in its total lack of support for the regeneration of /etc/*.db files (like the, uh, rather important password database) and sendmail aliases - things that you would handle via mergemaster in an ordinary, source-based upgrade, but which you must now figure out how to do by hand, without any guidance, and they really don't make it easy for you. ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Should I be able to use mergemaster with freebsd-update?
Hi all, In case anybody was following this discussion, I have successfully upgraded the system from 8.2 to 8.4 using freebsd-update. The process did have some glitches (in retrospect, minor ones) but mostly they were not related to freebsd-update (like some issues with gmirror and firewall configurations). The data merging phase was quite bearable and reasonable (if a bit tedious) and all the databases got properly updated. Thanks to everyone involved! Eugene -Original Message- From: Mike Brown Sent: Wednesday, June 26, 2013 6:22 AM To: freebsd-questions@freebsd.org Subject: Re: Should I be able to use mergemaster with freebsd-update? On Tue, Jun 25, 2013, at 15:29, Eugene wrote: I do not quite understand. Is the freebsd-update upgrade process completely broken? IMHO it is partially broken; I'm not doing anything special. How broken it is depends on what's getting changed. Most of what the system is designed to do, it indeed does very well. It also overlaps some of the functionality of mergemaster in that it automatically merges as many files as it can, which is nice. Where it is under-designed and under-implemented is in its rudimentary handling of un-mergeable files, and in its total lack of support for the regeneration of /etc/*.db files (like the, uh, rather important password database) and sendmail aliases - things that you would handle via mergemaster in an ordinary, source-based upgrade, but which you must now figure out how to do by hand, without any guidance, and they really don't make it easy for you. ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Upgrading from 8.0 to 8.4 with freebsd-update?
Is it possible to skip point releases using freebsd-update so that I can go from 8.0 to 8.4, or do I need to go 8.0 - 8.1 - 8.2 - 8.3 - 8.4? Patrick ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Upgrading from 8.0 to 8.4 with freebsd-update?
On Thu, Jun 27, 2013 at 8:05 PM, Patrick gibblert...@gmail.com wrote: Is it possible to skip point releases using freebsd-update so that I can go from 8.0 to 8.4 Yes. http://www.freebsd.org/releases/8.4R/relnotes-detailed.html#upgrade -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Should I be able to use mergemaster with freebsd-update?
I wrote: The main problem this time is that I'm not so lucky with the password files, because for 8.4, freebsd-update has fetched new, stock .db files to put in /etc. Whoa, sorry, I misspoke here. freebsd-update asked me, after the merges, to approve unspecified differences in pwd.db and spwd.db. I assumed that it had fetched those files as part of the 8.4 distribution. But http://svnweb.freebsd.org/base/release/8.4.0/etc/ seems to indicate that's not what happened; only master.passwd was changed. I'm looking through the freebsd-update code now. I see it does actually do some special handling of master.passwd, but not until you do your 'freebsd-update install'. At that point, it will look at /etc/master.passwd and see if it's newer than /etc/pwd.db or /etc/spwd.db, and it will run pwd_mkdb. It doesn't use the -p flag, so I guess it doesn't care about passwd. This pwd_mkdb run didn't happen for me, though, since my 'freebsd-update install' run didn't actually put the new master.passwd file, or anything else, into /etc yet. I thought it would, but I don't understand it, really. So I don't see how it's supposed to work. To summarize: 1. I did the initial 'freebsd-update -r 8.4-RELEASE upgrade' 2. When prompted, I did all the merges it needed me to do by hand. 3. When prompted, I approved all the diffs. Two of the diffs were unspecified pwd.db spwd.db changes, which caused me some alarm. 4. I looked in the staging area and found that these were empty files. 5. I looked in /etc and nothing new had been placed there yet. 6. I did the 'freebsd-update install' and checked /etc again; still nothing. 7. Afraid of rebooting with bogus password database files staged, I generated proper pwd.db, spwd.db, and passwd files myself, and put them in the staging area. Next step, I think, is reboot, before another 'freebsd-update install' run. I'm worried something is still amiss, though, so I'm holding off for now. :( ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Should I be able to use mergemaster with freebsd-update?
On Wed, Jun 26, 2013, at 2:07, Mike Brown wrote: Next step, I think, is reboot, before another 'freebsd-update install' run. I'm worried something is still amiss, though, so I'm holding off for now. :( When in doubt: fetch source, build, install, and use mergemaster. Then reboot. Better safe than sorry. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update percentage indicators - what are they, why are they so random?
Fetching 1 metadata files... 70.5% done. 70.5% 70.5% 74.2% 74.2% 81.7% 81.7% 70.5% I think this is a result of having -v in my GZIP environment variable. I always forget about my GZIP and BZIP2 variables. I should've known. So, never mind about that. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Should I be able to use mergemaster with freebsd-update?
I'm using freebsd-update to upgrade my system to the latest minor version
(from 8.3-RELEASE to 8.4-RELEASE).
I'm surprised that the merge handling system isn't more robust. When
upgrading
the old way, from source, I was used to using mergemaster to handle any
merges that couldn't be done automatically.
But when using freebsd-update, it seems that any failed merges require that
you get dumped into an empty text editor for each file.
[...]
As I continue with this process, doing all the mergemaster tasks manually, I'm
finding that the situation is even worse than I first realized.
First, the relatively painless part. As I mentioned, after running
'freebsd-update -r 8.4-RELEASE upgrade', I had to deal with the un-mergeable
files.
Although mergemaster apparently isn't an option, its interactive merge
function is really just a front-end for sdiff, so I found that I could
replicate that part of its functionality by doing this in a separate window
(-w 100 because I use a 100-column terminal):
cd /var/db/freebsd-update/merge/8.4-RELEASE
find -X . -type f | xargs -n 1 -o -I % sh -c '{ echo Now processing %.
left=current, right=new, help=?; sdiff -d -w 100 -o ../new/% ../old/% %; }'
This populated my 'new' directory with merged files, so that (in the first
window) when I opened the text editor for each one, I only had to just give it
a once-over and exit the editor.
Among the diffs in this 8.3 to 8.4 upgrade were changes to /etc/master.passwd
and /etc/passwd, to add the 'auditdistd' and 'hast' users. As reported in
March 2012 [1] in relation to 8.x to 9.x upgrades, this won't work as
expected, because freebsd-update doesn't run pwd_mkdb after the master.passwd
update.
Now the real hurt begins; in the 8.3 to 8.4 upgrade, it's even worse.
Once I saved all the files in the editor, I was prompted to approve a diff for
each one. I had to answer y or the entire process aborts.
Among the changes I was asked to approve, besides visible diffs, were
unspecified differences in /etc/pwd.db and /etc/spwd.db, the binary files that
contain the password database. There's no choice but to answer y and
approve them, and I don't get any opportunity to rebuild them properly.
So apparently, freebsd-update wants to install new, stock password databases,
which are out-of-sync with my customized, merged master.passwd passwd files.
(And because of the way the freebsd-update system works, what I actually
approved were empty, 0-byte files, the result of the failed merges.)
What would happen if I just let it do this? Surely I wouldn't be able to log
in, after the reboot, right?
After approving the files (again, I had no choice!), I was presented with
lists of all the files that would be deleted, added, and modified. Sure
enough, bad /etc/pwd.db and /etc/spwd.db files were in the list.
At this point, the merge folders were now gone; I no longer had the new
master.passwd in a recognizable place. So I thought, OK, I'll run
'freebsd-update install' and hope that the new files end up in /etc. Then I
could just run 'pwd_mkdb -p /etc/master.passwd' to regenerate passwd, pwd.db
and spwd.db before my reboot.
But the 'freebsd-update install' didn't put them there yet; I guess that
doesn't happen till after the reboot. So they're still sitting in a staging
folder, now gzipped and with obfuscated names, indexed in a separate file.
Averting this disaster-in-the-making is not at all straightforward:
cd /var/db/freebsd-update
mkdir -m 0700 /tmp/oldpwdfiles
zcat files/`grep '^/etc/master\.passwd' install.LYQAJQ/INDEX-NEW | cut -d \| -f
7`.gz /tmp/oldpwdfiles/master.passwd
zcat files/`grep '^/etc/passwd' install.LYQAJQ/INDEX-NEW | cut -d \| -f 7`.gz
/tmp/oldpwdfiles/passwd
zcat files/`grep '^/etc/pwd\.db' install.LYQAJQ/INDEX-NEW | cut -d \| -f 7`.gz
/tmp/oldpwdfiles/pwd.db
zcat files/`grep '^/etc/spwd\.db' install.LYQAJQ/INDEX-NEW | cut -d \| -f 7`.gz
/tmp/oldpwdfiles/spwd.db
mkdir -m 0700 /tmp/newpwdfiles
pwd_mkdb -d /tmp/newpwdfiles -p /tmp/oldpwdfiles/master.passwd
gzip /tmp/newpwdfiles/*
mv /tmp/newpwdfiles/master.passwd.gz files/`grep '^/etc/master\.passwd'
install.LYQAJQ/INDEX-NEW | cut -d \| -f 7`.gz
mv /tmp/newpwdfiles/passwd.gz files/`grep '^/etc/passwd'
install.LYQAJQ/INDEX-NEW | cut -d \| -f 7`.gz
mv /tmp/newpwdfiles/pwd.db.gz files/`grep '^/etc/pwd\.db'
install.LYQAJQ/INDEX-NEW | cut -d \| -f 7`.gz
mv /tmp/newpwdfiles/spwd.db.gz files/`grep '^/etc/spwd\.db'
install.LYQAJQ/INDEX-NEW | cut -d \| -f 7`.gz
rm -fr /tmp/oldpwdfiles /tmp/newpwdfiles
I'm really shocked that it came to this. Did I just overlook the
--no-surprises option in freebsd-update?
And now, before I reboot, I have to figure out how to handle the changes that
got made in /etc/mail ... ordinarily I'd run 'make all install restart' in
there. Not an option till after reboot, though. At least it's not crucial for
the reboot to work.
Again, this is something that mergemaster was really good
Re: Should I be able to use mergemaster with freebsd-update?
On Tue, Jun 25, 2013, at 3:14, Mike Brown wrote: Well, thanks for reading this far. I'm scared to death to reboot now, since my server is in another city, but we'll see how it goes. I always avoid freebsd-update when moving between releases simply because of this atrocity. If it requires we setup a stupid kickstarter to fund a developer to sit down and rip into freebsd-update so it uses mergemaster I would be incredibly thankful. I don't know how anyone can upgrade between FreeBSD releases without an /etc/mergemaster.rc with the following settings: AUTO_INSTALL='yes' AUTO_UPGRADE='yes' # keep our custom motd IGNORE_FILES='/etc/motd' # Do not display changes that only affect whitespace DIFF_FLAG='-Bub' FREEBSD_ID='yes' DELETE_STALE_RC_FILES='yes' ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Should I be able to use mergemaster with freebsd-update?
Hi all, I do not quite understand. Is the freebsd-update upgrade process completely broken? Or is it some special mode? Or was it broken recently? Because some time ago I have upgraded from 8.1 to 8.2 quite nicely, with editor-based merging of config files, and was planning to upgrade to 8.4 soon (especially as 8.2 is already not compatible with some ports). Best wishes Eugene -Original Message- From: Mike Brown Sent: Tuesday, June 25, 2013 12:14 PM To: freebsd-questions@freebsd.org Subject: Re: Should I be able to use mergemaster with freebsd-update? I'm using freebsd-update to upgrade my system to the latest minor version (from 8.3-RELEASE to 8.4-RELEASE). I'm surprised that the merge handling system isn't more robust. When upgrading the old way, from source, I was used to using mergemaster to handle any merges that couldn't be done automatically. But when using freebsd-update, it seems that any failed merges require that you get dumped into an empty text editor for each file. [...] As I continue with this process, doing all the mergemaster tasks manually, I'm finding that the situation is even worse than I first realized. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Should I be able to use mergemaster with freebsd-update?
On Tue, Jun 25, 2013, at 15:29, Eugene wrote: Hi all, I do not quite understand. Is the freebsd-update upgrade process completely broken? Or is it some special mode? Or was it broken recently? Because some time ago I have upgraded from 8.1 to 8.2 quite nicely, with editor-based merging of config files, and was planning to upgrade to 8.4 soon (especially as 8.2 is already not compatible with some ports). It depends on how many changes happen between the releases. Have you tried taking 7.x to 9.x before? You'll have to deal with that editor for merging many, many files. Maybe nearly everything in /etc. It's quite time consuming, whereas I can get mergemaster to auto-merge all of those files and only show me the 5 that I've personally touched. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Should I be able to use mergemaster with freebsd-update?
On Tue, Jun 25, 2013, at 15:29, Eugene wrote: I do not quite understand. Is the freebsd-update upgrade process completely broken? IMHO it is partially broken; I'm not doing anything special. How broken it is depends on what's getting changed. Most of what the system is designed to do, it indeed does very well. It also overlaps some of the functionality of mergemaster in that it automatically merges as many files as it can, which is nice. Where it is under-designed and under-implemented is in its rudimentary handling of un-mergeable files, and in its total lack of support for the regeneration of /etc/*.db files (like the, uh, rather important password database) and sendmail aliases - things that you would handle via mergemaster in an ordinary, source-based upgrade, but which you must now figure out how to do by hand, without any guidance, and they really don't make it easy for you. When I upgraded from 8.1 to 8.3, I avoided the issue altogether by not really merging anything; when dumped into the empty text editor, I just loaded my old files and made no changes. In the Handbook, there's an assumption that people who do this will go back later and figure out what merges are needed, but the resources you need to do that don't exist; if you don't do the merge when prompted, you don't get a second chance. In fact, even if you do it when prompted, you need to get it right, or start the whole process over. My upgrade to 8.3 worked out OK because I got lucky; freebsd-update hadn't fetched new, stock password database files. The unmergeable files were all text files, nothing requiring anything to be regenerated. But this time around, for 8.3 to 8.4, I am trying to do everything I'm supposed to, actually merging when prompted. The fact that it's a *really* manual process is a pain, but as I mentioned, I found a way to at least run sdiff from another window, which made it a lot easier, although still more tedious than it should be. The main problem this time is that I'm not so lucky with the password files, because for 8.4, freebsd-update has fetched new, stock .db files to put in /etc. So, yes, I was able to merge master.passwd passwd, but that's not very helpful since the .db files won't be in sync with them. If allow my custom password database to be overwritten with these new, stock .db files, obviously that's bad. And because freebsd-update makes no special allowance for the .db files, it actually put a zero-byte file in the staging area instead of the real .db file (as if it were going to have me modify it with an editor). So if I proceed, my password database will actually be overwritten with an empty file, which I believe would be a disaster. The solution, I feel, is to: 1. make freebsd-update recognize files that most likely need to be regenerated instead of replaced - /etc/*.db, at least, if not also any other binary file, and some of the things that would be generated by 'make' in /etc/mail. The user should be informed that these files need to be regenerated, if there's no way to just regenerate them automatically when their companion source files have been updated or merged. 2. make freebsd-update run mergemaster on the unmergeable text files, instead of dumping the user into an empty text editor for each one. For each file that can't be automatically merged, mergemaster will give the user the opportunity to choose whether to keep the old file, replace it with the new file, interactively merge them via sdiff, or do nothing. It is also smart enough to realize that when certain files are being touched, such as /etc/master.passwd, /etc/mail/aliases, etc. you'll need to run pwd_mkdb, cap_mkdb, services_mkdb, or newaliases...and it will run those for you (or remind you to do it). For this to work, mergemaster would need some tweaking to deal with freebsd-update's staging area, and to not duplicate any of the work that freebsd-update does. I keep hoping that maybe there's some nuance of the process that I'm missing, and that all of this really is not a problem.. user error, or not reading the docs carefully enough, you know? But Mark Felder's comments seem to confirm that it's a real issue. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
freebsd-update percentage indicators - what are they, why are they so random?
I'm using freebsd-update to upgrade my system to the latest minor release. At a couple points in the process, I get weird status indicators (percentages) showing me that something is happening: Fetching 1 metadata files... 70.5% done. 70.5% 70.5% 74.2% 74.2% 81.7% 81.7% 70.5% Inspecting system... done. Sometimes these numbers are negative, and although not entirely random, they don't seem to follow any particular pattern... they don't creep up from 0 to 100, at least: Preparing to download files... done. -4.7% -8.4% -9.6% 35.4% 30.6% 30.5% 45.2% 43.4% 43.0% 68.1% 68.2% 68.2% 44.4% 43.0% 43.0% 72.0% 71.9% 71.9% 69.1% 69.0% 69.0% 72.0% 71.9% 71.9% 69.1% 69.0% 69.0% 52.2% 50.2% 49.9% 53.4% 56.8% 57.5% 59.0% 55.1% 56.0% 91.4% 94.5% 94.3% 90.4% 94.5% 94.3% 54.8% 54.6% 55.3% 28.8% 24.9% 24.2% 57.0% 53.3% 55.1% Attempting to automatically merge changes in files... done. What is the point of these numbers? Does everyone see them, or is it just me? Are they supposed to be on separate lines like this, or are they supposed to overwrite each other one line? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Should I be able to use mergemaster with freebsd-update?
I'm using freebsd-update to upgrade my system to the latest minor version (from 8.3-RELEASE to 8.4-RELEASE). I'm surprised that the merge handling system isn't more robust. When upgrading the old way, from source, I was used to using mergemaster to handle any merges that couldn't be done automatically. But when using freebsd-update, it seems that any failed merges require that you get dumped into an empty text editor for each file. It doesn't even tell you where the new file is so you can load it and compare it to the old one. After that, you're asked to approve every diff, but if you reject one, you don't get a chance to re-edit; the entire upgrade aborts and you have to start all over again. Since it wasn't obvious what to do, last time I upgraded, I just loaded all my old files and kept them as-is, without merging them. This time, I'm trying to actually take care of them when prompted. When I get dumped into the empty text editor, I suppose it's not too hard to figure out that the new file is in /var/db/freebsd-update/merge/8.4-RELEASE, but that's certainly not documented anywhere. It could at least be mentioned prior to being sent to the editor. The old file is mentioned, so why not the new? Regardless, when doing a manual merge by loading both files and consolidating them, or by copy-paste voodoo between terminal windows, it is far easier to screw up than mergemaster's method, at least in my experience. So I was thinking that when I get to this stage of the freebsd-update process, it would be nice to use mergemaster in a separate terminal window. I mean, I know where the new files are, and I know where I need the merged files to go, so it should be just a matter of invoking mergemaster with the right flags, right? Then when I'm dumped into a text editor, it won't be empty; I'll see the mergemaster-produced file, and can just give it a once-over. The handbook even mentions mergemaster as if it is an option: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html#freebsdupdate-config-file ...or at least, it suggests I read about it, for some reason. But I can't figure out how to get mergemaster to use freebsd-update's file locations. Here is what I tried: mergemaster -ciFv -m /var/db/freebsd-update/merge/8.4-RELEASE -D /var/db/freebsd-update/merge/new Here's what that results in, even if I add trailing slashes: make: don't know how to make distrib-dirs. Stop make: don't know how to make distrib-dirs. Stop *** FATAL ERROR: Cannot 'cd' to /var/db/freebsd-update/merge/8.4-RELEASE and install files to the temproot environment Any suggestions appreciated. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
freebsd-update and /boot/kernel/linker.hints
Hi, since last freebsd-update fetch install I always get this message after freebsd-update fetch: The following files will be updated as part of updating to 9.1-RELEASE-p3: /boot/kernel/linker.hints but freebsd-update install doesn't install anything. Is there something wrong with my system or is this a bug in freebsd-update? kind regards Wolfgang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update and /boot/kernel/linker.hints
On Mon, May 13, 2013 at 11:22:41AM +0200, Wolfgang Riegler wrote: Hi, since last freebsd-update fetch install I always get this message after freebsd-update fetch: The following files will be updated as part of updating to 9.1-RELEASE-p3: /boot/kernel/linker.hints but freebsd-update install doesn't install anything. Is there something wrong with my system or is this a bug in freebsd-update? kind regards Wolfgang ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org My guess is that there is something wrong with freebsd-update. There is another thread here one the mailing list. And here is another thread at BSDForen.de I have started: http://www.bsdforen.de/showthread.php?p=251220#post251220 I am experiencing the same issue. I am no BSD-expert, but what I found strange is that if you compile your own GENERIC kernel+modules the freebsd-update tool tries to update the nfsd.ko module which would indeed result in a different checksum for nfsd.ko + a different linker.hints. signature.asc Description: Digital signature
freebsd-update question
I had an 8.2 system that I wanted to take to 8.4. First I tried upgrade to 8.4, getting (in essence) can't do that. So I upgraded 8.2 which worked giving the end-of-life warning. But seemed work. I then did an upgrade to 8.3 with: freebsd-update -r 8.3-RELEASE upgrade The first part, downloading the diffs and inspecting the system seemed ok. The install seemed ok up to the point it wanted to edit files. It wanted to edit freebsd.submit.cf and sendmail.cf neither of which had local changes and then it started wanting to delete all the files in /etc. I aborted the process when it got to rc.conf. The message was something like, deleting file hosts.allow no longer in 8.3. Happily aborting the process left the system unchanged. Aside from, what could I have done wrong? My question is should we be able to trust freebsd-update on expired systems if it says a mirror exists and then sets about doing its thing? Can this happen in the normal process of removing update 'cruft' from the mirrors? _ Douglas Denault http://www.safeport.com d...@safeport.com Voice: 301-217-9220 Fax: 301-217-9277 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On Thu, 25 Apr 2013, Steve O'Hara-Smith wrote: The problem under discussion is that the kernel version does not change when a freebsd-update update does not include a kernel change. Perhaps we could adopt the Linux practice of placing the release information in /etc/issue Daniel Feenberg ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On Thu, 25 Apr 2013 07:37:01 -0400 (EDT), Daniel Feenberg wrote: On Thu, 25 Apr 2013, Steve O'Hara-Smith wrote: The problem under discussion is that the kernel version does not change when a freebsd-update update does not include a kernel change. Perhaps we could adopt the Linux practice of placing the release information in /etc/issue I'd like to see a working placeholder for this file, not a modification, because it could be a custom file (created specifically for a system). Or do you perhaps refer to /etc/motd and the update_motd=YES (update version info in /etc/motd) as seen in /etc/defaults/rc.conf? In /etc/issue, you write something like %s/%m %r to print the information before the login prompt. Or you use something like the traditional im=\r\n%s/%m (%h) (%t) in /etc/gettytab. Those are placeholders, the information is stored _outside_ of the files. Maybe it could be possible to add a text file in /etc that will contain the correct OS and kernel version number, maybe the date of the source the system has been built from (or the binary package for freebsd-update has been created from), and maybe the SVN revision number, because it looks important. :-) Then, if there could be mechanisms to plug this information properly into the traditional placeholders as described. Uhm... that would be great. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On Thu, 25 Apr 2013, Polytropon wrote: On Thu, 25 Apr 2013 07:37:01 -0400 (EDT), Daniel Feenberg wrote: On Thu, 25 Apr 2013, Steve O'Hara-Smith wrote: The problem under discussion is that the kernel version does not change when a freebsd-update update does not include a kernel change. Perhaps we could adopt the Linux practice of placing the release information in /etc/issue ... In /etc/issue, you write something like %s/%m %r to print the information before the login prompt. Or you use something like the traditional im=\r\n%s/%m (%h) (%t) in /etc/gettytab. This is written as though it applies to FreeBSD, but I was under the impression that FreeBSD didn't do anything with /etc/issue. There isn't any man page for it, and when I created a file /etc/issue it wasn't presented at login. Is there something else I need to do? I am using 9.1 Daniel Feenberg ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On Thu, 25 Apr 2013 11:14:06 -0400 (EDT), Daniel Feenberg wrote: This is written as though it applies to FreeBSD, but I was under the impression that FreeBSD didn't do anything with /etc/issue. It actually works quite well, I'm using it for decades. :-) You just need to add the item if=/etc/issue to your default setting (or whichever you use) in /etc/gettytab. There isn't any man page for it, and when I created a file /etc/issue it wasn't presented at login. See man gettytab: if str unuseddisplay named file before prompt, like /etc/issue This is not part of the default configuration. Is there something else I need to do? I am using 9.1 Just change your /etc/gettytab to something like this: default:\ :cb:ce:ck:lc:fd#1000:im=TEXT :sp#1200:\ :if=/etc/issue: The system's default setting is like this: default:\ :cb:ce:ck:lc:fd#1000:im=\r\n%s/%m (%h) (%t)\r\n\r\n:sp#1200:\ There is no issue file defined. The im= setting contains (additional) text presented directly before the text login: appears. It could be the hostname or any other identification. In this file, as well as in /etc/issue, you can use the following placeholders: OS name:%s FreeBSD architecture: %m i386 OS version: %r 8.3 hostname: %h foo.example.com terminal line: %t ttyv1 date: %d Fri Apr 26 04:37:00 CEST 2013 They are also listed in man gettytab. Also know the figlet program (plus the figlet-fonts package) to design nice ASCII banners. :-) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
FreeBSD-update?
When I issue 'freebsd-update fetch install I see this: Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 9.1-RELEASE from update5.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. No updates needed to update system to 9.1-RELEASE-p2. No updates are available to install. So if 'No updates (are) needed to update system to 9.1-RELEASE-p2', how do I actually update to 9.1-RELEASE-p2? $ uname -r 9.1-RELEASE ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On Wed, 24 Apr 2013 16:00:47 + (UTC), Walter Hurry wrote: When I issue 'freebsd-update fetch install I see this: Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 9.1-RELEASE from update5.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. No updates needed to update system to 9.1-RELEASE-p2. No updates are available to install. So if 'No updates (are) needed to update system to 9.1-RELEASE-p2', how do I actually update to 9.1-RELEASE-p2? $ uname -r 9.1-RELEASE The kernel's version message will only change if the _kernel_ has been receiving changes. So, for example, if you update from 9.1 to 9.1-p2, and _no_ change has been written to the kernel, it will still report 9.1, even though the updates for -p2 have been applied to other places (like system binaries or libraries). You can use the -r option to freebsd-update to explicitely specify a version to update to. See man freebsd-update for details. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On Wed, 24 Apr 2013 18:05:04 +0200, Polytropon wrote: The kernel's version message will only change if the _kernel_ has been receiving changes. So, for example, if you update from 9.1 to 9.1-p2, and _no_ change has been written to the kernel, it will still report 9.1, even though the updates for -p2 have been applied to other places (like system binaries or libraries). You can use the -r option to freebsd-update to explicitely specify a version to update to. See man freebsd-update for details. Thanks for the reply, but I'm still confused. -- # freebsd-update upgrade -r 9.1-RELEASE-p2 Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 9.1-RELEASE from update5.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/generic src/src world/base world/lib32 The following components of FreeBSD do not seem to be installed: world/doc world/games Does this look reasonable (y/n)? y Fetching metadata signature for 9.1-RELEASE-p2 from update5.freebsd.org... failed. Fetching metadata signature for 9.1-RELEASE-p2 from update4.freebsd.org... failed. Fetching metadata signature for 9.1-RELEASE-p2 from update3.freebsd.org... failed. No mirrors remaining, giving up -- Where am I going wrong? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On Wednesday, April 24, 2013, Walter Hurry wrote: On Wed, 24 Apr 2013 18:05:04 +0200, Polytropon wrote: The kernel's version message will only change if the _kernel_ has been receiving changes. So, for example, if you update from 9.1 to 9.1-p2, and _no_ change has been written to the kernel, it will still report 9.1, even though the updates for -p2 have been applied to other places (like system binaries or libraries). You can use the -r option to freebsd-update to explicitely specify a version to update to. See man freebsd-update for details. Thanks for the reply, but I'm still confused. -- # freebsd-update upgrade -r 9.1-RELEASE-p2 Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 9.1-RELEASE from update5.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/generic src/src world/base world/lib32 The following components of FreeBSD do not seem to be installed: world/doc world/games Does this look reasonable (y/n)? y Fetching metadata signature for 9.1-RELEASE-p2 from update5.freebsd.org... failed. Fetching metadata signature for 9.1-RELEASE-p2 from update4.freebsd.org... failed. Fetching metadata signature for 9.1-RELEASE-p2 from update3.freebsd.org... failed. No mirrors remaining, giving up -- Where am I going wrong? Hi Walter, Freebsd-update tool apply binary patches to your -RELEASE system and GENERIC kernel. Furthermore, sources are synced too (/usr/src) by default. If you want to see the -p# increased, you have to recompile your GENERIC kernel. If you are using a custom kernel, you must recompile it to apply patches as your sources are up-to-date. You will have the -p# increased too. Kind regards, Alexandre ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On Wed, 24 Apr 2013 16:00:47 + (UTC) Walter Hurry walterhu...@gmail.com wrote: When I issue 'freebsd-update fetch install I see this: Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 9.1-RELEASE from update5.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. No updates needed to update system to 9.1-RELEASE-p2. No updates are available to install. So if 'No updates (are) needed to update system to 9.1-RELEASE-p2', how do I actually update to 9.1-RELEASE-p2? $ uname -r 9.1-RELEASE You have updated to 9.1-RELEASE-p2 - but since there have been no kernel changes since 9.1-RELEASE the kernel version message hasn't changed. This could very reasonably be regarded as bug in the update/version reporting process but I wouldn't hold my breath for a fix, as things stand the version reported only changes when the kernel is updated, or if you recompile it after the update. -- Steve O'Hara-Smith st...@sohara.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On Wed, 24 Apr 2013 14:34:30 -0500, Steve O'Hara-Smith st...@sohara.org wrote: You have updated to 9.1-RELEASE-p2 - but since there have been no kernel changes since 9.1-RELEASE the kernel version message hasn't changed. This could very reasonably be regarded as bug in the update/version reporting process but I wouldn't hold my breath for a fix, as things stand the version reported only changes when the kernel is updated, or if you recompile it after the update. It would be nice if the version of the OS itself was stored in something like /etc/freebsd-version so you know what the version of the OS as a whole is. I'd even accept some sort of output by freebsd-update. It just seems silly that there's no other way -- kern.osrelease is just the base release and kern.version is the same thing that uname -a outputs. It's hard to pick this up and monitor it accurately. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On Wed, 24 Apr 2013 19:35:01 +0200, Alexandre wrote: Freebsd-update tool apply binary patches to your -RELEASE system and GENERIC kernel. Furthermore, sources are synced too (/usr/src) by default. If you want to see the -p# increased, you have to recompile your GENERIC kernel. If you are using a custom kernel, you must recompile it to apply patches as your sources are up-to-date. You will have the -p# increased too. OK, thanks. The mists are beginning to clear. I've synced the source tree and recompiled the kernel, and all is well now. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On Wed, 24 Apr 2013 14:52:17 -0500, Mark Felder wrote: On Wed, 24 Apr 2013 14:34:30 -0500, Steve O'Hara-Smith st...@sohara.org wrote: You have updated to 9.1-RELEASE-p2 - but since there have been no kernel changes since 9.1-RELEASE the kernel version message hasn't changed. This could very reasonably be regarded as bug in the update/version reporting process but I wouldn't hold my breath for a fix, as things stand the version reported only changes when the kernel is updated, or if you recompile it after the update. It would be nice if the version of the OS itself was stored in something like /etc/freebsd-version so you know what the version of the OS as a whole is. I'd even accept some sort of output by freebsd-update. It just seems silly that there's no other way -- kern.osrelease is just the base release and kern.version is the same thing that uname -a outputs. It's hard to pick this up and monitor it accurately. I think I agree with this. It's somewhat confusing for a novice like me. Thanks to all for the helpful replies. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On Wed, 24 Apr 2013 14:52:17 -0500 Mark Felder f...@feld.me wrote: On Wed, 24 Apr 2013 14:34:30 -0500, Steve O'Hara-Smith st...@sohara.org wrote: You have updated to 9.1-RELEASE-p2 - but since there have been no kernel changes since 9.1-RELEASE the kernel version message hasn't changed. This could very reasonably be regarded as bug in the update/version reporting process but I wouldn't hold my breath for a fix, as things stand the version reported only changes when the kernel is updated, or if you recompile it after the update. It would be nice if the version of the OS itself was stored in something like /etc/freebsd-version so you know what the version of the OS as a Yes it would. -- Steve O'Hara-Smith | Directable Mirror Arrays C:WIN | A better way to focus the sun The computer obeys and wins.|licences available see You lose and Bill collects. |http://www.sohara.org/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On 04/25/13 06:31, Steve O'Hara-Smith wrote: On Wed, 24 Apr 2013 14:52:17 -0500 Mark Felder f...@feld.me wrote: On Wed, 24 Apr 2013 14:34:30 -0500, Steve O'Hara-Smith st...@sohara.org wrote: You have updated to 9.1-RELEASE-p2 - but since there have been no kernel changes since 9.1-RELEASE the kernel version message hasn't changed. This could very reasonably be regarded as bug in the update/version reporting process but I wouldn't hold my breath for a fix, as things stand the version reported only changes when the kernel is updated, or if you recompile it after the update. It would be nice if the version of the OS itself was stored in something like /etc/freebsd-version so you know what the version of the OS as a Yes it would. sysctl kern.version ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
Da Rock wrote: sysctl kern.version For me, that's the same info as in uname -a. Try this: grep -v # /usr/src/sys/conf/newvers.sh | head -4 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On Wed, Apr 24, 2013, at 18:07, Mike Brown wrote: Da Rock wrote: sysctl kern.version For me, that's the same info as in uname -a. Try this: grep -v # /usr/src/sys/conf/newvers.sh | head -4 Not useful if you don't have src on your servers, but that's good to know. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On 04/25/13 09:07, Mike Brown wrote: Da Rock wrote: sysctl kern.version For me, that's the same info as in uname -a. Try this: grep -v # /usr/src/sys/conf/newvers.sh | head -4 That shows even less. But the point of the OP was having a file in etc with the info on version, which I fell could be redundant given the excessive detail available in sysctl which is what it is meant for. uname actually refers to the sysctl as a neat command for a shell user, doesn't it? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On Wed, Apr 24, 2013, at 20:41, Da Rock wrote: On 04/25/13 09:07, Mike Brown wrote: Da Rock wrote: sysctl kern.version For me, that's the same info as in uname -a. Try this: grep -v # /usr/src/sys/conf/newvers.sh | head -4 That shows even less. But the point of the OP was having a file in etc with the info on version, which I fell could be redundant given the excessive detail available in sysctl which is what it is meant for. uname actually refers to the sysctl as a neat command for a shell user, doesn't it? The point is that the uname and sysctl output is inaccurate. If the latest release is -p6 and the kernel hasn't been touched since -p4, both uname and the sysctl only show -p4. It's impossible to tell otherwise that the system is really -p6 if you don't have /usr/src/. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On Wed, 24 Apr 2013 21:13:56 -0500, Mark Felder wrote: The point is that the uname and sysctl output is inaccurate. If the latest release is -p6 and the kernel hasn't been touched since -p4, both uname and the sysctl only show -p4. It's impossible to tell otherwise that the system is really -p6 if you don't have /usr/src/. The src component can be updated using the appropriate entry in /etc/freebsd-update.conf so the information is there, no matter if the kernel has been touched or not. In my opinion, it could be helpful to have a somehow more precise information about what version of the OS is currently installed. I suggest having a text file in /etc that contains the currently installed version, maybe also a SVN revision number and a date. Updating via freebsd-update should not be that complicated. Also by updating from source (e. g. when following -STABLE where no X.Y-pZ version information is provided) this file could be installed properly. By checking this file the user could quickly retrieve the required information in a quickly understandable form. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On 4/24/2013 at 5:07 PM Mike Brown wrote: |Da Rock wrote: | sysctl kern.version | |For me, that's the same info as in uname -a. | |Try this: | |grep -v # /usr/src/sys/conf/newvers.sh | head -4 = If uname -r [-a] does not give the proper version of the OS, then it is either a bug, or the documentation for uname should be changed. Currently, the man page for uname gives the following option: -r Write the current release level of the operating system to stan- dard output. If you need to do grep -v # /usr/src/sys/conf/newvers.sh | head -4 in order to write the correct and current release level of the operating system to standard output, then perhaps uname should be fixed to accommodate freebsd update's partial update process of the OS. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On Wed, 24 Apr 2013 22:32:17 -0400, Mike. wrote: If uname -r [-a] does not give the proper version of the OS, then it is either a bug, or the documentation for uname should be changed. Currently, the man page for uname gives the following option: -r Write the current release level of the operating system to stan- dard output. Also the manpage of uname(3) would require a change to make clear that the version of the _kernel_ is provided, which _may_ stay the same during patchlevels of a given version. From that point of view, if we consider the patchlevel _not_ being part of the OS _version_, the statement (as it currently reads) makes sense. The understanding is: Version 9.1 is the OS version, and if a patch has been added, it's still 9.1 (even though the more precise information is 9.1-p5 for example). Similarly consider followint -STABLE: in this case, 9-STABLE or 9.1-STABLE is being reported, because no precise version numbers exist on that branch (at least not in the terms of patchlevels, instead a repository revision number or the date of the checkout could be considered for precision). The uname program relies on the uname system call to get the system identification, which queries the information stored in a (struct utsname *) data structure: The uname() function stores NUL-terminated strings of information identi- fying the current system into the structure referenced by name. The utsname structure is defined in the sys/utsname.h header file, and contains the following members: release Release level of the operating system. version Version level of the operating system. This part of documentation would, given the case, also require adjustment, refering to the kernel instead of the OS. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On 4/25/2013 at 4:47 AM Polytropon wrote: |On Wed, 24 Apr 2013 22:32:17 -0400, Mike. wrote: | If uname -r [-a] does not give the proper version of the OS, then it is | either a bug, or the documentation for uname should be changed. | Currently, the man page for uname gives the following option: | | -r Write the current release level of the operating system to | stan- | dard output. | |Also the manpage of uname(3) would require a change to make clear |that the version of the _kernel_ is provided, which _may_ stay the |same during patchlevels of a given version. From that point of |view, if we consider the patchlevel _not_ being part of the OS |_version_, the statement (as it currently reads) makes sense. |The understanding is: Version 9.1 is the OS version, and if |a patch has been added, it's still 9.1 (even though the more |precise information is 9.1-p5 for example). Similarly consider |followint -STABLE: in this case, 9-STABLE or 9.1-STABLE is being |reported, because no precise version numbers exist on that |branch (at least not in the terms of patchlevels, instead a |repository revision number or the date of the checkout could |be considered for precision). | |The uname program relies on the uname system call to get the |system identification, which queries the information stored in a |(struct utsname *) data structure: | | The uname() function stores NUL-terminated strings of information |identi- | fying the current system into the structure referenced by name. | | | The utsname structure is defined in the sys/utsname.h header file, |and | contains the following members: | | release Release level of the operating system. | | version Version level of the operating system. | |This part of documentation would, given the case, also require |adjustment, refering to the kernel instead of the OS. = On the other hand, maybe instead of changing the documentation of uname to accommodate a problem with freebsd update, maybe freebsd update should be changed to accommodate the historical and expected performance of uname. In other words, once I found out this problem with freebsd update (i.e., not properly refreshing the OS version), I stopped using it, as I was not able to ascertain the current state of my OS installation anymore. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On 04/25/13 13:32, Mike. wrote: On 4/25/2013 at 4:47 AM Polytropon wrote: |On Wed, 24 Apr 2013 22:32:17 -0400, Mike. wrote: | If uname -r [-a] does not give the proper version of the OS, then it is | either a bug, or the documentation for uname should be changed. | Currently, the man page for uname gives the following option: | | -r Write the current release level of the operating system to | stan- |dard output. | |Also the manpage of uname(3) would require a change to make clear |that the version of the _kernel_ is provided, which _may_ stay the |same during patchlevels of a given version. From that point of |view, if we consider the patchlevel _not_ being part of the OS |_version_, the statement (as it currently reads) makes sense. |The understanding is: Version 9.1 is the OS version, and if |a patch has been added, it's still 9.1 (even though the more |precise information is 9.1-p5 for example). Similarly consider |followint -STABLE: in this case, 9-STABLE or 9.1-STABLE is being |reported, because no precise version numbers exist on that |branch (at least not in the terms of patchlevels, instead a |repository revision number or the date of the checkout could |be considered for precision). | |The uname program relies on the uname system call to get the |system identification, which queries the information stored in a |(struct utsname *) data structure: | | The uname() function stores NUL-terminated strings of information |identi- | fying the current system into the structure referenced by name. | | | The utsname structure is defined in the sys/utsname.h header file, |and | contains the following members: | | release Release level of the operating system. | | version Version level of the operating system. | |This part of documentation would, given the case, also require |adjustment, refering to the kernel instead of the OS. = On the other hand, maybe instead of changing the documentation of uname to accommodate a problem with freebsd update, maybe freebsd update should be changed to accommodate the historical and expected performance of uname. In other words, once I found out this problem with freebsd update (i.e., not properly refreshing the OS version), I stopped using it, as I was not able to ascertain the current state of my OS installation anymore. Interesting. My only observation was that sysctl is supposed to be the 'system' database where all queries relate to. It is supposed to display everything about the system; therefore any of these data bits should be fixed here first. Anything else would be a 'feature' :) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On Thu, 25 Apr 2013 08:43:59 +1000 Da Rock freebsd-questi...@herveybayaustralia.com.au wrote: On 04/25/13 06:31, Steve O'Hara-Smith wrote: On Wed, 24 Apr 2013 14:52:17 -0500 Mark Felder f...@feld.me wrote: On Wed, 24 Apr 2013 14:34:30 -0500, Steve O'Hara-Smith st...@sohara.org wrote: You have updated to 9.1-RELEASE-p2 - but since there have been no kernel changes since 9.1-RELEASE the kernel version message hasn't changed. This could very reasonably be regarded as bug in the update/version reporting process but I wouldn't hold my breath for a fix, as things stand the version reported only changes when the kernel is updated, or if you recompile it after the update. It would be nice if the version of the OS itself was stored in something like /etc/freebsd-version so you know what the version of the OS as a Yes it would. sysctl kern.version The problem under discussion is that the kernel version does not change when a freebsd-update update does not include a kernel change. -- Steve O'Hara-Smith st...@sohara.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD-update?
On Thu, 25 Apr 2013 13:43:03 +1000 Da Rock freebsd-questi...@herveybayaustralia.com.au wrote: Interesting. My only observation was that sysctl is supposed to be the 'system' database where all queries relate to. It is supposed to display everything about the system; therefore any of these data bits should be fixed here first. Anything else would be a 'feature' :) That would be nice - one way to achieve that would be to add a writable oid for patch level and not bump newvers.sh for patches. -- Steve O'Hara-Smith st...@sohara.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Keeping FreeBSD with custom kernel up to date: freebsd-update no option?
Thank you, Polytropon. I have (as far as I can tell) successfully upgraded to 9.1-RELEASE-p2 now. For this I moved /usr/src (SVN) out of the way and followed the upgrade process described in 25.2.3.2 Performing the Upgrade in the Handbook [1]. on 17.4.13 22:55 Polytropon said the following: On Wed, 17 Apr 2013 22:37:06 +0200, andreas scherrer wrote: For some reason I was under the impression that /usr/src/sys is not being updated by freebsd-update if I remove kernel from the Components directive in freebsd-update.conf. But I might be wrong (I will check). According to the documentation, /usr/src (and therefor the /usr/src/sys subtree) is part of the src component, not of kernel, so it should be updated properly. OK. I will check if my /usr/src(/sys) ever changes now. I too think it should. Maybe related to this: how does freebsd-update know what sources/binaries to get when I don't use the -r switch? Does it rely on /usr/src/sys/conf/newvers.sh? That would still interest me (also see below). By following -RELEASE, freebsd-update will apply _that_ snapshot of the source tree and the prebuild world and kernel at the revision when X.Y-RELEASE-pZ has been verified, sloppily said. So it basically doesn't matter what sources you have on your machine (or even if you have any sources) as long as you're not going to compile anything. But because this is a requirement in your specific setting, freebsd-update will take care of that by having the src component on its list. So how would I follow -RELEASE. Or how does freebsd-update what I want to follow (see above)? I don't want to, so this is an academic question... And something else is bugging me: Is there a way I can contact someone (Tom Rhodes?) about the outdated freebsd-update documentation (concerning the custom kernel handling) in the Handbook (FreeBSD Update [2])? Colin Percival's email is in the man page, would that be the way to go? The Handbook states that Tom Rhodes wrote the freebsd-update section but does not reveal an email address... Kind regards andreas [1] http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html [2] http://www.freebsd.org/doc/en/books/handbook/updating-upgrading-freebsdupdate.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Keeping FreeBSD with custom kernel up to date: freebsd-update no option?
Hi Andreas and Polytropon,
In the case your are tracking -RELEASE branch, you can use freebsd-update
tool to apply binary security patches on your system and upgrade versions
(e.g. 9.0 to 9.1 or 9.x to 10.0 when available).
Freebsd-update tool apply binary updates to your system and GENERIC kernel.
Furthermore, this tool syncs sources (by default). So if you are using
custom kernel, you just have to rebuild and install your custom kernel.
It is recommended to not use SVN to update your system sources if you are
using freebsd-update tool to avoid troubles.
Regards,
Alexandre
On Tue, Apr 16, 2013 at 10:18 PM, Polytropon free...@edvax.de wrote:
On Tue, 16 Apr 2013 21:38:16 +0200, andreas scherrer wrote:
Dear FreeBSD savvies
I am (still) struggling to understand how to keep my FreeBSD system up
to date (world/system, not ports). I want to track RELEASE (not a
development branch) and I want to receive security related updates. And
I want to run a custom kernel.
Without actually havint tested it, it seems that if you want
to use freebsd-update (binary updating), you should note this:
In /etc/freebsd-update.conf, you should have the line for what
to update as Components src world.
This should prevent overwriting of the kernel, but you need to
compile your kernel and install it. The component src will
make sure you have the proper kernel sources. I assume a custom
kernel configuration file in /usr/src/sys/{i386|amd64}/conf/
is _not_ being overwritten by freebsd-update.
Use the -r option of freebsd-update to specify the correct
release if required. It should follow -RELEASE-pN for the
currentl patchlevel N (which you intend to follow) normally.
From what I understand I cannot use freebsd-update in this case
because it will invariably either overwrite my custom kernel (if I have
Components kernel in the config file) or not update the kernel sources
in /usr/src/sys (when I do not have Components kernel in the config
file). See [1].
As far as I read from man freebsd-update.conf, the src component
will not exclude kernel sources; kernel refers to the kernel and
the modules as binary stuff.
This is the relevant text passage:
The components are ``src''
(source code), ``world'' (non-kernel binaries),
and ``kernel''; the sub-components are the indi-
vidual distribution sets generated as part of
the release process (e.g., ``src/base'',
``src/sys'', ``world/base'', ``world/catpages'',
``kernel/smp''). Note that prior to
FreeBSD 6.1, the ``kernel'' component was dis-
tributed as part of ``world/base''.
So src will include src/sys which is the kernel sources you
will need to build your custom kernel.
This leaves me with the only possibility to use SVN to update /usr/src,
right?
No, but it might be the more advanced alternative, and it should
work. Note that in _this_ case, you will also have to rebuild the
world, so kernel and world are in sync after an update. Refer to
the comment header of /usr/src/Makefile for the whole process that
has to be performed after updating (or see in the Handbook: the
section about updating by source).
I have a copy of the SVN sources (for the outdated RELEASE-9.0.0
but that's a different story), see below for svn info). As I
understand [2] I cannot mix freebsd-update and SVN, right?
It could cause trouble. Deciding for _one_ way should be better.
So I can run svn update in /usr/src whenever I like. But what then? Do
I need to rebuild the world and my custom kernel every time I run svn
update (and there are some updates)?
Yes, or better: As soon as it is required. This depends on _what_
has been part of the update. For example, kernel updates _can_
require updates of userland programs or libraries, but it's also
possible that it's not the case. To be sure, rebuild.
I'm on a low powered consumer
device and it takes considerable amount of time to build the world and
kernel (plus I still don't feel comfortable doing such tasks remotely).
In this case, use freebsd-update as explained at the beginning of
my message: Update components world and src, leave out kernel,
the rebuild the kernel by source and install it. Then reboot.
Is this really the way to do it or am I missing something?
There are _several_ ways to do it. :-)
There are quite some posts, websites and threads out there (see [3] or
[4] for example) about this topic but (surprisingly?) I could not (yet)
find a conclusive answer.
This is because the answer depends on what you actually want to do
(follow RELEASE, STABLE, CURRENT), and how you want to do it (binary,
by source).
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
Re: Keeping FreeBSD with custom kernel up to date: freebsd-update no option?
Thank you very much for your detailed answer!
on 16.4.13 22:18 Polytropon said the following:
On Tue, 16 Apr 2013 21:38:16 +0200, andreas scherrer wrote:
I am (still) struggling to understand how to keep my FreeBSD system up
to date (world/system, not ports). I want to track RELEASE (not a
development branch) and I want to receive security related updates. And
I want to run a custom kernel.
Without actually havint tested it, it seems that if you want
to use freebsd-update (binary updating), you should note this:
In /etc/freebsd-update.conf, you should have the line for what
to update as Components src world.
That's what I thought (and currently have).
This should prevent overwriting of the kernel, but you need to
compile your kernel and install it. The component src will
make sure you have the proper kernel sources. I assume a custom
kernel configuration file in /usr/src/sys/{i386|amd64}/conf/
is _not_ being overwritten by freebsd-update.
A custom kernel configuration file is *not* overwritten by
freebsd-update, I can confirm this. Of course I will have to compile and
install my custom kernel manually.
For some reason I was under the impression that /usr/src/sys is not
being updated by freebsd-update if I remove kernel from the
Components directive in freebsd-update.conf. But I might be wrong (I
will check).
Maybe related to this: how does freebsd-update know what
sources/binaries to get when I don't use the -r switch? Does it rely
on /usr/src/sys/conf/newvers.sh?
Could it be that I never saw a change to my kernel sources
(/usr/src/sys) because freebsd-update was tracking some static sources?
[snip]
I'm on a low powered consumer
device and it takes considerable amount of time to build the world and
kernel (plus I still don't feel comfortable doing such tasks remotely).
In this case, use freebsd-update as explained at the beginning of
my message: Update components world and src, leave out kernel,
the rebuild the kernel by source and install it. Then reboot.
That's what I am planning to do. Let's see.
As I currently have a checkout from SVN in /urs/src I need to get rid of
this. Can I just copy (read: move) back my previous /usr/src directory
and continue to use freebsd-update? I think this should work, right? I
am just not sure if freebsd-update still knows what sources/binaries
to track (see my previous comment about how freebsd-update knows what
source to use).
Cheers
andreas
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Keeping FreeBSD with custom kernel up to date: freebsd-update no option?
On Wed, 17 Apr 2013 22:37:06 +0200, andreas scherrer wrote: For some reason I was under the impression that /usr/src/sys is not being updated by freebsd-update if I remove kernel from the Components directive in freebsd-update.conf. But I might be wrong (I will check). According to the documentation, /usr/src (and therefor the /usr/src/sys subtree) is part of the src component, not of kernel, so it should be updated properly. Maybe related to this: how does freebsd-update know what sources/binaries to get when I don't use the -r switch? Does it rely on /usr/src/sys/conf/newvers.sh? Could it be that I never saw a change to my kernel sources (/usr/src/sys) because freebsd-update was tracking some static sources? Not neccessarily. For example, if only a userland program has received a security update, and the kernel was kept the same, no change would be done in /usr/src/sys. In this case, the kernel version output (as seen by the uname program) would not have changed. As I currently have a checkout from SVN in /urs/src I need to get rid of this. Can I just copy (read: move) back my previous /usr/src directory and continue to use freebsd-update? You should not switch between both methods, it may cause problems. The simplest way would be to # mv /usr/src /usr/src.svn and let freebsd-update populate the sources with the required version. Note that it will install the world your (custom) kernel will finally have to match, and so it should make sure you have the correct revision of the sources to avoid a version conflict. However, it's basically not a problem to use SVN to track -RELEASE, but in this case, you should recompile world and kernel from that sources, instead of relying on freebsd-update for a binary update of the world only. But as you said you're only interested in a custom kernel (which _requires_ building from source), you can safely leave everything else to freebsd-update and don't use SVN. (It would be a totally different thing if you would track -STABLE or -CURRENT which is not possible with freebsd-update, and which would _force_ you to build everything from source.) By following -RELEASE, freebsd-update will apply _that_ snapshot of the source tree and the prebuild world and kernel at the revision when X.Y-RELEASE-pZ has been verified, sloppily said. So it basically doesn't matter what sources you have on your machine (or even if you have any sources) as long as you're not going to compile anything. But because this is a requirement in your specific setting, freebsd-update will take care of that by having the src component on its list. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Keeping FreeBSD with custom kernel up to date: freebsd-update no option?
Dear FreeBSD savvies I am (still) struggling to understand how to keep my FreeBSD system up to date (world/system, not ports). I want to track RELEASE (not a development branch) and I want to receive security related updates. And I want to run a custom kernel. From what I understand I cannot use freebsd-update in this case because it will invariably either overwrite my custom kernel (if I have Components kernel in the config file) or not update the kernel sources in /usr/src/sys (when I do not have Components kernel in the config file). See [1]. This leaves me with the only possibility to use SVN to update /usr/src, right? I have a copy of the SVN sources (for the outdated RELEASE-9.0.0 but that's a different story), see below for svn info). As I understand [2] I cannot mix freebsd-update and SVN, right? So I can run svn update in /usr/src whenever I like. But what then? Do I need to rebuild the world and my custom kernel every time I run svn update (and there are some updates)? I'm on a low powered consumer device and it takes considerable amount of time to build the world and kernel (plus I still don't feel comfortable doing such tasks remotely). Is this really the way to do it or am I missing something? There are quite some posts, websites and threads out there (see [3] or [4] for example) about this topic but (surprisingly?) I could not (yet) find a conclusive answer. Any hints, help, tutorials or corrections would be greatly appreciated. Kind regards andreas [1] http://lists.freebsd.org/pipermail/freebsd-questions/2013-January/247763.html [2] http://lists.freebsd.org/pipermail/freebsd-questions/2013-April/250461.html [3] http://forums.freebsd.org/showthread.php?t=26140 [4] http://forums.freebsd.org/showthread.php?t=3 - # svn info Path: . Working Copy Root Path: /usr/src URL: https://svn0.us-east.freebsd.org/base/release/9.0.0 Repository Root: https://svn0.us-east.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 248546 Node Kind: directory Schedule: normal Last Changed Author: kensmith Last Changed Rev: 229307 Last Changed Date: 2012-01-02 19:59:55 +0100 (Mon, 02 Jan 2012) - Ps.: Is there a way I can contact someone (Tom Rhodes?) about the outdated freebsd-update documentation (concerning the custom kernel handling) in the Handbook (FreeBSD Update [5])? [5] http://www.freebsd.org/doc/en/books/handbook/updating-upgrading-freebsdupdate.html ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Keeping FreeBSD with custom kernel up to date: freebsd-update no option?
On Tue, 16 Apr 2013 21:38:16 +0200, andreas scherrer wrote:
Dear FreeBSD savvies
I am (still) struggling to understand how to keep my FreeBSD system up
to date (world/system, not ports). I want to track RELEASE (not a
development branch) and I want to receive security related updates. And
I want to run a custom kernel.
Without actually havint tested it, it seems that if you want
to use freebsd-update (binary updating), you should note this:
In /etc/freebsd-update.conf, you should have the line for what
to update as Components src world.
This should prevent overwriting of the kernel, but you need to
compile your kernel and install it. The component src will
make sure you have the proper kernel sources. I assume a custom
kernel configuration file in /usr/src/sys/{i386|amd64}/conf/
is _not_ being overwritten by freebsd-update.
Use the -r option of freebsd-update to specify the correct
release if required. It should follow -RELEASE-pN for the
currentl patchlevel N (which you intend to follow) normally.
From what I understand I cannot use freebsd-update in this case
because it will invariably either overwrite my custom kernel (if I have
Components kernel in the config file) or not update the kernel sources
in /usr/src/sys (when I do not have Components kernel in the config
file). See [1].
As far as I read from man freebsd-update.conf, the src component
will not exclude kernel sources; kernel refers to the kernel and
the modules as binary stuff.
This is the relevant text passage:
The components are ``src''
(source code), ``world'' (non-kernel binaries),
and ``kernel''; the sub-components are the indi-
vidual distribution sets generated as part of
the release process (e.g., ``src/base'',
``src/sys'', ``world/base'', ``world/catpages'',
``kernel/smp''). Note that prior to
FreeBSD 6.1, the ``kernel'' component was dis-
tributed as part of ``world/base''.
So src will include src/sys which is the kernel sources you
will need to build your custom kernel.
This leaves me with the only possibility to use SVN to update /usr/src,
right?
No, but it might be the more advanced alternative, and it should
work. Note that in _this_ case, you will also have to rebuild the
world, so kernel and world are in sync after an update. Refer to
the comment header of /usr/src/Makefile for the whole process that
has to be performed after updating (or see in the Handbook: the
section about updating by source).
I have a copy of the SVN sources (for the outdated RELEASE-9.0.0
but that's a different story), see below for svn info). As I
understand [2] I cannot mix freebsd-update and SVN, right?
It could cause trouble. Deciding for _one_ way should be better.
So I can run svn update in /usr/src whenever I like. But what then? Do
I need to rebuild the world and my custom kernel every time I run svn
update (and there are some updates)?
Yes, or better: As soon as it is required. This depends on _what_
has been part of the update. For example, kernel updates _can_
require updates of userland programs or libraries, but it's also
possible that it's not the case. To be sure, rebuild.
I'm on a low powered consumer
device and it takes considerable amount of time to build the world and
kernel (plus I still don't feel comfortable doing such tasks remotely).
In this case, use freebsd-update as explained at the beginning of
my message: Update components world and src, leave out kernel,
the rebuild the kernel by source and install it. Then reboot.
Is this really the way to do it or am I missing something?
There are _several_ ways to do it. :-)
There are quite some posts, websites and threads out there (see [3] or
[4] for example) about this topic but (surprisingly?) I could not (yet)
find a conclusive answer.
This is because the answer depends on what you actually want to do
(follow RELEASE, STABLE, CURRENT), and how you want to do it (binary,
by source).
--
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Keeping FreeBSD uptodate with svn, freebsd-update complaining
[I wasn't sure what the most appropriate list for this issue is...] Hello! Recently (after the latest OpenSSL security issue) I have updated my FreeBSD install from source. i.e., I have updated my source tree (under /usr/src) with svn and did the buildworld/buildkernel/installkernel/mergemaster/installworld/mergemaster procedure. For completeness: My source tree contains this code revision: URL: https://svn0.us-west.freebsd.org/base/releng/9.1 Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 249029 This was my first time, but I was following the handbook closely and everything seems to have worked just fine. # uname -a FreeBSD XXX 9.1-RELEASE-p2 FreeBSD 9.1-RELEASE-p2 #5 r249029: Wed Apr 3 12:29:28 CEST 2013 root@XXX:/usr/obj/usr/src/sys/FUGLOS amd64 But what I don't understand is the following. Whenever I execute 'freebsd-update fetch' (I had added a 'freebsd-update cron' to my crontab), the output below(!) is generated. It's not clear to me what this actually means: * Why does freebsd-update want to update my system to 9.1-RELEASE-p2, although I _am_ running that version already? * Why does it want to update that specific list of files? This is just a subset of of the the binary files which should have been installed from installworld. What is special about this subset? * What is the proper way to 'resolve' this situation? I would be happy about some insights/pointers/help here! Thank you very much, melanie -- From: Charlie root@XXX Date: Thu, 11 Apr 2013 03:58:36 +0200 To: root Subject: XXX security updates Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 9.1-RELEASE from update4.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. The following files are affected by updates, but no changes have been downloaded because the files have been modified locally: /var/db/mergemaster.mtree The following files will be updated as part of updating to 9.1-RELEASE-p2: /lib/libc.so.7 /lib/libcrypto.so.6 /rescue/[ /rescue/atacontrol /rescue/atmconfig /rescue/badsect /rescue/bsdlabel /rescue/bunzip2 /rescue/bzcat /rescue/bzip2 /rescue/camcontrol /rescue/cat /rescue/ccdconfig /rescue/chflags /rescue/chgrp /rescue/chio /rescue/chmod /rescue/chown /rescue/chroot /rescue/clri /rescue/cp /rescue/csh /rescue/date /rescue/dd /rescue/devfs /rescue/df /rescue/dhclient /rescue/disklabel /rescue/dmesg /rescue/dump /rescue/dumpfs /rescue/dumpon /rescue/echo /rescue/ed /rescue/ex /rescue/expr /rescue/fastboot /rescue/fasthalt /rescue/fdisk /rescue/fsck /rescue/fsck_4.2bsd /rescue/fsck_ffs /rescue/fsck_msdosfs /rescue/fsck_ufs /rescue/fsdb /rescue/fsirand /rescue/gbde /rescue/geom /rescue/getfacl /rescue/glabel /rescue/gpart /rescue/groups /rescue/gunzip /rescue/gzcat /rescue/gzip /rescue/halt /rescue/head /rescue/hostname /rescue/id /rescue/ifconfig /rescue/init /rescue/ipf /rescue/kenv /rescue/kill /rescue/kldconfig /rescue/kldload /rescue/kldstat /rescue/kldunload /rescue/ldconfig /rescue/link /rescue/ln /rescue/ls /rescue/lzcat /rescue/lzma /rescue/md5 /rescue/mdconfig /rescue/mdmfs /rescue/mkdir /rescue/mknod /rescue/mount /rescue/mount_cd9660 /rescue/mount_msdosfs /rescue/mount_nfs /rescue/mount_ntfs /rescue/mount_nullfs /rescue/mount_udf /rescue/mount_unionfs /rescue/mt /rescue/mv /rescue/nc /rescue/newfs /rescue/newfs_msdos /rescue/nos-tun /rescue/pgrep /rescue/ping /rescue/ping6 /rescue/pkill /rescue/ps /rescue/pwd /rescue/rcorder /rescue/rcp /rescue/rdump /rescue/realpath /rescue/reboot /rescue/red /rescue/rescue /rescue/restore /rescue/rm /rescue/rmdir /rescue/route /rescue/routed /rescue/rrestore /rescue/rtquery /rescue/rtsol /rescue/savecore /rescue/sed /rescue/setfacl /rescue/sh /rescue/spppcontrol /rescue/stty /rescue/swapon /rescue/sync /rescue/sysctl /rescue/tail /rescue/tar /rescue/tcsh /rescue/tee /rescue/test /rescue/tunefs /rescue/umount /rescue/unlink /rescue/unlzma /rescue/unxz /rescue/vi /rescue/whoami /rescue/xz /rescue/xzcat /rescue/zcat /rescue/zfs /rescue/zpool /sbin/restore /sbin/rrestore /usr/bin/dc /usr/bin/dig /usr/bin/ftp /usr/bin/gate-ftp /usr/bin/host /usr/bin/kadmin /usr/bin/login /usr/bin/nslookup /usr/bin/nsupdate /usr/bin/ntpq /usr/bin/openssl /usr/bin/pftp /usr/bin/sftp /usr/bin/slogin /usr/bin/ssh /usr/bin/ssh-add /usr/bin/ssh-agent /usr/bin/telnet /usr/games/factor /usr/lib/libc.a /usr/lib/libc_p.a /usr/lib/libc_pic.a /usr/lib/libcrypto.a /usr/lib/libcrypto_p.a /usr/lib/libfetch.a /usr/lib/libfetch.so.6 /usr/lib/libfetch_p.a /usr/lib/libgssapi_krb5.a /usr/lib/libgssapi_krb5.so.10 /usr/lib/libgssapi_krb5_p.a /usr/lib/libgssapi_ntlm.a /usr/lib/libgssapi_ntlm.so.10 /usr/lib/libgssapi_ntlm_p.a /usr/lib/libhdb.a /usr/lib/libhdb_p.a /usr/lib/libhx509.a /usr/lib/libhx509.so.10 /usr/lib/libhx509_p.a /usr/lib/libkrb5
Re: Keeping FreeBSD uptodate with svn, freebsd-update complaining
On 12/04/2013 09:19, Melanie Schulte wrote: [I wasn't sure what the most appropriate list for this issue is...] Hello! Recently (after the latest OpenSSL security issue) I have updated my FreeBSD install from source. i.e., I have updated my source tree (under /usr/src) with svn and did the buildworld/buildkernel/installkernel/mergemaster/installworld/mergemaster procedure. For completeness: My source tree contains this code revision: URL: https://svn0.us-west.freebsd.org/base/releng/9.1 Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 249029 This was my first time, but I was following the handbook closely and everything seems to have worked just fine. # uname -a FreeBSD XXX 9.1-RELEASE-p2 FreeBSD 9.1-RELEASE-p2 #5 r249029: Wed Apr 3 12:29:28 CEST 2013 root@XXX:/usr/obj/usr/src/sys/FUGLOS amd64 But what I don't understand is the following. Whenever I execute 'freebsd-update fetch' (I had added a 'freebsd-update cron' to my crontab), the output below(!) is generated. It's not clear to me what this actually means: * Why does freebsd-update want to update my system to 9.1-RELEASE-p2, although I _am_ running that version already? * Why does it want to update that specific list of files? This is just a subset of of the the binary files which should have been installed from installworld. What is special about this subset? * What is the proper way to 'resolve' this situation? I would be happy about some insights/pointers/help here! Thank you very much, melanie Hi, Melanie, Your main problem here is trying to mix usage of SVN with usage of freebsd-update. You can use either one of those methods but not both. Unless you prefer to build your own, I'd recommend sticking with freebsd-update. It's much simpler and quicker to keep your systems up to date than the alternative. To recover from the mix of files you have from freebsd-update and self-compiled, it should be sufficient to run 'freebsd-update install' This is going to rewrite all the files that freebsd-update knows about that were altered by your self-built update: ie. most of the OS. Definitely make sure you have good backups before doing that. Yes, it may say 'upgrading to 9.1-RELEASE-p2' but that's because it is comparing against the previous version you got from freebsd-update, not what you compiled yourself. The list of files it shows are specifically the files that were changed between FreeBSD 9.1-RELEASE-p1 and 9.1-RELEASE-p2. freebsd-update is fast largely because it only installs the changed bits onto your system. Cheers, Matthew ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Keeping FreeBSD uptodate with svn, freebsd-update complaining
Thank you, Matthew! That answers all of my questions. :-) I've done a freebsd-update install and it seems to have resolved the situation alright. ~ melanie -- M. Schulte -- mail jabber: m...@fuglos.org http://m.fuglos.org/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
freebsd-update problems
I ran freebsd-update to update my 8.1-RELEASE system to 8.3-RELEASE (freebsd-update -r 8.3-RELEASE upgrade). It downloaded a bunch of files, asked me to edit some configuration files, showed me long lists of files that have been changed, added and removed, and then ended with no status or error indications. The problem is that there appears to be absolutely NO change in my system that I can find. I have checked /etc, /bin, and /lib with 'ls -lct | head', but there are no files that have changed recently. The /var/db/freebsd-update directory has over 500MB of files it downloaded. Does anybody have any suggestions on what might have happened and what can be done? -- Carl Johnsonca...@peak.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update problems
On Fri, Feb 01, 2013 at 11:51:41AM -0800, Carl Johnson wrote: I ran freebsd-update to update my 8.1-RELEASE system to 8.3-RELEASE (freebsd-update -r 8.3-RELEASE upgrade). It downloaded a bunch of files, asked me to edit some configuration files, showed me long lists of files that have been changed, added and removed, and then ended with no status or error indications. The problem is that there appears to be absolutely NO change in my system that I can find. I have checked /etc, /bin, and /lib with 'ls -lct | head', but there are no files that have changed recently. The /var/db/freebsd-update directory has over 500MB of files it downloaded. Does anybody have any suggestions on what might have happened and what can be done? -- Carl Johnson ca...@peak.org I'm not looking at the docs ATM, but IIRC you need to run an install step now. Check the docs ... they should tell you. HTH, Kevin Kinsey ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update problems
Fri, 01 Feb 2013 11:51:41 -0800 tarihinde Carl Johnson ca...@peak.org yazmış: Does anybody have any suggestions on what might have happened and what can be done? Hello Carl, What does # uname -a or # uname -r output says? -- Gökşin Akdeniz goksin.akde...@gmail.com pgpxkVgruffrn.pgp Description: PGP signature
Re: freebsd-update problems
Kevin Kinsey k...@daleco.biz writes: On Fri, Feb 01, 2013 at 11:51:41AM -0800, Carl Johnson wrote: I ran freebsd-update to update my 8.1-RELEASE system to 8.3-RELEASE (freebsd-update -r 8.3-RELEASE upgrade). It downloaded a bunch of files, asked me to edit some configuration files, showed me long lists of files that have been changed, added and removed, and then ended with no status or error indications. The problem is that there appears to be absolutely NO change in my system that I can find. I have checked /etc, /bin, and /lib with 'ls -lct | head', but there are no files that have changed recently. The /var/db/freebsd-update directory has over 500MB of files it downloaded. Does anybody have any suggestions on what might have happened and what can be done? -- Carl Johnson ca...@peak.org I'm not looking at the docs ATM, but IIRC you need to run an install step now. Check the docs ... they should tell you. Thanks, I just saw that a few minutes ago. I wasn't happy about it so I went out for a long walk, but I should have done it before posting. I'll try that right after this. -- Carl Johnsonca...@peak.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update problems
Gökşin Akdeniz goksin.akde...@gmail.com writes: Fri, 01 Feb 2013 11:51:41 -0800 tarihinde Carl Johnson ca...@peak.org yazmış: Does anybody have any suggestions on what might have happened and what can be done? Hello Carl, What does # uname -a or # uname -r output says? It still shows 8.1, but another poster just pointed out that I hadn't installed my upgrade. I need to read the man pages more carefully. Thanks. -- Carl Johnsonca...@peak.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update problems
On 01/02/2013 22:50, Carl Johnson wrote: Gökşin Akdeniz goksin.akde...@gmail.com writes: Fri, 01 Feb 2013 11:51:41 -0800 tarihinde Carl Johnson ca...@peak.org yazmış: Does anybody have any suggestions on what might have happened and what can be done? Hello Carl, What does # uname -a or # uname -r output says? It still shows 8.1, but another poster just pointed out that I hadn't installed my upgrade. I need to read the man pages more carefully. Thanks. Better link: http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html#freebsdupdate-using -- - Paul Macdonald IFDNRG Ltd Web and video hosting - t: 0131 5548070 m: 07970339546 e: p...@ifdnrg.com w: http://www.ifdnrg.com - IFDNRG 40 Maritime Street Edinburgh EH6 6SA High Specification Dedicated Servers from £100.00pm ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update problems
Carl Johnson ca...@peak.org writes: Kevin Kinsey k...@daleco.biz writes: On Fri, Feb 01, 2013 at 11:51:41AM -0800, Carl Johnson wrote: I ran freebsd-update to update my 8.1-RELEASE system to 8.3-RELEASE (freebsd-update -r 8.3-RELEASE upgrade). It downloaded a bunch of files, asked me to edit some configuration files, showed me long lists of files that have been changed, added and removed, and then ended with no status or error indications. The problem is that there appears to be absolutely NO change in my system that I can find. I have checked /etc, /bin, and /lib with 'ls -lct | head', but there are no files that have changed recently. The /var/db/freebsd-update directory has over 500MB of files it downloaded. Does anybody have any suggestions on what might have happened and what can be done? -- Carl Johnsonca...@peak.org I'm not looking at the docs ATM, but IIRC you need to run an install step now. Check the docs ... they should tell you. Thanks, I just saw that a few minutes ago. I wasn't happy about it so I went out for a long walk, but I should have done it before posting. I'll try that right after this. Everything looks good now: 'uname -r' now show '8.3-RELEASE-p3'. Thanks for the response. -- Carl Johnsonca...@peak.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update problems
On 01/02/2013 22:50, Carl Johnson wrote: Gökşin Akdeniz goksin.akde...@gmail.com writes: Fri, 01 Feb 2013 11:51:41 -0800 tarihinde Carl Johnson ca...@peak.org yazmış: Does anybody have any suggestions on what might have happened and what can be done? Hello Carl, What does # uname -a or # uname -r output says? It still shows 8.1, but another poster just pointed out that I hadn't installed my upgrade. I need to read the man pages more carefully. Thanks. Its well documented here, i've never had any problems yet.. http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html -- - Paul Macdonald IFDNRG Ltd Web and video hosting - t: 0131 5548070 m: 07970339546 e: p...@ifdnrg.com w: http://www.ifdnrg.com - IFDNRG 40 Maritime Street Edinburgh EH6 6SA High Specification Dedicated Servers from £100.00pm ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update problems
Paul Macdonald p...@ifdnrg.com writes: On 01/02/2013 22:50, Carl Johnson wrote: Gökşin Akdeniz goksin.akde...@gmail.com writes: Fri, 01 Feb 2013 11:51:41 -0800 tarihinde Carl Johnson ca...@peak.org yazmış: Does anybody have any suggestions on what might have happened and what can be done? Hello Carl, What does # uname -a or # uname -r output says? It still shows 8.1, but another poster just pointed out that I hadn't installed my upgrade. I need to read the man pages more carefully. Thanks. Better link: http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html#freebsdupdate-using Thanks, that link is much clearer than the version of the handbook that came with my 8.1 system. -- Carl Johnsonca...@peak.org ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
freebsd-update won't update 8.2-R-p9 to p10
I can't seem to get freebsd-update to do the jump from 9.2-RELEASE-p9 to p10. This is what I'm getting. sudo freebsd-update fetch Password: Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 8.2-RELEASE from update5.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. The following files are affected by updates, but no changes have been downloaded because the files have been modified locally: /var/db/mergemaster.mtree No updates needed to update system to 8.2-RELEASE-p10. WARNING: FreeBSD 8.2-RELEASE-p9 HAS PASSED ITS END-OF-LIFE DATE. Any security issues discovered after Wed Aug 1 00:00:00 UTC 2012 will not have been corrected. Note the complaint about mergemaster.mtree. I haven't modified that, so I'm not sure why it's complaining. It may be a red herring anyway though. However, since no changes have been downloaded, an install does nothing. sudo freebsd-update install No updates are available to install. Run '/usr/sbin/freebsd-update fetch' first. However, after a reboot, I'm still running p9. uname -a FreeBSD obfuscated.com 8.2-RELEASE-p9 FreeBSD 8.2-RELEASE-p9 #0: Mon Jun 11 23:00:11 UTC 2012 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 I'm running a generic kernel, which should be updated according to the freebsd-update docs. Any suggestions for how to get this to complete? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
freebsd-update IDS
Hi! I run freebsd-update on my upgraded FreeBSD 9.1-RELEASE and I got: /var/cache has 0755 permissions, but should have 0750 permissions I don't have a server. Should I change permission, please? Thank you. Mitja http://www.redbubble.com/people/lumiwa ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update: fale?
On Thu, Jan 03, 2013 at 03:50:44PM +0100, Martin Laabs wrote: Hi, On 01/02/13 01:21, Joe Altman wrote: Greetings, list. I have the following error; though I can load update5.FreeBSD.org in a browser: [...] maybe you use a release that is not supported by freebsd-update. Run uname -r an compare the release with that you see when looking at http://update4.freebsd.org/ If it is not there you can not use freebsd-update. Yes; I realized that after I revisited the man page and handbook; somehow I managed to miss that initially. I'm currently using 9.1-PRERELEASE. Now I am left to wonder how that state will last; ISTM that eventually 9.1 will be supported by freebsd-update but I cannot tell when that might happen. Given that CVSUP is going away soon, I can't see reinstalling it just for this unnecessary upgrade. Since I appear to be stuck between things, I have three questions: 1) Is there any way to guesstimate how long until 9.1 is supported by freebsd-update? 2) Am I correct in assuming that there is no good reason (security concerns, for instance) to update right now? I seem to have no problems with my system; it runs fine. 3) Does freebsd-update really require at least a Gig of space in /var for a major or minor upgrade? If so, it looks like I may as well reinstall the OS, since I never anticipated needing that much in /var. At this point, given the amount of 'portupgrade -fr' I'll need to do, it might consume less time to start from scratch. Thanks for the followup, and best regards, Joe ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update: fale?
Joe Altman wrote: On Thu, Jan 03, 2013 at 03:50:44PM +0100, Martin Laabs wrote: Hi, On 01/02/13 01:21, Joe Altman wrote: Greetings, list. I have the following error; though I can load update5.FreeBSD.org in a browser: [...] maybe you use a release that is not supported by freebsd-update. Run uname -r an compare the release with that you see when looking at http://update4.freebsd.org/ If it is not there you can not use freebsd-update. Yes; I realized that after I revisited the man page and handbook; somehow I managed to miss that initially. I'm currently using 9.1-PRERELEASE. Now I am left to wonder how that state will last; ISTM that eventually 9.1 will be supported by freebsd-update but I cannot tell when that might happen. Given that CVSUP is going away soon, I can't see reinstalling it just for this unnecessary upgrade. Since I appear to be stuck between things, I have three questions: 1) Is there any way to guesstimate how long until 9.1 is supported by freebsd-update? 2) Am I correct in assuming that there is no good reason (security concerns, for instance) to update right now? I seem to have no problems with my system; it runs fine. 3) Does freebsd-update really require at least a Gig of space in /var for a major or minor upgrade? If so, it looks like I may as well reinstall the OS, since I never anticipated needing that much in /var. At this point, given the amount of 'portupgrade -fr' I'll need to do, it might consume less time to start from scratch. Thanks for the followup, and best regards, Joe Heres a work around that should work. For your 9.1-PRERELEASE you can temporary change that so freebsd-update will work for you. Issue this console command on your system. setenv UNAME_r 9.0-RELEASE Now when you run freebsd-update it will think your system is 9.0-RELEASE and go through with the update to 9.1-RELEASE. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update: fale?
Hi, On 01/02/13 01:21, Joe Altman wrote: Greetings, list. I have the following error; though I can load update5.FreeBSD.org in a browser: [...] maybe you use a release that is not supported by freebsd-update. Run uname -r an compare the release with that you see when looking at http://update4.freebsd.org/ If it is not there you can not use freebsd-update. Best regards, Martin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update: fale?
Hi, On 01/02/13 01:21, Joe Altman wrote: Greetings, list. I have the following error; though I can load update5.FreeBSD.org in a browser: [...] maybe you use a release that is not supported by freebsd-update. Run uname -r an compare the release with that you see when looking at http://update4.freebsd.org/ If it is not there you can not use freebsd-update. Best regards, Martin ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
freebsd-update patches custom /boot/kernel/kernel which it should not
Hi This can be considered a follow up to the message How to keep freebsd-update from trashing custom kernel? sent to this list by Brett Glass on August 13th 2012 (see [1]). Unfortunately there is no solution to the problem in that thread (or I cannot see it). I am running currently running 9.0-RELEASE-p4 and freebsd-update recommends to update to p5. It states: - The following files will be updated as part of updating to 9.0-RELEASE-p5: /boot/kernel/kernel snip - And from experience this is what it will do: replace /boot/kernel/kernel which is my custom kernel with a GENERIC kernel. As it seems that freebsd-update works by comparing a hash of /boot/kernel/kernel with the GENERIC kernel's hash I checked the md5 and sha1 hash of /boot/kernel/kernel and /boot/GENERIC/kernel. They differ (see [3]). So why is freebsd-update going to overwrite my custom kernel? And how can I prevent it from doing so? By the way there is a post on superuser.com describing the same issue (see [2]). Best Regards andreas [1] http://freebsd.1045724.n5.nabble.com/How-to-keep-freebsd-update-from-trashing-custom-kernel-tt5733932.html#none [2] http://superuser.com/questions/507322/freebsd-update-patches-custom-boot-kernel-kernel-which-breaks-remote-access [3] # md5 /boot/kernel/kernel MD5 (/boot/kernel/kernel) = 5757af02283522328c3537b8550a286a # sha1 /boot/kernel/kernel SHA1 (/boot/kernel/kernel) = a513c6d0d0a71fa5d74156c000952a5211e41465 # md5 /boot/GENERIC/kernel MD5 (/boot/GENERIC/kernel) = 3795c8766abf8e16088b5f1305931483 # sha1 /boot/GENERIC/kernel SHA1 (/boot/GENERIC/kernel) = 3a32246b3ce5f13ddeef336c010adf8f354443da ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Newbie question about freebsd-update: single user mode is not needed anymore?
Well, I understand your concern. I've been using the freebsd-update method since several years now and mostly remotely. I've never encounter a problem. I haven't recompiled everything many times as I didn't really found a tangible advantage in this method but I've never thought about this. I believe some developer around here can provide you a neat explanation about that (which is going to be interesting to know). Strictly about your concern I believe whatever way you use for your upgrade you CANNOT be 100% sure that your upgrade will go smoothly and things like loosing control of your remote box will not happen. Even though jumping from close releases 9.0 = 9.1 is a low risk upgrade, a console access to your remote server (via terminal server/KVM/other) is imperative in these cases to avoid the worst. On Mon, 2012-12-31 at 16:50 +0100, Jose Garcia Juanino wrote: El lunes 31 de diciembre a las 16:27:44 CET, ASV escribió: Hi Jose, with the freebsd-update method you don't need to pass through the make installworld as it's a binary patch/upgrade system. Using freebsd-update upgrade -r 9.1-RELEASE for example allows you to get your system patched directly without recompiling the kernel and the userland but getting binary patches from the repo and applying these directly on your system. Check the following page for a more detailed explanation and be aware that upgrading your ports/packages is required every time you upgrade your kernel to a major version (which would be your case). http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html Happy new year. Thanks for your response. The freebsd-update upgrade method is: 1- freebsd-update install # will install a new kernel and modules 2- reboot in multi user 3- freebsd-update install # will install new userland 4- reboot in multi user The src upgrade method is: 1- make installkernel # will install a new kernel 2- reboot in single user 3- make installworld # will install a new userland 4- reboot in multiuser I think that the third step is essentially the same in both methods: it will install a new userland. But the second one require to be ran in single user, and the first one does not. Why? My unique concern is that step 2 in freebsd-update method goes smootly: it will boot kernel in 9.1-RELEASE but userland in 9.0-RELEASE. If the system hangs giving up the net or other essential service, I will not be able to reach the computer via ssh. Regards ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update patches custom /boot/kernel/kernel which it should not
--On January 2, 2013 6:45:50 PM +0100 andreas scherrer ascher...@gmail.com wrote: Hi This can be considered a follow up to the message How to keep freebsd-update from trashing custom kernel? sent to this list by Brett Glass on August 13th 2012 (see [1]). Unfortunately there is no solution to the problem in that thread (or I cannot see it). I am running currently running 9.0-RELEASE-p4 and freebsd-update recommends to update to p5. It states: - The following files will be updated as part of updating to 9.0-RELEASE-p5: /boot/kernel/kernel snip - And from experience this is what it will do: replace /boot/kernel/kernel which is my custom kernel with a GENERIC kernel. As it seems that freebsd-update works by comparing a hash of /boot/kernel/kernel with the GENERIC kernel's hash I checked the md5 and sha1 hash of /boot/kernel/kernel and /boot/GENERIC/kernel. They differ (see [3]). So why is freebsd-update going to overwrite my custom kernel? And how can I prevent it from doing so? Read man (5) freebsd-update.conf. Particularly the COMPONENTS portion that explains how to update world without changing kernel. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. Thomas Jefferson There are some ideas so wrong that only a very intelligent person could believe in them. George Orwell ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Newbie question about freebsd-update: single user mode is not needed anymore?
For some reason my email hasn't apparently been delivered so I'm re-sending it. From: ASV a...@inhio.eu To: Jose Garcia Juanino jjuan...@gmail.com Cc: freebsd-questions@freebsd.org Subject:Re: Newbie question about freebsd-update: single user mode is not needed anymore? Date: Mon, 31 Dec 2012 17:19:19 +0100| Well, I understand your concern. I've been using the freebsd-update method since several years now and mostly remotely. I've never encounter a problem. I haven't recompiled everything many times as I didn't really found a tangible advantage in this method but I've never thought about this. I believe some developer around here can provide you a neat explanation about that (which is going to be interesting to know). Strictly about your concern I believe whatever way you use for your upgrade you CANNOT be 100% sure that your upgrade will go smoothly and things like loosing control of your remote box will not happen. Even though jumping from close releases 9.0 = 9.1 is a low risk upgrade, a console access to your remote server (via terminal server/KVM/other) is imperative in these cases to avoid the worst. On Mon, 2012-12-31 at 16:50 +0100, Jose Garcia Juanino wrote: El lunes 31 de diciembre a las 16:27:44 CET, ASV escribió: Hi Jose, with the freebsd-update method you don't need to pass through the make installworld as it's a binary patch/upgrade system. Using freebsd-update upgrade -r 9.1-RELEASE for example allows you to get your system patched directly without recompiling the kernel and the userland but getting binary patches from the repo and applying these directly on your system. Check the following page for a more detailed explanation and be aware that upgrading your ports/packages is required every time you upgrade your kernel to a major version (which would be your case). http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html Happy new year. Thanks for your response. The freebsd-update upgrade method is: 1- freebsd-update install # will install a new kernel and modules 2- reboot in multi user 3- freebsd-update install # will install new userland 4- reboot in multi user The src upgrade method is: 1- make installkernel # will install a new kernel 2- reboot in single user 3- make installworld # will install a new userland 4- reboot in multiuser I think that the third step is essentially the same in both methods: it will install a new userland. But the second one require to be ran in single user, and the first one does not. Why? My unique concern is that step 2 in freebsd-update method goes smootly: it will boot kernel in 9.1-RELEASE but userland in 9.0-RELEASE. If the system hangs giving up the net or other essential service, I will not be able to reach the computer via ssh. Regards ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Newbie question about freebsd-update: single user mode is not needed anymore?
Hi Jose, with the freebsd-update method you don't need to pass through the make installworld as it's a binary patch/upgrade system. Using freebsd-update upgrade -r 9.1-RELEASE for example allows you to get your system patched directly without recompiling the kernel and the userland but getting binary patches from the repo and applying these directly on your system. Check the following page for a more detailed explanation and be aware that upgrading your ports/packages is required every time you upgrade your kernel to a major version (which would be your case). http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html Happy new year. On Mon, 2012-12-31 at 13:13 +0100, Jose Garcia Juanino wrote: Hi, I am planning to upgrade from FreeBSD 9.0-RELEASE to FreeBSD-9.1-RELEASE. With upgrade source method, it is always needed to do the make installworld step in single user mode. But it seems to be that single user is not required with freebsd-update method, in the second freebsd-update install. Someone could explain the reason? Am I misunderstanding something? Can I run the upgrade enterely by mean a ssh connection in a safe way, or will I need a serial console? Best regards, and excuse my poor english. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update patches custom /boot/kernel/kernel which it should not
The confusion comes from the fact that the original behavior of freebsd-update was NOT to update the kernel binaries if a custom kernel was detected. FYI my /etc/freebsd-update.conf has # Components of the base system which should be kept updated. #Components src world kernel Components src world ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update patches custom /boot/kernel/kernel which it should not
on 2.1.13 19:15 Paul Schmehl said the following: --On January 2, 2013 6:45:50 PM +0100 andreas scherrer And from experience this is what it will do: replace /boot/kernel/kernel which is my custom kernel with a GENERIC kernel. As it seems that freebsd-update works by comparing a hash of /boot/kernel/kernel with the GENERIC kernel's hash I checked the md5 and sha1 hash of /boot/kernel/kernel and /boot/GENERIC/kernel. They differ (see [3]). So why is freebsd-update going to overwrite my custom kernel? And how can I prevent it from doing so? Read man (5) freebsd-update.conf. Particularly the COMPONENTS portion that explains how to update world without changing kernel. Thanks for pointing this out. I might change my freebsd-update.conf to not update the kernel. But still I believe this to be more of a kludge than a solution: in my opinion the handbook suggests that a custom kernel should be detected and left alone. But at the same time a GENERIC kernel in /boot/GENERIC should be patched. http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html - However, freebsd-update will detect and update the GENERIC kernel in /boot/GENERIC (if it exists), even if it is not the current (running) kernel of the system. - Furthermore if I remove the kernel option from the COMPONENTS in freebsd-update.conf I think I will not get the kernel source patches anymore, right? Which in turn means I have to get them via some other mechanism, no? From the same link as above to the handbook: - Unless the default configuration in /etc/freebsd-update.conf has been changed, freebsd-update will install the updated kernel sources along with the rest of the updates. - I think something does not add up here but I can't get my head around it (yet?). ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update patches custom /boot/kernel/kernel which it should not
On Wed, Jan 2, 2013 at 11:18 AM, andreas scherrer ascher...@gmail.comwrote: This is no longer true, though it was true at the time that was written... - However, freebsd-update will detect and update the GENERIC kernel in /boot/GENERIC (if it exists), even if it is not the current (running) kernel of the system. This is no longer true, though it was true at the time - Furthermore if I remove the kernel option from the COMPONENTS in freebsd-update.conf I think I will not get the kernel source patches anymore, right? Which in turn means I have to get them via some other mechanism, no? No. If you have Components src world you'll get all sources - which you want, presumably, since /usr/src/sys changes are sometimes motivated by security vulnerabilities.. - M ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update patches custom /boot/kernel/kernel which it should not
--On January 2, 2013 8:18:38 PM +0100 andreas scherrer ascher...@gmail.com wrote: on 2.1.13 19:15 Paul Schmehl said the following: --On January 2, 2013 6:45:50 PM +0100 andreas scherrer And from experience this is what it will do: replace /boot/kernel/kernel which is my custom kernel with a GENERIC kernel. As it seems that freebsd-update works by comparing a hash of /boot/kernel/kernel with the GENERIC kernel's hash I checked the md5 and sha1 hash of /boot/kernel/kernel and /boot/GENERIC/kernel. They differ (see [3]). So why is freebsd-update going to overwrite my custom kernel? And how can I prevent it from doing so? Read man (5) freebsd-update.conf. Particularly the COMPONENTS portion that explains how to update world without changing kernel. Thanks for pointing this out. I might change my freebsd-update.conf to not update the kernel. But still I believe this to be more of a kludge than a solution: in my opinion the handbook suggests that a custom kernel should be detected and left alone. But at the same time a GENERIC kernel in /boot/GENERIC should be patched. http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html - That needs to be updated. However, freebsd-update will detect and update the GENERIC kernel in /boot/GENERIC (if it exists), even if it is not the current (running) kernel of the system. - Furthermore if I remove the kernel option from the COMPONENTS in freebsd-update.conf I think I will not get the kernel source patches anymore, right? Which in turn means I have to get them via some other mechanism, no? See UpdateIfUnmodified in the man page. You can specify a regex pattern that prevents the kernel from being modified but still downloads the sources. Or you can simply pull source from svn, which I think would be my preferred method. Once you've made the first pull, you can use svn to pull all the kernel updates subsequent to that first pull and then buildkernel as you normally do. From the same link as above to the handbook: - Unless the default configuration in /etc/freebsd-update.conf has been changed, freebsd-update will install the updated kernel sources along with the rest of the updates. - I think something does not add up here but I can't get my head around it (yet?). The Handbook is out of date. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. Thomas Jefferson There are some ideas so wrong that only a very intelligent person could believe in them. George Orwell ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update patches custom /boot/kernel/kernel which it should not
--On January 2, 2013 1:46:25 PM -0600 Paul Schmehl pschmehl_li...@tx.rr.com wrote: --On January 2, 2013 8:18:38 PM +0100 andreas scherrer ascher...@gmail.com wrote: on 2.1.13 19:15 Paul Schmehl said the following: --On January 2, 2013 6:45:50 PM +0100 andreas scherrer And from experience this is what it will do: replace /boot/kernel/kernel which is my custom kernel with a GENERIC kernel. As it seems that freebsd-update works by comparing a hash of /boot/kernel/kernel with the GENERIC kernel's hash I checked the md5 and sha1 hash of /boot/kernel/kernel and /boot/GENERIC/kernel. They differ (see [3]). So why is freebsd-update going to overwrite my custom kernel? And how can I prevent it from doing so? Read man (5) freebsd-update.conf. Particularly the COMPONENTS portion that explains how to update world without changing kernel. Thanks for pointing this out. I might change my freebsd-update.conf to not update the kernel. But still I believe this to be more of a kludge than a solution: in my opinion the handbook suggests that a custom kernel should be detected and left alone. But at the same time a GENERIC kernel in /boot/GENERIC should be patched. http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html - That needs to be updated. However, freebsd-update will detect and update the GENERIC kernel in /boot/GENERIC (if it exists), even if it is not the current (running) kernel of the system. - Furthermore if I remove the kernel option from the COMPONENTS in freebsd-update.conf I think I will not get the kernel source patches anymore, right? Which in turn means I have to get them via some other mechanism, no? See UpdateIfUnmodified in the man page. You can specify a regex pattern that prevents the kernel from being modified but still downloads the sources. I wasn't thinking when I wrote this. Freebsd-update pulls *binary* copies of files, so you're not ever going to get the src files to rebuild your kernel from freebsd-update. You need to pull those in using svn. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead. Thomas Jefferson There are some ideas so wrong that only a very intelligent person could believe in them. George Orwell ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update patches custom /boot/kernel/kernel which it should not
On 02/01/2013 20:55, Paul Schmehl wrote: I wasn't thinking when I wrote this. Freebsd-update pulls *binary* copies of files, so you're not ever going to get the src files to rebuild your kernel from freebsd-update. You need to pull those in using svn. Not so. Take a look at /etc/freebsd-update.conf -- if you have 'src' listed as one of the Components, freebsd-update will keep your /usr/src up to date. Primarily this is intendend for people that want to do binary updates of userland, but compile their own kernels for particular device support or whatever reason. However there's no reason why you couldn't just use freebsd-update just to grab system sources, and them update by building and installing world. If you want to track a release brance, and you don't intend to do any development work on the sources, then freebsd-update is going to be a lot more efficient for you than SVN. Outside that particular audience, however, svn rules. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Upgrading from 9.0-STABLE to 9.1-RELEASE with freebsd-update?
I've used STABLE for years, but with csup going away, I don't want to deal with adding extra packages, and keeping them unbroken, just to stay up date. Running freebsd-update doesn't work for people running STABLE, and I'm not sure freebsd-update will work properly anyway if I compile world for myself. What's the best way to switch from running STABLE to running the RELEASE channel? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
freebsd-update: fale?
Greetings, list. I have the following error; though I can load update5.FreeBSD.org in a browser: root-is-on-fire # freebsd-update fetch 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. Am I missing something in this process? Regards, Joe ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Newbie question about freebsd-update: single user mode is not needed anymore?
Hi, I am planning to upgrade from FreeBSD 9.0-RELEASE to FreeBSD-9.1-RELEASE. With upgrade source method, it is always needed to do the make installworld step in single user mode. But it seems to be that single user is not required with freebsd-update method, in the second freebsd-update install. Someone could explain the reason? Am I misunderstanding something? Can I run the upgrade enterely by mean a ssh connection in a safe way, or will I need a serial console? Best regards, and excuse my poor english. pgpswn9DndVD_.pgp Description: PGP signature
Re: Newbie question about freebsd-update: single user mode is not needed anymore?
El lunes 31 de diciembre a las 16:27:44 CET, ASV escribió: Hi Jose, with the freebsd-update method you don't need to pass through the make installworld as it's a binary patch/upgrade system. Using freebsd-update upgrade -r 9.1-RELEASE for example allows you to get your system patched directly without recompiling the kernel and the userland but getting binary patches from the repo and applying these directly on your system. Check the following page for a more detailed explanation and be aware that upgrading your ports/packages is required every time you upgrade your kernel to a major version (which would be your case). http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html Happy new year. Thanks for your response. The freebsd-update upgrade method is: 1- freebsd-update install # will install a new kernel and modules 2- reboot in multi user 3- freebsd-update install # will install new userland 4- reboot in multi user The src upgrade method is: 1- make installkernel # will install a new kernel 2- reboot in single user 3- make installworld # will install a new userland 4- reboot in multiuser I think that the third step is essentially the same in both methods: it will install a new userland. But the second one require to be ran in single user, and the first one does not. Why? My unique concern is that step 2 in freebsd-update method goes smootly: it will boot kernel in 9.1-RELEASE but userland in 9.0-RELEASE. If the system hangs giving up the net or other essential service, I will not be able to reach the computer via ssh. Regards pgpbaloy3DIlu.pgp Description: PGP signature
Re: freebsd-update - To 'Stable'?
--On 22 November 2012 17:41 +0100 Polytropon free...@edvax.de wrote: I'm looking at switching to 'freebsd-update' - is there an equivalent way to get it to update me to '-STABLE'? No. The freebsd-update program can only be used to follow the RELEASE branch, plus the security updates (RELEASE-pN). Following STABLE branch still requires you to update by source. Ok, as csup is 'deprecated' - I guess what I need to do is move over to Subversion instead? - As 'freebsd-update' is only going to get me release + security (-pX), not 'stable'. At the moment we have a local host that has the entire FreeBSD source tree on it - so we can just 'cherry pick' versions we need to update - I'd guess / hope a similar setup is possible, but with Subversion... -Karl [Off to look for a setup guide ;)] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: freebsd-update - To 'Stable'?
On Sun, 25 Nov 2012 12:06:06 +, Karl Pielorz wrote: --On 22 November 2012 17:41 +0100 Polytropon free...@edvax.de wrote: I'm looking at switching to 'freebsd-update' - is there an equivalent way to get it to update me to '-STABLE'? No. The freebsd-update program can only be used to follow the RELEASE branch, plus the security updates (RELEASE-pN). Following STABLE branch still requires you to update by source. Ok, as csup is 'deprecated' - I guess what I need to do is move over to Subversion instead? Sadly, yes. There still is no csup-equivalent (efficient and fast implementation distributed with the base OS) provided yet. And it's not just about being provided with the OS, but also about nice integration (like /etc/sup/* config files or the option to simply make update). - As 'freebsd-update' is only going to get me release + security (-pX), not 'stable'. Correct. You _can_ use this to compile your own non-GENERIC kernel, but it will always have the pre-STABLE content, just as the rest of /usr/src. At the moment we have a local host that has the entire FreeBSD source tree on it - so we can just 'cherry pick' versions we need to update - I'd guess / hope a similar setup is possible, but with Subversion... It should be possible, as the functionality of CVS and SVN can be seen as quite comparable. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Should newfs include -S 4096? was Re: boot problem after freebsd-update from 9.1-RC2 to 9.1-RC3
On Fri, 23 Nov 2012, free...@johnea.net wrote: One of the complications was getting old metadata off of the drive. After trying a couple of 'dd' invocations: # overwriting the first sector dd if=/dev/zero of=/dev/ada0 bs=512 count=1 # also tried overwriting the last sector diskinfo ada0 | cut -f4 3907029168 (subtract 34, per WB) (I actually just subtracted the trailing 68) dd if=/dev/zero of=/dev/ada0 seek=3907029100 This would still seem to not delete all of the metadata, since after issuing: gmirror label -b split gm0 /dev/ada0 gmirror load # repartition new mirror gpart create -s MBR mirror/gm0 # ignore mirror/gm0s1 added, but partition is not aligned on 4096 bytes after add gpart add -t freebsd -a 4k mirror/gm0 # create the bsdlabel partitions in slice 1 (s1) gpart create -s BSD mirror/gm0s1 I would see that the old gm0s1a and gm0s1b had reappeared, even though I had not yet issued the 'add -t freebsd-ufs'. I'm not sure if they came back with the 'add -t freebsd' or the 'create -s BSD'. Saved this since yesterday, thinking maybe I could come up with an idea, but so far I can't think what would cause that. It might not hurt to force a retaste after the dd. The only thing that seemed to fix it was: gpart destroy -F /dev/ada0 I also tried at one point: gpart destroy -F ada0 gpart create -s gpt ada0 gpart destroy -F ada0 The thing I wonder about now: Should newfs include -S 4096? I used: newfs -U /dev/mirror/gm0s1a Will this lead to 512 byte sector access to the disk through the file system? Will this impact performance or longevity of the mirror? It's a good question; I have not tried it. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Should newfs include -S 4096? was Re: boot problem after freebsd-update from 9.1-RC2 to 9.1-RC3
On 2012-11-20 21:10, Warren Block wrote: On Tue, 20 Nov 2012, free...@johnea.net wrote: On 2012-11-20 14:28, Gary Aitken wrote: On 11/20/12 13:34, free...@johnea.net wrote: freebsd-update upgrade -r 9.1-RC3 ... Not UFS No ada0 No boot Seems like it isn't supposed to work for 9.1-RC2 I previously used binary update to migrate from 9.0 to 9.1, via: freebsd-update upgrade -r 9.1-RC1 freebsd-update install reboot freebsd-update install reboot I'm starting to think having the swap partition in gm0s1a and the booting UFS partition in ada0s1b is the problem: http://forums.freebsd.org/showthread.php?t=31954 The Not UFS error comes immediately on boot. If I boot from rescue media, I can start the gmirror, mount it and chroot into it. The whole install seems fine except for the first stage boot loader finding the UFS partition. A handy bootloader config trick would be greatly appreciated! boot(8) says The automatic boot will attempt to load /boot/loader from partition `a' of either the floppy or the hard disk. You could try setting the correct device path in /boot/boot.config, but I suspect that won't be read until too late. gptboot looks for the first UFS partition. Maybe /boot/boot can be modified to do that also. I ended up booting from rescue media, removing one drive and stopping the gmirror, creating a new gmirror on the removed drive to place the UFS partition first, and performing a dump/restore to transfer the system. Then I was able to boot from the new gmitrror and add the second drive to it. One of the complications was getting old metadata off of the drive. After trying a couple of 'dd' invocations: # overwriting the first sector dd if=/dev/zero of=/dev/ada0 bs=512 count=1 # also tried overwriting the last sector diskinfo ada0 | cut -f4 3907029168 (subtract 34, per WB) (I actually just subtracted the trailing 68) dd if=/dev/zero of=/dev/ada0 seek=3907029100 This would still seem to not delete all of the metadata, since after issuing: gmirror label -b split gm0 /dev/ada0 gmirror load # repartition new mirror gpart create -s MBR mirror/gm0 # ignore mirror/gm0s1 added, but partition is not aligned on 4096 bytes after add gpart add -t freebsd -a 4k mirror/gm0 # create the bsdlabel partitions in slice 1 (s1) gpart create -s BSD mirror/gm0s1 I would see that the old gm0s1a and gm0s1b had reappeared, even though I had not yet issued the 'add -t freebsd-ufs'. I'm not sure if they came back with the 'add -t freebsd' or the 'create -s BSD'. The only thing that seemed to fix it was: gpart destroy -F /dev/ada0 I also tried at one point: gpart destroy -F ada0 gpart create -s gpt ada0 gpart destroy -F ada0 After that I could create the new partitions within the slice, with freebsd-ufs first: # size of ufs partition must be calculated, from 'diskinfo -v /dev/ada0': 2000398934016 # media size in bytes (1.8T) ; 1024*1024*1024 1073741824 ; 2000398934016/1073741824 1863.01668548583984375 # subtract 8G from 1863 = 1855G gpart add -t freebsd-ufs -a 4k -s 1855G mirror/gm0s1 gpart add -t freebsd-swap -a 4k mirror/gm0s1 Everything looks good with 4K alignment, and freebsd-ufs first: gpart show =63 3907029104 mirror/gm0 MBR (1.8T) 63 63 - free - (31k) 126 3907028979 1 freebsd [active] (1.8T) 3907029105 62 - free - (31k) = 0 3907028979 mirror/gm0s1 BSD (1.8T) 0 2- free - (1.0k) 2 3890216960 1 freebsd-ufs (1.8T) 389021696216812016 2 freebsd-swap (8.0G) 3907028978 1- free - (512B) After newfs, I was able to dump/restore to transfer the installed system from ada1 to gm0 (which is 9.1-RC3 now). The thing I wonder about now: Should newfs include -S 4096? I used: newfs -U /dev/mirror/gm0s1a Will this lead to 512 byte sector access to the disk through the file system? Will this impact performance or longevity of the mirror? Thanks again for the sage advice! johnea ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
gpt booting (Was: Re: boot problem after freebsd-update from 9.1-RC2 to 9.1-RC3)
On 11/21/12 05:11, Warren Block wrote: gptboot looks for the first UFS partition. Maybe /boot/boot can be modified to do that also. It's a little more complicated than that Warren. AIUI gptboot first looks (in partition order) for partitions with both the bootme and bootonce attributes set. If it doesn't find any, or if they all failed to boot it then tries booting partitions with just the bootme attribute. It only boots the first UFS partition if no partitions have the bootme attribute set, and IIRC that is for compatibility with the 8.x gptboot which didn't know the boot* attributes. Confusingly, there's no manual page for gptboot to document this. It's sort of implicit in the gpart manual page, in the section on ATTRIBUTES for GPT, but the best way to understand it is to read the code for gptfind in /usr/src/sys/boot/common/gpt.c ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: gpt booting (Was: Re: boot problem after freebsd-update from 9.1-RC2 to 9.1-RC3)
On Wed, 21 Nov 2012, Arthur Chance wrote: On 11/21/12 05:11, Warren Block wrote: gptboot looks for the first UFS partition. Maybe /boot/boot can be modified to do that also. It's a little more complicated than that Warren. AIUI gptboot first looks (in partition order) for partitions with both the bootme and bootonce attributes set. If it doesn't find any, or if they all failed to boot it then tries booting partitions with just the bootme attribute. It only boots the first UFS partition if no partitions have the bootme attribute set, and IIRC that is for compatibility with the 8.x gptboot which didn't know the boot* attributes. Confusingly, there's no manual page for gptboot to document this. It's sort of implicit in the gpart manual page, in the section on ATTRIBUTES for GPT, but the best way to understand it is to read the code for gptfind in /usr/src/sys/boot/common/gpt.c Well, yes. The point is that gptboot doesn't just assume that p2, say, is where the bootable UFS partition must be. I've also noted the lack of a gptboot man page, and it's on my long list of Things That Should Be Done. There was a thread on -doc: http://lists.freebsd.org/pipermail/freebsd-doc/2012-June/020060.html Help would be greatly appreciated. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
boot problem after freebsd-update from 9.1-RC2 to 9.1-RC3
Hello, I recently installed a 9.1-RC2 system using gmirror with MBR, and swap in first bsdlabel. orsbackup# gpart show =63 3907029104 mirror/gm0 MBR (1.8T) 63 63 - free - (31k) 126 3907028979 1 freebsd [active] (1.8T) 3907029105 62 - free - (31k) = 0 3907028979 mirror/gm0s1 BSD (1.8T) 0 2- free - (1.0k) 216777216 1 freebsd-swap (8.0G) 16777218 3890251760 2 freebsd-ufs (1.8T) 3907028978 1- free - (512B) The drive was setup with the following commands: orsbackup# gpart create -s MBR mirror/gm0 mirror/gm0 created orsbackup# gpart add -t freebsd -a 4k mirror/gm0 # ignored mirror/gm0s1 added, but partition is not aligned on 4096 bytes # create the bsdlabel partitions in slice 1 (s1) orsbackup# gpart create -s BSD mirror/gm0s1 orsbackup# gpart add -t freebsd-swap -a 4k -s 8g mirror/gm0s1 orsbackup# gpart add -t freebsd-ufs -a 4k mirror/gm0s1 # put bootcode on the MBR and mark the first slice active orsbackup# gpart bootcode -b /boot/mbr mirror/gm0 orsbackup# gpart set -a active -i 1 mirror/gm0 # put bootcode on the bsdlabel orsbackup# gpart bootcode -b /boot/boot mirror/gm0s1 The system rebooted several times without issue. This system is a testbed for 9.1 and is not yet deployed as a production server. I thought I'd update to 9.1-RC3, so I ran: freebsd-update upgrade -r 9.1-RC3 freebsd-update install reboot The system won't boot and complains about: Not UFS No ada0 No boot Before I charge ahead with reissuing the gpart bootcode commands I thought I'd: a) make others aware there may be issues in freebsd-update with the 9.1 release candidates b) ask about the best way to resolve this bootloader issue. Thanks you for any pointers in resolving this bootloader issue! johnea ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
