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
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
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: 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
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
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: 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
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
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: 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
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: FreeBSD update
2012. október 8. 17:35 napon Andreas Rudisch cyb.@gmx.net Ãrta: On Mon, 08 Oct 2012 16:52:24 +0200 Istvan Gabor suseuse...@lajt.hu wrote: As I remember correctly during the fetch I saw a message that the current patch level is p4. After rebooting the computer uname gives p3 on the updated system: Why does uname reports p3 while freebsd-update indicates p4 state? Hi, if freebsd-update does not update the kernel uname will not show the 'correct' patch level. Andreas Thanks Andreas. FreeBSD Handbook (at the end of section 25.2.2) says: However, freebsd-update will always update the /usr/src/sys/conf/newvers.sh file. The current patch level (as indicated by the -p number reported by uname -r) is obtained from this file. Rebuilding your custom kernel, even if nothing else changed, will allow uname(1) to accurately report the current patch level of the system. From this I conclude that if I rebuild the kernel (the general kernel, not a custom kernel), it should reflect patch level correctly. This raises another question: are the updates made sequentially, as p1, p2, etc.? This would explain why the kernel stayed at p3 level while the system was updated to p4. I Suppose if the update was done in one step after fetching and applying all update patches the kernel should reflect the system's patch level. Is this correct? I am confused a little bit. Istvan ___ 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 Tue, 09 Oct 2012 11:47:02 +0200 Istvan Gabor suseuse...@lajt.hu wrote: FreeBSD Handbook (at the end of section 25.2.2) says: However, freebsd-update will always update the /usr/src/sys/conf/newvers.sh file. The current patch level (as indicated by the -p number reported by uname -r) is obtained from this file. Rebuilding your custom kernel, even if nothing else changed, will allow uname(1) to accurately report the current patch level of the system. From this I conclude that if I rebuild the kernel (the general kernel, not a custom kernel), it should reflect patch level correctly. Yes. This raises another question: are the updates made sequentially, as p1, p2, etc.? This would explain why the kernel stayed at p3 level while the system was updated to p4. Yes. I Suppose if the update was done in one step after fetching and applying all update patches the kernel should reflect the system's patch level. Is this correct? Well, it 'should', but it does not, since freebsd-update does not work that way. p4 did not require rebuilding the kernel, so it had not been done. I am confused a little bit. Feel free to browse the mailing lists, you are not the first one to be confused. Andreas -- GnuPG key : 0x2A573565|http://www.gnupg.org/howtos/de/ Fingerprint: 925D 2089 0BF9 8DE5 9166 33BB F0FD CD37 2A57 3565 ___ 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 Mon, 08 Oct 2012 16:52:24 +0200 Istvan Gabor suseuse...@lajt.hu wrote: As I remember correctly during the fetch I saw a message that the current patch level is p4. After rebooting the computer uname gives p3 on the updated system: Why does uname reports p3 while freebsd-update indicates p4 state? Hi, if freebsd-update does not update the kernel uname will not show the 'correct' patch level. Andreas -- GnuPG key : 0x2A573565|http://www.gnupg.org/howtos/de/ Fingerprint: 925D 2089 0BF9 8DE5 9166 33BB F0FD CD37 2A57 3565 ___ 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 Sun, 26 Aug 2012 14:24:34 -0400, doug wrote: In doing an update from 8.3 -- 9.0 I messed up the merge on /etc/ttys. This has interesting consequences BTW. Are there any docs on how to do this? Here's mine. Note: I changed ttyv8 from off to on as I am using xdm. console noneunknown off secure # ttyv0 /usr/libexec/getty Pc xterm on secure # Virtual terminals ttyv1 /usr/libexec/getty Pc xterm on secure ttyv2 /usr/libexec/getty Pc xterm on secure ttyv3 /usr/libexec/getty Pc xterm on secure ttyv4 /usr/libexec/getty Pc xterm on secure ttyv5 /usr/libexec/getty Pc xterm on secure ttyv6 /usr/libexec/getty Pc xterm on secure ttyv7 /usr/libexec/getty Pc xterm on secure ttyv8 /usr/local/bin/xdm -nodaemon xterm on secure # Serial terminals # The 'dialup' keyword identifies dialin lines to login, fingerd etc. ttyu0 /usr/libexec/getty std.9600 dialup off secure ttyu1 /usr/libexec/getty std.9600 dialup off secure ttyu2 /usr/libexec/getty std.9600 dialup off secure ttyu3 /usr/libexec/getty std.9600 dialup off secure # Dumb console dcons /usr/libexec/getty std.9600 vt100 off secure (END) ___ 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 Sun, 26 Aug 2012, Walter Hurry wrote: On Sun, 26 Aug 2012 14:24:34 -0400, doug wrote: In doing an update from 8.3 -- 9.0 I messed up the merge on /etc/ttys. This has interesting consequences BTW. Are there any docs on how to do this? Here's mine. Note: I changed ttyv8 from off to on as I am using xdm. console noneunknown off secure # ttyv0 /usr/libexec/getty Pc xterm on secure # Virtual terminals ttyv1 /usr/libexec/getty Pc xterm on secure ttyv2 /usr/libexec/getty Pc xterm on secure ttyv3 /usr/libexec/getty Pc xterm on secure ttyv4 /usr/libexec/getty Pc xterm on secure ttyv5 /usr/libexec/getty Pc xterm on secure ttyv6 /usr/libexec/getty Pc xterm on secure ttyv7 /usr/libexec/getty Pc xterm on secure ttyv8 /usr/local/bin/xdm -nodaemon xterm on secure # Serial terminals # The 'dialup' keyword identifies dialin lines to login, fingerd etc. ttyu0 /usr/libexec/getty std.9600 dialup off secure ttyu1 /usr/libexec/getty std.9600 dialup off secure ttyu2 /usr/libexec/getty std.9600 dialup off secure ttyu3 /usr/libexec/getty std.9600 dialup off secure # Dumb console dcons /usr/libexec/getty std.9600 vt100 off secure (END) So with something like: [the beginning of my file] current version PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin HOME=/var/log === PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin 8.0-RELEASE [the rest of my file] just delete the stuff after === ?? ___ 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 question.
On Thu, 23 Aug 2012 11:36:51 -0400 (EDT), d...@safeport.com wrote: I wanted to see if I could get an 8.1 system updated to 9.0 (mostly) with freebsd-update. I did this with a source update to RELENG_8_3 and then did the standard stuff to get to 9.0 perl and xdm both gave errors that libutil.so.9 was missing. scanning google and questions suggested this module was removed. Also in some basic way the ports make scripts view the system as an 8.X system as make index gives 'Generating INDEX-8 - please wait.. Can this be repaired? Building from source is out of the question for this system. After a major version update (8.x - 9.x) you should reinstall _all_ ports. See man portmaster (EXAMPLES section) for suggestions on how to do this. If you want to avoid it. you can install the compat8x port on your system. Unaltered (!) installs from 8.x should continue running. But as soon as you're introducing new software, trouble may occur. In that case, a clean install of your applications should be the better way. (Note that you can do this either by source or by packages, just as you prefer.) The described problem with libutil can be avoided when working with the compat8x port. There are more such ports for older versions that allow running binaries compiled for those OS versions (API/ABI remapping). -- 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 question.
On Thu, 23 Aug 2012, Polytropon wrote: On Thu, 23 Aug 2012 11:36:51 -0400 (EDT), d...@safeport.com wrote: I wanted to see if I could get an 8.1 system updated to 9.0 (mostly) with freebsd-update. I did this with a source update to RELENG_8_3 and then did the standard stuff to get to 9.0 perl and xdm both gave errors that libutil.so.9 was missing. scanning google and questions suggested this module was removed. Also in some basic way the ports make scripts view the system as an 8.X system as make index gives 'Generating INDEX-8 - please wait.. Can this be repaired? Building from source is out of the question for this system. After a major version update (8.x - 9.x) you should reinstall _all_ ports. See man portmaster (EXAMPLES section) for suggestions on how to do this. If you want to avoid it. you can install the compat8x port on your system. Unaltered (!) installs from 8.x should continue running. But as soon as you're introducing new software, trouble may occur. In that case, a clean install of your applications should be the better way. (Note that you can do this either by source or by packages, just as you prefer.) The described problem with libutil can be avoided when working with the compat8x port. There are more such ports for older versions that allow running binaries compiled for those OS versions (API/ABI remapping). After seeing if xorg and twm would just work, I did remove all packages with pkg_delete. That did not clear out all of /usr/local. When pkg_add of perl failed, I just built that. pkg_add of xorg worked. pkg_add of xdm got an error something along the line of unliking lib/X11/auth... so I deleted that dir and did pkg_add again. This installed but xdm fails on execution with libutil.so.9 missing. monhegan:~ uname -a FreeBSD monhegan.boltsys.com 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 01:47:53 UTC 2012 r...@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 But make index thinks (I think) this is an 8.x system. pkg_add did add from ...lastest..9.0 for xorg and xdm. AFAIK there are no 8.x components. ___ 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 question.
On Thu, 23 Aug 2012 13:49:18 -0400 (EDT), d...@safeport.com wrote: After seeing if xorg and twm would just work, I did remove all packages with pkg_delete. That did not clear out all of /usr/local. You can do a manual cleanup of /usr/local, entirely removing it and then reconstructing its structure from the /etc/mtree file. # cd /usr/local # rm -rf * # mtree -f /etc/mtree/BSD.local.dist # mtree -f /etc/mtree/BSD.x11.dist (Not tested, see the manpage for reference.) That should give you a clean environment for a full re-installation. Also note that /var/db/pkg could be manually deleted in this case. When pkg_add of perl failed, I just built that. pkg_add of xorg worked. pkg_add of xdm got an error something along the line of unliking lib/X11/auth... so I deleted that dir and did pkg_add again. This installed but xdm fails on execution with libutil.so.9 missing. Seems that there are complications with leftover stuff in /usr/local. monhegan:~ uname -a FreeBSD monhegan.boltsys.com 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 01:47:53 UTC 2012 r...@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 But make index thinks (I think) this is an 8.x system. pkg_add did add from ...lastest..9.0 for xorg and xdm. AFAIK there are no 8.x components. You could install the ports tree from a 9.0 installation media or simply use CVS to obtain (or at least update) it. -- 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 fetch trying to update custom kernel
On Mon, Aug 20, 2012 at 11:47 AM, Denis piloy...@gmail.com wrote: Hi, I have FreeBSD 9.0 (p4) with custom kernel. uname -i says it: HOMEWIFI90 However, when I run freebsd-update fetch command it would like to update my kernel as well: freebsd-update fetch Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 9.0-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 The following files will be updated as part of updating to 9.0-RELEASE-p4: /boot/kernel/kernel /boot/kernel/kernel.symbols What is wrong with it? If I'm not mistaken, this problem first appeared in 9.0-RELEASE-p2, before this everything worked fine. How can I fix this error? Best regards, Pi ___ 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 Hi Denis, Have you rebuilt your custom kernel after ? This is described in the Handbook in the section 25.2.2 http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html 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 fetch trying to update custom kernel
Hi Alexandre, Have you rebuilt your custom kernel after ? This is described in the Handbook in the section 25.2.2 http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html Yes, I rebuilt my custom kernel after. But this doesn't help - every time I run freebsd-update fetch it suugest me to update kernel and kernel.symbols. Best regards, Denis ___ 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 fetch trying to update custom kernel
On Mon, 20 Aug 2012 14:37:40 +0400, Denis wrote: Hi Alexandre, Have you rebuilt your custom kernel after ? This is described in the Handbook in the section 25.2.2 http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html Yes, I rebuilt my custom kernel after. But this doesn't help - every time I run freebsd-update fetch it suugest me to update kernel and kernel.symbols. Then why not follow my suggestion of _letting_ freebsd-update update the kernel, but _use_ a different one instead which it won't touch? In /boot/loader.conf: kernel=mykernel bootfile=/boot/mykernel/kernel Now freebsd-update can happily alter the default kernel without affecting yours. Note that this implies that _you_ have to take care of kernel changes and recompiling if needed. I know, it's just a workaround and doesn't address the problem directly, but it should get you away from any related trouble. -- 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 fetch trying to update custom kernel
Then why not follow my suggestion of _letting_ freebsd-update update the kernel, but _use_ a different one instead which it won't touch? In /boot/loader.conf: kernel=mykernel bootfile=/boot/mykernel/kernel Now freebsd-update can happily alter the default kernel without affecting yours. Note that this implies that _you_ have to take care of kernel changes and recompiling if needed. I know, it's just a workaround and doesn't address the problem directly, but it should get you away from any related trouble. Yes, I saw your advice, and will follow it. The main idea - may be I missed something and there will be an easy fix to my problem. I want to make sure that the problem exists, and I'm not the only person faced with this error. And also I have a small hope that problem will be fixed by freebsd team :-). Best regards, Denis ___ 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 fetch trying to update custom kernel
== Denis wrote on Mon 20.Aug'12 at 16:41:56 +0400 == Then why not follow my suggestion of _letting_ freebsd-update update the kernel, but _use_ a different one instead which it won't touch? In /boot/loader.conf: kernel=mykernel bootfile=/boot/mykernel/kernel Now freebsd-update can happily alter the default kernel without affecting yours. Note that this implies that _you_ have to take care of kernel changes and recompiling if needed. I know, it's just a workaround and doesn't address the problem directly, but it should get you away from any related trouble. Yes, I saw your advice, and will follow it. The main idea - may be I missed something and there will be an easy fix to my problem. I want to make sure that the problem exists, and I'm not the only person faced with this error. And also I have a small hope that problem will be fixed by freebsd team :-). Best regards, Denis If you're building your own customised kernel, why don't you just build the entire system from source? I've not used freebsd-update yet and probably won't. Is it just a matter of time, i.e. waiting for the compilation to finish? ___ 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 fetch trying to update custom kernel
If you're building your own customised kernel, why don't you just build the entire system from source? I've not used freebsd-update yet and probably won't. Is it just a matter of time, i.e. waiting for the compilation to finish? Actually I built this system from source. And now use freebsd-update just to install security patches (it seems to be easy and faster then to rebuild world). Best regards, Denis ___ 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 csup - I'm going around in circles.
On Fri, 17 Aug 2012 01:48:18 +0200, Polytropon wrote: snip problem and comprehensive answer That's really helpful. Very many thanks, Polytropon. ___ 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 csup - I'm going around in circles.
On Thu, 16 Aug 2012 21:24:37 + (UTC), Walter Hurry wrote: Every time I run freebsd-update fetch it says it wants to update the following 5 source files as part of updating to 9.0-RELEASE-p4: /usr/src/sys/amd64/amd64/trap.c /usr/src/sys/conf/newvers.sh /usr/src/sys/netinet/tcp_input.c /usr/src/sys/netinet6/in6.c /usr/src/sys/netinet6/ip6_input.c So I run freebsd-update install and they are updated happily. But when I run csup with my standard-supfile, it puts the same 5 files back to where they were. Not and. Why are you mixing tools here? You're shooting your own foot. :-) You use _either_ freebsd-update to update your system the binary way, _or_ you use csup to update your sources and then compile your system from that sources. Solution: Don't use csup. :-) Side note: Check your update configuration files so they reflect the proper branch you want to follow. With freebsd-update you follow the -RELEASE-pX branch, with csup you can a) follow -RELEASE-pX b) follow -STABLE c) follow -CURRENT Note that you should not mix those! You can always switch branches when using the source code based method (csup), but you should not do so using freebsd-update. An example configuration to follow -RELEASE-pX using the csup method with make update would look like this: % cat /etc/sup/release.sup *default host=cvsup.freebsd.org *default base=/var/db *default prefix=/usr *default release=cvs tag=RELENG_9_0 *default delete use-rel-suffix *default compress src-all Together with the selection in /etc/make.conf: SUP_UPDATE= YES SUP=/usr/bin/csup SUPFLAGS= -L 2 SUPHOST=cvsup.freebsd.org SUPFILE=/etc/sup/release.sup PORTSSUPFILE= /etc/sup/ports.sup DOCSUPFILE= /etc/sup/doc.sup DOC_LANG= en_US.ISO8859-1 de_DE.ISO8859-1 you can easily control the process. (Sidenote: I also have /etc/sup/stable.sup which looks like the example provided, but has tag=RELENG_9 in it. You could also use tag=RELENG_9_0_0_RELEASE to revert back to 9.0-RELEASE.) You can find an example for what the CVS tags mean here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvs-tags.html -- 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 from recent 8-STABLE to 9.0-RELEASE issues
On Mon, 25 Jun 2012 04:21:18 -0500 Zane C. B-H. wrote: Howdy! Any one have any idea what is going on below? [root@shiela]/root# uname -a FreeBSD shiela.vulpes.vvelox.net 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Sat Feb 25 04:55:35 CST 2012 kits...@shiela.vulpes.vvelox.net:/usr/obj/usr/src/sys/sheila amd64 [root@shiela]/root# freebsd-update -r 9.0-RELEASE upgrade Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching public key from update5.FreeBSD.org... failed. Fetching public key from update4.FreeBSD.org... failed. Fetching public key from update3.FreeBSD.org... failed. No mirrors remaining, giving up. Exit 1 [root@shiela]/root# freebsd-update doesn't support development branches, you have to go from security branch to security branch. ___ 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 from recent 8-STABLE to 9.0-RELEASE issues
On Mon, 25 Jun 2012 12:26:12 +0100 RW rwmailli...@googlemail.com wrote: On Mon, 25 Jun 2012 04:21:18 -0500 Zane C. B-H. wrote: Howdy! Any one have any idea what is going on below? [root@shiela]/root# uname -a FreeBSD shiela.vulpes.vvelox.net 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Sat Feb 25 04:55:35 CST 2012 kits...@shiela.vulpes.vvelox.net:/usr/obj/usr/src/sys/sheila amd64 [root@shiela]/root# freebsd-update -r 9.0-RELEASE upgrade Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching public key from update5.FreeBSD.org... failed. Fetching public key from update4.FreeBSD.org... failed. Fetching public key from update3.FreeBSD.org... failed. No mirrors remaining, giving up. Exit 1 [root@shiela]/root# freebsd-update doesn't support development branches, you have to go from security branch to security branch. I know it can't be used to update to stable, but I've not encountered any thing in the documentation saying it can't be used to update from stable it to a 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 from recent 8-STABLE to 9.0-RELEASE issues
On Mon, 25 Jun 2012 06:53:45 -0500 Zane C. B-H. wrote: On Mon, 25 Jun 2012 12:26:12 +0100 RW rwmailli...@googlemail.com wrote: freebsd-update doesn't support development branches, you have to go from security branch to security branch. I know it can't be used to update to stable, but I've not encountered any thing in the documentation saying it can't be used to update from stable it to a release. From the man page: ... the FreeBSD Security Team only builds updates for releases shipped in binary form by the FreeBSD Release Engineering Team ___ 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 from recent 8-STABLE to 9.0-RELEASE issues
On Mon, 25 Jun 2012 14:12:36 +0100 RW rwmailli...@googlemail.com wrote: On Mon, 25 Jun 2012 06:53:45 -0500 Zane C. B-H. wrote: On Mon, 25 Jun 2012 12:26:12 +0100 RW rwmailli...@googlemail.com wrote: freebsd-update doesn't support development branches, you have to go from security branch to security branch. I know it can't be used to update to stable, but I've not encountered any thing in the documentation saying it can't be used to update from stable it to a release. From the man page: ... the FreeBSD Security Team only builds updates for releases shipped in binary form by the FreeBSD Release Engineering Team Right, that is exactly what I was referring to. 9.0-RELEASE is one of those as far as I know. It is ambiguous as to if that means being upgraded from or to and the error message given does not indicate what is being upgraded from is not supported, so I am a bit confused on if this is to be expected or not. ___ 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 install question
Dale Scott skrev 2012-06-14 14:59: Should I install the libc souces? I had this error when upgrading 8.x (8.1 to 8.2?), and solved it by creating the directory only (actual sources not required). I recall someone had posted this solution to the list at the time. Regards, Dale ___ 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 I followed your suggestion and created the directory. I then installed the latest update with freebsd-update and it went well without any warnings. Thanks for the advice :-) /Leslie ___ 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 procedure, question
On 14/06/2012 10:41, Leslie Jensen wrote: When one recives the FreeBSD Errata Notice or FreeBSD Security Advisory The instruction is to do: # freebsd-update fetch # freebsd-update install From earlier discussions on this list about the -px number not changing, I usually rebuild and install the kernel. My question is: Do I need to reboot after # freebsd-update install or can I rebuild and install the kernel before the reboot? freebsd-update will fetch any updates to /usr/src, so any time after you've done 'freebsd-update install' you can build and install a new kernel with all the security patches applied. Given that you are only applying security updates within one release branch and you are using a kernel configuration that has been well tested, you should be fine to just install the new kernel before rebooting at the end of your update procedure. However, if you're going to be doing anything more ambitious (switching RELEASE version, modifying the kernel config non-trivially), then you should adopt a more cautious approach. You need to make sure you've got a world+kernel combination that still works after freebsd-update has applied all its changes to the system before you try booting to your customised kernel. In the case of major version upgrades, use the default kernels that freebsd-update supplies during the actual upgrade so you can be assured that you have a working combination (working in the sense that you can log in and build/install a new kernel; if you need a custom kernel to support some odd bits of hardware then those temporarily won't work). Once you've got the system up and running after updating, then go ahead and build and install your new kernel. Should it fail to boot properly, you will be able to back-out to the previous known-working kernel. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: freebsd-update install question
On 14/06/2012 10:45, Leslie Jensen wrote: When I do freebsd-update install I get this error: Installing updates...install: ///usr/src/lib/libc/gen/libc_dlopen.c: No such file or directory I think it's because I do not have all sources installed. So I just want to confirm that it's the case. If you're using freebsd-update then you don't need the libc sources. Does no harm to have them around. Given you're using a custom kernel then you definitely do need the kernel sources: that's everything under /usr/src/sys plus a few other bits and pieces. Also, should I care and install the source needed? The default setting for freebsd-update is to install the system sources. If you haven't changed /etc/freebsd-update.conf then something odd is happening. Perhaps you manually deleted the contents of /usr/src ? If you definitely don't want the system sources, then edit /etc/freebsd-update.conf and change this section in the obvious way: # Components of the base system which should be kept updated. Components src world kernel # Example for updating the userland and the kernel source code only: # Components src/base src/sys world ie. comment out the first 'Components' line and uncomment the second. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: freebsd-update install question
2012-06-14 12:18, Matthew Seaman skrev: On 14/06/2012 10:45, Leslie Jensen wrote: When I do freebsd-update install I get this error: Installing updates...install: ///usr/src/lib/libc/gen/libc_dlopen.c: No such file or directory I think it's because I do not have all sources installed. So I just want to confirm that it's the case. If you're using freebsd-update then you don't need the libc sources. Does no harm to have them around. Given you're using a custom kernel then you definitely do need the kernel sources: that's everything under /usr/src/sys plus a few other bits and pieces. Also, should I care and install the source needed? The default setting for freebsd-update is to install the system sources. If you haven't changed /etc/freebsd-update.conf then something odd is happening. Perhaps you manually deleted the contents of /usr/src ? If you definitely don't want the system sources, then edit /etc/freebsd-update.conf and change this section in the obvious way: # Components of the base system which should be kept updated. Components src world kernel # Example for updating the userland and the kernel source code only: # Components src/base src/sys world ie. comment out the first 'Components' line and uncomment the second. Cheers, Matthew I use the default kernel, on changes whatsoever. I haven't changed anything. I installed the sources because it was needed for VirtualBox, I think. I didn't install all sources only what was needed. I've not touched /etc/frebsd-update.conf at all. Should I install the libc souces? thanks /Leslie ___ 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 install question
Should I install the libc souces? I had this error when upgrading 8.x (8.1 to 8.2?), and solved it by creating the directory only (actual sources not required). I recall someone had posted this solution to the list at the time. Regards, Dale ___ 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 Not Recognizing Updated Custom Kernel for 9.0-RELEASE-p3
Resend as I lost cc questions@ by mistake Ryan Frederick wrote: I have several FreeBSD 9 systems with custom compiled kernels. After using freebsd-update to go from 9.0-RELEASE-p2 to 9.0-RELEASE-p3 this morning I rebuilt the kernels. However after recompiling, installing, and rebooting with the custom kernels subsequent update checks using freebsd-update cron or freebsd-update fetch indicate that /boot/kernel/kernel (and only /boot/kernel/kernel) needs to be updated despite the custom kernel indicating 9.0-RELEASE-p3 in the output of uname -a. Maybe freebsd-update is taking cognisance of recent posts to security-advisor...@freebsd.org Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below not above, cumulative like a play script, indent with . Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. Mail from @yahoo dumped @berklix. http://berklix.org/yahoo/ ___ 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 Not Recognizing Updated Custom Kernel for 9.0-RELEASE-p3
I realized I made a couple of wording/clarification errors in my original message. First just about all of these kernels are not custom but simply locally compiled with no custom modifications. Second the locally compiled kernels are all named GENERIC (no custom name). Ryan On 6/12/12 2:29 PM, Ryan Frederick wrote: I have several FreeBSD 9 systems with custom compiled kernels. After using freebsd-update to go from 9.0-RELEASE-p2 to 9.0-RELEASE-p3 this morning I rebuilt the kernels. However after recompiling, installing, and rebooting with the custom kernels subsequent update checks using freebsd-update cron or freebsd-update fetch indicate that /boot/kernel/kernel (and only /boot/kernel/kernel) needs to be updated despite the custom kernel indicating 9.0-RELEASE-p3 in the output of uname -a. Ryan ___ 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 no mirrors?
On Sun, 03 Jun 2012 12:47:47 +0100 Chris Whitehouse wrote: c400# uname -a FreeBSD c400 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC 2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Following the handbook: c400# freebsd-update -r 9-STABLE upgrade ... Am I doing something wrong? freebsd-update only works on release security branches - not development branches. ___ 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 no mirrors?
On 03/06/2012 13:00, RW wrote: On Sun, 03 Jun 2012 12:47:47 +0100 Chris Whitehouse wrote: c400# uname -a FreeBSD c400 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:15:25 UTC 2012 r...@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 Following the handbook: c400# freebsd-update -r 9-STABLE upgrade ... Am I doing something wrong? freebsd-update only works on release security branches - not development branches. Ah my mistake, thanks. It's a rather old slow laptop and I don't want to stress it by building world/kernel, I guess that means it stays on RELEASE. thanks Chris ___ 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 not updating reported patchlevel
On 03/05/2012 23:43, Robert Bonomi wrote: Amazingly, this very question was covered on this list within the last few hours. grin It's not that much of a coincidence. We always get a rash of queries like this every time there's a security advisory and consequently a lot of people are updating. Executive summary: the kernel ID string that uname reports changes only when the -kernel- is changed. -p4, -p5, -p6, and -p7. have -not- involved any changes to the kernel. hence the ID string has stayed at '-p3'. While this _is_ counter-intuitive, it does make sense to avoid pushing a new k ernel out, and/or forcing an admin to rebuild a custom kernel, when the -only- change would be to the ID string. I wonder if it would be possible or indeed worthwhile to have a very small kld or sysctl that shows the current patch level and that can be updated without replacing the kernel entire. Obviously, this introduces the possibility of faking the patchlevel, so perhaps this should be constructed so it can only be modified on reboot. H Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: freebsd-update not updating reported patchlevel
On 03/05/2012 22:52, Mike Brown wrote: For example, with this latest OpenSSL security update, running 'freebsd-update fetch' says (among other things) The following files will be updated as part of updating to 8.2-RELEASE-p7 and WARNING: FreeBSD 8.2-RELEASE-p3 is approaching its End-of-Life date. It is strongly recommended that you upgrade to a newer release within the next 2 months. Aside from the question of the version string embedded in the kernel not being updated which has been addressed elsewhere, this warning seems a bit unclear. It's actually the entire 8.2-RELEASE branch that is approaching EoL, not any specific patchlevel within it. (Individual patchlevels don't have an EoL concept per se: they just last until the next one comes out, or the whole branch goes out of support.) In other words, this message is warning you to update to 8.3-RELEASE or 9.0-RELEASE in the near future. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: freebsd-update not updating reported patchlevel
From owner-freebsd-questi...@freebsd.org Fri May 4 02:54:56 2012
Date: Fri, 04 May 2012 08:52:24 +0100
From: Matthew Seaman m.sea...@infracaninophile.co.uk
To: freebsd-questions@freebsd.org
Subject: Re: freebsd-update not updating reported patchlevel
On 03/05/2012 23:43, Robert Bonomi wrote:
Amazingly, this very question was covered on this list within the last few
hours. grin
It's not that much of a coincidence. ...
No kidding. wry grin
The 'amazingly' was a wry commentary on that very fact.
I wonder if it would be possible or indeed worthwhile to have a very
small kld or sysctl that shows the current patch level and that can be
updated without replacing the kernel entire. Obviously, this introduces
the possibility of faking the patchlevel, so perhaps this should be
constructed so it can only be modified on reboot.
What is required is a differentation between the _kernel_ revision level,
and the patchlevel of the entire base system.
Store the kernel revision level -in- the kernel. Use the 'standard'
THREE-level version numbering {Major}.{Minor}.{revision} for the kernel.
Bump 'revision' for each set fo kernel patches.
The patchlevel info for the base system can be a simple data file.
I'd suggest a dotfile' in /etc, mode 644, with the followig flags
set: 'system append only', 'system undlink'.
Bump 'patchlevel' every time -anything- in the base system changes,
regardless of whether it is part of the kernel or the 'world'.
Both kernel revision level and 'world' patchlevel are reset -only-
when a new minor (or major) release of the O/S is installed. Aside
from that, they increment semi-independantly -- 'world' patchlevel
is always greater-equal to kernel revision level.
Ideally, this is a _log_ of all the actual changes, something along the
lines of:
BEGIN updates
updated {foo}, Vers x.y.z, old file renamed to {foo}.x.y.x-replaced
patchfile {foo1} for {pathname}, patch application succeeded
patchfile {foo2} for {pathname}, patch application FAILED
obselete file {foo3} renamed to {foo3}.x.y.z-obselete
END updates Now at patchlevel {quux}
For 'audit' purposes', every line is prefixed with
timestamp,
login username/effective UID(as a username)
the tty device from which the action was performed.
When a new release of the O/S is installed, the patchlog file is renamed
or deleted, and a single line of the form:
END install Now at patchlevel 0
is written. Thus there is always an END line with the patchlevel ID.
The numeric patchlevel is written as a fixed-width *right-justiied* field.
Thus, the last 'END' starts at a 'known' position before the end of the
file, allowing an application to do a direct fseek(3)/lseek(2) to it (or
the patchlevel) without having to read the entire file. ('install' and
'updates' are chosen with malice aforethought, they're the same length ;)
From the command-line, 'tail -1 {patchlog}' gets everything.
With this kind of setup, and assuming that all distributed patchfiles have
'unique' names, the 'patchlog' provides a roadmap for reconstructing the
state of the kernel and 'world' as of any particular point in time.
AT LEAST as important, it provides a record that would let one 'back out'
an update, to revert to a prior system state, if needed. In fact, it
would be 'easy' to have automation perform that task.
___
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 not updating reported patchlevel
On Fri, 4 May 2012 04:14:05 -0500 (CDT), Robert Bonomi wrote:
What is required is a differentation between the _kernel_ revision level,
and the patchlevel of the entire base system.
Store the kernel revision level -in- the kernel. Use the 'standard'
THREE-level version numbering {Major}.{Minor}.{revision} for the kernel.
Bump 'revision' for each set fo kernel patches.
The patchlevel info for the base system can be a simple data file.
I'd suggest a dotfile' in /etc, mode 644, with the followig flags
set: 'system append only', 'system undlink'.
Bump 'patchlevel' every time -anything- in the base system changes,
regardless of whether it is part of the kernel or the 'world'.
Interesting approach. Both files could also be header files
in /usr/include to store this information per #define. But
in fact, I like the /etc idea better.
Allow me to extent the approach: For -STABLE versions (e. g. if
updated per CVS), those files could contain the build number
and the date of the currently installed -STABLE snapshot.
A separation of a kernel version file and a world version
file is useful in cases the kernel won't be touched, so no
need to update its version file (as well as the kernel itself)
by a binary update.
The files should be easily parsable. They could even contain
an assignment in sh syntax, as well as comments (for BSDL and
$FreeBSD$ information). Their templates could be stored in
the /usr/src subtree for the etc/ structure, so programs like
make and mergemaster could access them from there.
Maybe a binary command could be added to the base system to
query this information (maybe getent could do that?).
Here are some suggestions:
/etc/kernversion
VERSION=8.2
BRANCH=STABLE
BUILD=12345
DATE=2011-08-01 12:34:56
or
/etc/kernversion
VERSION=8.4
BRANCH=RELEASE
PATCH=2
DATE=2012-02-02 02:02:02
/etc/sysversion
VERSION=8.4
BRANCH=RELEASE
PATCH=4
DATE=2012-04-04 04:04:04
This shows: Kernel has last been updated to patchlevel 2 (to
check with uname -r will show that version), but the system
has been updated two more times to patchlevel 4.
The notation could be X.Y-pZ or X.Y.Z for -RELEASE installations,
and X.Y-B for -STABLE installations. However, it's not hard to
write any custom parser and composer if urgently needed.
Maybe things also present in uname -a output (such as architecture
and OS name) could be included, but I think that's not required
because it's mostly obvious. :-)
Both kernel revision level and 'world' patchlevel are reset -only-
when a new minor (or major) release of the O/S is installed. Aside
from that, they increment semi-independantly -- 'world' patchlevel
is always greater-equal to kernel revision level.
Ideally, this is a _log_ of all the actual changes, something along the
lines of:
BEGIN updates
updated {foo}, Vers x.y.z, old file renamed to {foo}.x.y.x-replaced
patchfile {foo1} for {pathname}, patch application succeeded
patchfile {foo2} for {pathname}, patch application FAILED
obselete file {foo3} renamed to {foo3}.x.y.z-obselete
END updates Now at patchlevel {quux}
For 'audit' purposes', every line is prefixed with
timestamp,
login username/effective UID(as a username)
the tty device from which the action was performed.
When a new release of the O/S is installed, the patchlog file is renamed
or deleted, and a single line of the form:
END install Now at patchlevel 0
is written. Thus there is always an END line with the patchlevel ID.
The numeric patchlevel is written as a fixed-width *right-justiied* field.
Thus, the last 'END' starts at a 'known' position before the end of the
file, allowing an application to do a direct fseek(3)/lseek(2) to it (or
the patchlevel) without having to read the entire file. ('install' and
'updates' are chosen with malice aforethought, they're the same length ;)
From the command-line, 'tail -1 {patchlog}' gets everything.
Also very nice. By simply _viewing_ the file, the most non-current
version will be discovered, so maybe (just _maybe_) re-ordering them
in upside-down (newest version on top) would be better? Of course,
this would not go well with the log idea. Files like UPDATING
in the /usr/ports and /usr/src tree use such an approach.
Such a log file would not feel comfortable in /etc, it should
rather go to /var or even /var/log. :-)
With this kind of setup, and assuming that all distributed patchfiles have
'unique' names, the 'patchlog' provides a roadmap for reconstructing the
state of the kernel and 'world' as of any particular point in time.
AT LEAST as important, it provides a record that would let one 'back out'
an update, to revert to a prior system state, if needed. In fact, it
would be 'easy' to have automation perform that task.
How about performing version skips, e. g. from -p1 to -p4
directly (using
Re: freebsd-update not updating reported patchlevel
Polytropon free...@edvax.de wrote:
On Fri, 4 May 2012 04:14:05 -0500 (CDT), Robert Bonomi wrote:
What is required is a differentation between the _kernel_ revision level,
and the patchlevel of the entire base system.
Store the kernel revision level -in- the kernel. Use the 'standard'
THREE-level version numbering {Major}.{Minor}.{revision} for the kernel.
Bump 'revision' for each set fo kernel patches.
The patchlevel info for the base system can be a simple data file.
I'd suggest a dotfile' in /etc, mode 644, with the followig flags
set: 'system append only', 'system undlink'.
Bump 'patchlevel' every time -anything- in the base system changes,
regardless of whether it is part of the kernel or the 'world'.
Interesting approach. Both files could also be header files
in /usr/include to store this information per #define. But
in fact, I like the /etc idea better.
The 'state of the kernel' _belongs_ in /usr/src/sys, or similar. to be
included in kernal builds, and where the *handful* of utilities -- e.g.
lsof -- that are intimately coupled to the exact O/S version are already
picking up 'system specific' gory details.
/usr/include is definitely a 'wrong place'. Arguably, so is /etc.
From the standpoint of 'a single place' for critical data, anything other
than a kernel build should use what is in the 'uname' output. (See the
notes on O'Brien, below.)
_Very_few_ applications are concerned with the patchlevel of 'world'.
rebuilding everything that #included a 'world patchlevel' file, when
the only thing that changed was the patchlevel, is just plain silly.
Allow me to extent the approach: For -STABLE versions (e. g. if
updated per CVS), those files could contain the build number
and the date of the currently installed -STABLE snapshot.
Changes for 'other than that application' are -irrelevant- to any
particular application.
*PROPERLY* USED, CVS keywords provide automatic inclusion of this
information -- for _every_ source module (.c or .h, and equivalents for
other languages) in every executable build.
For example, put the following lines in the start of every source module
(before any '#include' lines);
static char *_id =
@(#) $Id:$ \0\0
@(#) Version: $Revision:$ Edited: $Date:$ \0\0
@(#) Build:__DATE__ __TIME__ ;
and similar lines in each #include (excluding the 'build' info),
with the variable name being made 'unique' by appendinng the file name,
and bracketed in #ifndef/#endif to ensure only a single inclusion in a
given mudule.
Recognizing that '@(#)' is a 'magic sequence' used by SCCS, and utilized
by what(1). if 'what' is not available, it can be simulated by;
strings {foo} | awk '/^@(#) / { $1=; print; }'
Add a similarly-constructed '_id_header' in the 'main' module, (making sure
that 'main' is named first on the linker line) which provides a label, the
'published' Major/minor/revision number and a 'counter' of the number of
builds (doe with a one-liner addition in the makefile target that builds the
executable, and you get results like THIS:
% what milter_daemon
milter_daemon:
version-control
Version: 1.1.0(368)
milter_daemon.c,v 1.34 2010/11/04 23:54:02 bonomi Exp
Version: 1.34 Edited: 2010/11/04 23:54:02
Build: Dec 20 2010 02:49:47
testharness.h,v 1.5 2010/11/04 23:53:37 bonomi Exp
Version: 1.5 Edited: 2010/11/04 23:53:37
milter_includes.h,v 1.5 2010/11/04 23:53:37 bonomi Exp
Version: 1.5 Edited: 2010/11/04 23:53:37
pass_dict.h,v 1.4 2010/11/04 23:53:37 bonomi Exp
Version: 1.4 Edited: 2010/11/04 23:53:37
headers.h,v 1.4 2010/10/02 00:12:56 bonomi Exp
Version: 1.4 Edited: 2010/10/02 00:12:56
mime_subs.h,v 1.4 2010/11/04 23:53:37 bonomi Exp
Version: 1.4 Edited: 2010/11/04 23:53:37
milter_config_file.h,v 1.25 2010/11/27 21:43:02 bonomi Exp
Version: 1.25 Edited: 2010/11/27 21:43:02
postfixer.h,v 1.8 2010/11/04 23:53:37 bonomi Exp
Version: 1.8 Edited: 2010/11/04 23:53:37
mlfi_priv.h,v 1.9 2010/10/05 16:18:15 bonomi Exp
Version: 1.9 Edited: 2010/10/05 16:18:15
checklists.h,v 1.3 2010/09/16 18:27:51 bonomi Exp
Version: 1.3 Edited: 2010/09/16 18:27:51
per_user_config.h,v 1.2 2010/10/25 22:45:37 bonomi Exp
Version: 1.2 Edited: 2010/10/25 22:45:37
pass_dictionary.c,v 1.5 2010/11/04 23:54:02 bonomi Exp
Version: 1.5 Edited: 2010/11/04 23:54:02
Build: Dec 20 2010 02:49:49
headers.c,v 1.4 2010/10/02 00:12:56 bonomi Exp
Version: 1.4 Edited:
Re: freebsd-update not updating reported patchlevel
On 2012-05-04 10:45, Polytropon wrote: Allow me to extent the approach: For -STABLE versions (e. g. if updated per CVS), those files could contain the build number and the date of the currently installed -STABLE snapshot. A separation of a kernel version file and a world version file is useful in cases the kernel won't be touched, so no need to update its version file (as well as the kernel itself) by a binary update. The files should be easily parsable. They could even contain an assignment in sh syntax, as well as comments (for BSDL and $FreeBSD$ information). Their templates could be stored in the /usr/src subtree for the etc/ structure, so programs like make and mergemaster could access them from there. Maybe a binary command could be added to the base system to query this information (maybe getent could do that?). Here are some suggestions: /etc/kernversion VERSION=8.2 BRANCH=STABLE BUILD=12345 DATE=2011-08-01 12:34:56 or /etc/kernversion VERSION=8.4 BRANCH=RELEASE PATCH=2 DATE=2012-02-02 02:02:02 /etc/sysversion VERSION=8.4 BRANCH=RELEASE PATCH=4 DATE=2012-04-04 04:04:04 This shows: Kernel has last been updated to patchlevel 2 (to check with uname -r will show that version), but the system has been updated two more times to patchlevel 4. The notation could be X.Y-pZ or X.Y.Z for -RELEASE installations, and X.Y-B for -STABLE installations. However, it's not hard to write any custom parser and composer if urgently needed. Maybe things also present in uname -a output (such as architecture and OS name) could be included, but I think that's not required because it's mostly obvious. :-) I think you could still get a machine-parseable version on one line, that's also a bit nicer for human reading. Perhaps something like this? (Partly inspired by RedHat's /etc/redhat-release) /etc/sysversion FreeBSD RELEASE 8.4-p4: 2012-04-04 04:04:04 You should be able to parse that with a few lines of C or shell, and it looks like something set up to be read by humans. You just need to define - and stick to - which pieces of information will be in there in what order. (For instance, I'd prefer '9.0-p0' to '9.0' Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --- ___ 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 not updating reported patchlevel
First of all, thanks for explaining your point of view.
Allow me to add a few thoughts:
On Fri, 4 May 2012 11:44:49 -0500 (CDT), Robert Bonomi wrote:
Polytropon free...@edvax.de wrote:
On Fri, 4 May 2012 04:14:05 -0500 (CDT), Robert Bonomi wrote:
What is required is a differentation between the _kernel_ revision level,
and the patchlevel of the entire base system.
Store the kernel revision level -in- the kernel. Use the 'standard'
THREE-level version numbering {Major}.{Minor}.{revision} for the kernel.
Bump 'revision' for each set fo kernel patches.
The patchlevel info for the base system can be a simple data file.
I'd suggest a dotfile' in /etc, mode 644, with the followig flags
set: 'system append only', 'system undlink'.
Bump 'patchlevel' every time -anything- in the base system changes,
regardless of whether it is part of the kernel or the 'world'.
Interesting approach. Both files could also be header files
in /usr/include to store this information per #define. But
in fact, I like the /etc idea better.
The 'state of the kernel' _belongs_ in /usr/src/sys, or similar. to be
included in kernal builds, and where the *handful* of utilities -- e.g.
lsof -- that are intimately coupled to the exact O/S version are already
picking up 'system specific' gory details.
Correct. I appreciate the idea of having _one_ centralized
point for that information that is authoritative regarding
all queries. Like uname displays several aspects of the
kernel's data, it is limited in some regards:
For example, if you have updated the system the binary
way to -p3 which included a kernel change, uname will
report that -p3 properly. If you follow -STABLE, you
don't get the information of what build you currently
have, so you cannot put it into relation after what
-plevel we currently are.
% uname -r
8.2-STABLE
I know there is some file in /usr/src where the build
number can be obtained from (I think it's a #define),
but it's not included in the kernel queryable data.
/usr/include is definitely a 'wrong place'. Arguably, so is /etc.
From the standpoint of 'a single place' for critical data, anything other
than a kernel build should use what is in the 'uname' output. (See the
notes on O'Brien, below.)
_Very_few_ applications are concerned with the patchlevel of 'world'.
rebuilding everything that #included a 'world patchlevel' file, when
the only thing that changed was the patchlevel, is just plain silly.
Oh, I didn't think about recompiling any stuff against
such a header file. I did primarily assume it as a kind
of purely informative source, which could also be provided
by a plain text file.
*PROPERLY* USED, CVS keywords provide automatic inclusion of this
information -- for _every_ source module (.c or .h, and equivalents for
other languages) in every executable build.
Correct, but obtaining such data is often not possible by the
application itself (except it has an extended version option
or it includes that info in a help screen).
For the kernel, uname prints various information (which are
obtained from the kernel directly, which is good), but what
program can do the same for the system?
See above.
Done 'right', this stuff is already all there, with _existing- tools.
Not fully, if I see it correctly. E. g., what build number
has a particular -STABLE installation? Or, if kernel and world
are able to be updated independently - no kernel change, but a
program change from -plevel to -plevel+1 will leave the
kernel's uname -r at -plevel, so how to tell easily that
the world is at -plevel+1?
Also very nice. By simply _viewing_ the file, the most non-current
version will be discovered, so maybe (just _maybe_) re-ordering them
in upside-down (newest version on top) would be better?
Definitely -not-. grin
You obviously didn't notice that the file flags are 'sysem append only'.
Oh, I noticed that, and I know appending on top is always
more complicated than appending (in the precise sense of what
to append means). :-)
The entire point of my proposal is to make it an IMMUTATABLE RECORD of
'what was done'. 'add to top' has several disadvantages. First,
a performance issue, you do have to read down the log to find the
first 'END' line rather than being able to seek directly to it.
Second, and the *BIG* one, you risk destroying the prior information
by re-writing the file. Third, it makes it easier for a 'malicious'
update to cover it's tracks.
Additionally, _undoing_ operations would also be logged - not
by omitting lines, but by a proper record that states how things
have been reverted to a previous level, which is also very good
for diagnostics.
Until you learn to think like O'Brien, staying ahead of him requires a
-lot- of forethought.
Oh, I often think like O'Brien, and I don't remember, especially
when I'm talking to 6079 Smith W., machen Sie die Augen auf! :-)
On topic again:
Re: freebsd-update not updating reported patchlevel
On 4 May 2012, at 16:45, Polytropon free...@edvax.de wrote:
On Fri, 4 May 2012 04:14:05 -0500 (CDT), Robert Bonomi wrote:
What is required is a differentation between the _kernel_ revision level,
and the patchlevel of the entire base system.
Store the kernel revision level -in- the kernel. Use the 'standard'
THREE-level version numbering {Major}.{Minor}.{revision} for the kernel.
Bump 'revision' for each set fo kernel patches.
The patchlevel info for the base system can be a simple data file.
I'd suggest a dotfile' in /etc, mode 644, with the followig flags
set: 'system append only', 'system undlink'.
Bump 'patchlevel' every time -anything- in the base system changes,
regardless of whether it is part of the kernel or the 'world'.
Interesting approach. Both files could also be header files
in /usr/include to store this information per #define. But
in fact, I like the /etc idea better.
Allow me to extent the approach: For -STABLE versions (e. g. if
updated per CVS), those files could contain the build number
and the date of the currently installed -STABLE snapshot.
I have massive love for this idea, having to check the kern build date to have
a rough idea of what 8-STABLE I'm running is too prone to errors.
___
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 not updating reported patchlevel
On Fri, 4 May 2012 16:45:51 -0500 (CDT), Robert Bonomi wrote:
Polytropon free...@edvax.de wrote:
First of all, thanks for explaining your point of view.
Allow me to add a few thoughts:
On Fri, 4 May 2012 11:44:49 -0500 (CDT), Robert Bonomi wrote:
Polytropon free...@edvax.de wrote:
On Fri, 4 May 2012 04:14:05 -0500 (CDT), Robert Bonomi wrote:
What is required is a differentation between the _kernel_ revision
level,
and the patchlevel of the entire base system.
Store the kernel revision level -in- the kernel. Use the 'standard'
THREE-level version numbering {Major}.{Minor}.{revision} for the
kernel.
Bump 'revision' for each set fo kernel patches.
The patchlevel info for the base system can be a simple data file.
I'd suggest a dotfile' in /etc, mode 644, with the followig flags
set: 'system append only', 'system undlink'.
Bump 'patchlevel' every time -anything- in the base system changes,
regardless of whether it is part of the kernel or the 'world'.
Interesting approach. Both files could also be header files
in /usr/include to store this information per #define. But
in fact, I like the /etc idea better.
The 'state of the kernel' _belongs_ in /usr/src/sys, or similar. to be
included in kernal builds, and where the *handful* of utilities -- e.g.
lsof -- that are intimately coupled to the exact O/S version are already
picking up 'system specific' gory details.
Correct. I appreciate the idea of having _one_ centralized
point for that information that is authoritative regarding
all queries. Like uname displays several aspects of the
kernel's data, it is limited in some regards:
For example, if you have updated the system the binary
way to -p3 which included a kernel change, uname will
report that -p3 properly. If you follow -STABLE, you
don't get the information of what build you currently
have, so you cannot put it into relation after what
-plevel we currently are.
% uname -r
8.2-STABLE
uname -v, maybe ??
Like uname -a (maximum output), only the date of the kernel
build is present. I'd like to know that strange number and
how it relates (pre-/postdates) -plevel patch levels.
If you're talking about trying to associate a particular patch/revison
level of a particular program with a partiular 'world' patchlevel. That
is a very different problem, and requires a separate separate solution,
something like a 'correlation' database.
Yes, that was my primary intention.
For the kernel, uname prints various information (which are
obtained from the kernel directly, which is good), but what
program can do the same for the system?
For kernel info, any program that can 'popen' for write uname -a. *grin*
For the patchlevel of the 'world', TTBOMK it isn't recorded anywhere
conveniently accessible.
I know that this build number is stored somewhere (I found it
once!), I think it was a header file. Sure, you can grep for it,
but it would be easier to make this information better accessible
(and maybe even to put it into relation to a patch level number).
Not fully, if I see it correctly. E. g., what build number
has a particular -STABLE installation? Or, if kernel and world
are able to be updated independently - no kernel change, but a
program change from -plevel to -plevel+1 will leave the
kernel's uname -r at -plevel, so how to tell easily that
the world is at -plevel+1?
It doesn't presently exist.
That's precisely what the solution I proposed addresses.
In the complete solution I proposed,
'tail -1 /etc/{patchlog'
Or, for a program,
one can popen() that command, and read the output
or even
#include sys/patchlog
#include stdio.h
fd=fopen(PATCHLOG,r);
fseek(fd,PATCHLOG_LAST,SEEK_END);
fgets(line,sizeof(line),fd)
So when does it arrive in -CURRENT? :-)
The entire point of my proposal is to make it an IMMUTATABLE RECORD of
'what was done'. 'add to top' has several disadvantages. First,
a performance issue, you do have to read down the log to find the
first 'END' line rather than being able to seek directly to it.
Second, and the *BIG* one, you risk destroying the prior information
by re-writing the file. Third, it makes it easier for a 'malicious'
update to cover it's tracks.
Additionally, _undoing_ operations would also be logged - not
by omitting lines, but by a proper record that states how things
have been reverted to a previous level, which is also very good
for diagnostics.
If it's being done by automation, it can either log all the individual
'undo' changes, or just log a 'reverting to patchlevel {foo} line.
There are benefits to both approaches.
If it's a 'manual' reversion, there's no way to guarantee anything gets
added to the log.
Let's assume that the standard ways (freebsd-update, make installworld
or
Re: freebsd-update not updating reported patchlevel
Mike Brown m...@skew.org wrote; I installed 8.2-RELEASE when it was new, and have been just using freebsd-update since then. I run freebsd-update whenever there are new critical patches. But for some reason, my system's reported patchlevel number hasn't updated since p3. [sneck] But 'uname -r' continues to return 8.2-RELEASE-p3. Rebooting doesn't help. Is there something I need to do in order to bump the reported patchlevel? I thought this was supposed to happen automatically, since I didn't have to do anything to get it up to -p3. Amazingly, this very question was covered on this list within the last few hours. grin Executive summary: the kernel ID string that uname reports changes only when the -kernel- is changed. -p4, -p5, -p6, and -p7. have -not- involved any changes to the kernel. hence the ID string has stayed at '-p3'. While this _is_ counter-intuitive, it does make sense to avoid pushing a new k ernel out, and/or forcing an admin to rebuild a custom kernel, when the -only- change would be to the ID string. ___ 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; What did I do?
On 31/01/2012 13:55, Martin McCormick wrote: I started to run freebsd-update to upgrade a 8.x system to 9.0-RELEASE # freebsd-update -r 9.0-RELEASE upgrade Looking up update.FreeBSD.org mirrors... 4 mirrors found. Fetching metadata signature for 8.2-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/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/info world/manpages world/proflibs The following components of FreeBSD do not seem to be installed: world/catpages world/games world/lib32 Does this look reasonable (y/n)? yes Fetching metadata signature for 9.0-RELEASE from update5.FreeBSD.org... done. Fetching metadata index... done. The update metadata is correctly signed, but failed an integrity check. Cowardly refusing to proceed any further. # What is the next step, here? That's a known problem and fixable by first updating your 8.2-RELEASE machine to the latest patch level before trying the update to 9.0 http://security.freebsd.org/advisories/FreeBSD-EN-12:01.freebsd-update.asc Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate JID: matt...@infracaninophile.co.uk Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: freebsd-update; What did I do?
Matthew Seaman writes: That's a known problem and fixable by first updating your 8.2-RELEASE machine to the latest patch level before trying the update to 9.0 It appears to be working now. Thank 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
Re: freebsd-update and archs
On 01/22/12 03:45, Christer Solskogen wrote: On Sat, Jan 21, 2012 at 1:21 PM, Colin Percival cperc...@freebsd.org wrote: Try doing a release cross-build and compare it against a non-crossed release build; extract the built tarballs and send me a list of which ones aren't identical. I know which files normally build differently so I can look over the list and tell you if there's something which shouldn't be there. I just did, and the file list is the same. Or do you want me to do a md5 of every file? Yes, I meant to compare the contents of files (or their hashes of course). -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid ___ 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 archs
On Mon, Jan 23, 2012 at 3:03 PM, Colin Percival cperc...@freebsd.org wrote: On 01/22/12 03:45, Christer Solskogen wrote: I just did, and the file list is the same. Or do you want me to do a md5 of every file? Yes, I meant to compare the contents of files (or their hashes of course). Here you go: http://antarctica.no/~solskogen/temp/cross.txt.bz2 http://antarctica.no/~solskogen/temp/native.txt.bz2 http://antarctica.no/~solskogen/temp/diff.txt.bz2 -- chs, ___ 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
