Re: freebsd-update 12.3 to 14.0RC1 takes 12-24 hours (block cloning regression)
On 2023-10-17 09:40:37, Kevin Bowling wrote: The flash SLOG system took around 12 hours to complete freebsd-update from 13.2 to 14.0-RC1. The system without the SLOG took nearly 24 hours. This was the result of ~50k patches, and ~10k files from freebsd-update and a very pathological 'install' command performance. I spoke with mjg about this and because my pools do not have block cloning enabled, copy_file_range turns into a massive pessimization in 'install'. I reported on IRC what I think is the same issue, except in my case this was on an MMC and took many days (I stopped paying attention after 3 days). Piotr
RE: freebsd-update 12.3 to 14.0RC1 takes 12-24 hours (block cloning regression)
Kevin Bowling wrote on Date: Tue, 17 Oct 2023 16:40:37 UTC : > I have two systems with a zpool 2x2 mirror on 7.2k RPM disks. One > system also has a flash SLOG. > > The flash SLOG system took around 12 hours to complete freebsd-update > from 13.2 to 14.0-RC1. The system without the SLOG took nearly 24 > hours. This was the result of ~50k patches, and ~10k files from > freebsd-update and a very pathological 'install' command performance. > > 'ps auxww | grep install': > root 52225 0.0 0.0 12852 2504 0 D+ 20:55 0:00.00 > install -S -o 0 -g 0 -m 0644 > b6850914127c27fe192a41387f5cec04a1d927e6605ff09e8fd88dcd74fdec9d > ///usr/src/sys/netgraph/ng_vlan.h > root 68042 0.0 0.0 13580 3648 0 I+ 02:24 0:01.14 > /bin/sh /usr/sbin/freebsd-update install root 69946 > 0.0 0.0 13580 3632 0 S+ 02:24 0:15.65 /bin/sh > /usr/sbin/freebsd-update install > > 'control+t on freebsd-update': > > load: 0.16 cmd: install 97128 [tx->tx_sync_done_cv] 0.67r 0.00u 0.00s > 0% 2440k > mi_switch+0xc2 _cv_wait+0x113 txg_wait_synced_impl+0xb9 > txg_wait_synced+0xb dmu_offset_next+0x77 zfs_holey+0x137 zfs_fre > ebsd_ioctl+0x4f vn_generic_copy_file_range+0x64b > kern_copy_file_range+0x327 sys_copy_file_range+0x78 > amd64_syscall+0x10c > fast_syscall_common+0xf8 > > I spoke with mjg about this and because my pools do not have block > cloning enabled, copy_file_range turns into a massive pessimization in > 'install'. Block cloning is new. So the past is sort of like Block cloning not being enabled now. This leads me to wonder: prior to block cloning existing, what would analogous times have been like instead of 12 hrs and 24 hrs? (Not that analogous would be easy to identify in history or test now.) Depending on the results, my next question might have been: "What happened for block cloning being disabled now to make it worse than before block cloning existed?" > He suggested a workaround of 'sysctl > vfs.zfs.dmu_offset_next_sync=0' but we should probably sort this out > for 14.0-RELEASE. === Mark Millard marklmi at yahoo.com
freebsd-update 12.3 to 14.0RC1 takes 12-24 hours (block cloning regression)
Hi, I have two systems with a zpool 2x2 mirror on 7.2k RPM disks. One system also has a flash SLOG. The flash SLOG system took around 12 hours to complete freebsd-update from 13.2 to 14.0-RC1. The system without the SLOG took nearly 24 hours. This was the result of ~50k patches, and ~10k files from freebsd-update and a very pathological 'install' command performance. 'ps auxww | grep install': root 52225 0.0 0.0 12852 2504 0 D+ 20:55 0:00.00 install -S -o 0 -g 0 -m 0644 b6850914127c27fe192a41387f5cec04a1d927e6605ff09e8fd88dcd74fdec9d ///usr/src/sys/netgraph/ng_vlan.h root 68042 0.0 0.0 13580 3648 0 I+ 02:24 0:01.14 /bin/sh /usr/sbin/freebsd-update install root 69946 0.0 0.0 13580 3632 0 S+ 02:24 0:15.65 /bin/sh /usr/sbin/freebsd-update install 'control+t on freebsd-update': load: 0.16 cmd: install 97128 [tx->tx_sync_done_cv] 0.67r 0.00u 0.00s 0% 2440k mi_switch+0xc2 _cv_wait+0x113 txg_wait_synced_impl+0xb9 txg_wait_synced+0xb dmu_offset_next+0x77 zfs_holey+0x137 zfs_fre ebsd_ioctl+0x4f vn_generic_copy_file_range+0x64b kern_copy_file_range+0x327 sys_copy_file_range+0x78 amd64_syscall+0x10c fast_syscall_common+0xf8 I spoke with mjg about this and because my pools do not have block cloning enabled, copy_file_range turns into a massive pessimization in 'install'. He suggested a workaround of 'sysctl vfs.zfs.dmu_offset_next_sync=0' but we should probably sort this out for 14.0-RELEASE. Regards, Kevin
Re: git: 989c5f6da990 - main - freebsd-update: create deep BEs by default [really about if -r for bectl create should just go away]
Am 2023-10-12 07:08, schrieb Mark Millard: I use the likes of: BE Active Mountpoint Space Created build_area_for-main-CA72 - - 1.99G 2023-09-20 10:19 main-CA72NR / 4.50G 2023-09-21 10:10 NAMECANMOUNT MOUNTPOINT zopt0 on/zopt0 . . . zopt0/ROOT onnone zopt0/ROOT/build_area_for-main-CA72 noautonone zopt0/ROOT/main-CA72noautonone zopt0/poudriere on /usr/local/poudriere zopt0/poudriere/dataon /usr/local/poudriere/data zopt0/poudriere/data/.m on /usr/local/poudriere/data/.m zopt0/poudriere/data/cache on /usr/local/poudriere/data/cache zopt0/poudriere/data/images on /usr/local/poudriere/data/images zopt0/poudriere/data/logs on /usr/local/poudriere/data/logs zopt0/poudriere/data/packages on /usr/local/poudriere/data/packages zopt0/poudriere/data/wrkdirson /usr/local/poudriere/data/wrkdirs zopt0/poudriere/jails on /usr/local/poudriere/jails zopt0/poudriere/ports on /usr/local/poudriere/ports zopt0/tmp on/tmp zopt0/usr off /usr zopt0/usr/13_0R-src on/usr/13_0R-src zopt0/usr/alt-main-src on/usr/alt-main-src zopt0/usr/home on/usr/home zopt0/usr/local on/usr/local [...] If such ends up as unsupportable, it will effectively eliminate my reason for using bectl (and, so, zfs): the sharing is important to my use. Additionally/complementary to what Kyle said... The -r option is about zop0/ROOT/main-CA72 zop0/ROOT/main-CA72/subDS1 zop0/ROOT/main-CA72/subDS2 A shallow clone is only taking zop0/ROOT/main-CA72 into account, while a -r clone is also cloning subDS1 and subDS2. So as Kyle said, your (and my) use case are not affected by this. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF signature.asc Description: OpenPGP digital signature
Re: git: 989c5f6da990 - main - freebsd-update: create deep BEs by default [really about if -r for bectl create should just go away]
On 10/12/23 00:08, Mark Millard wrote: Kyle Evans wrote on Date: Thu, 12 Oct 2023 02:54:13 UTC : The branch main has been updated by kevans: URL: https://cgit.FreeBSD.org/src/commit/?id=989c5f6da99081b1f2b76ec09e91078e531e1250 commit 989c5f6da99081b1f2b76ec09e91078e531e1250 Author: Kyle Evans AuthorDate: 2023-10-12 02:51:07 + Commit: Kyle Evans CommitDate: 2023-10-12 02:54:03 + freebsd-update: create deep BEs by default The -r flag to bectl needs to go away, and we need to just do the right thing. In the meantime, we can apply an -r in freebsd-update as a minimal fix to stop creating partial backups in these (non-default) deep BE setups. These notes about not about the specific commit, nor about if -r like behavior should be the default for bectl create. The notes are about if the currently "not -r" bectl create behavior should become impossible vs. being supported --or, more accurately, what layouts are possible. (In case I'm misreading the implications of the -r wording.) The primary reason I use zfs is to use bectl, not for the other kinds of reasons zfs is typically used for. [...] I've got such a set up (up to naming differences) as my default boot media for each of: ThreadRipper 1950X, HoneyComb, Windows DevKit 2023, MACCHIATObin Double Shot. I also sometimes use such boot media with the 8 GiByte RPI4B's. (The smaller capacity systems [all aarch64/armv7] basically just boot UFS media --that I normally produce from the HoneyCmb's bectl based boot context.) If such ends up as unsupportable, it will effectively eliminate my reason for using bectl (and, so, zfs): the sharing is important to my use. -r should do the right thing in all cases, the only real difference from w/o -r is that it'll recurse into subordinates of the BE dataset. For the common case, including yours, that means there's no functional difference and negligible overhead added (because we still have to try to iterate over childfren, even if there are none). Thanks, Kyle Evans
RE: git: 989c5f6da990 - main - freebsd-update: create deep BEs by default [really about if -r for bectl create should just go away]
Kyle Evans wrote on Date: Thu, 12 Oct 2023 02:54:13 UTC : > The branch main has been updated by kevans: > > URL: > https://cgit.FreeBSD.org/src/commit/?id=989c5f6da99081b1f2b76ec09e91078e531e1250 > > commit 989c5f6da99081b1f2b76ec09e91078e531e1250 > Author: Kyle Evans > AuthorDate: 2023-10-12 02:51:07 + > Commit: Kyle Evans > CommitDate: 2023-10-12 02:54:03 + > > freebsd-update: create deep BEs by default > > The -r flag to bectl needs to go away, and we need to just do the right > thing. In the meantime, we can apply an -r in freebsd-update as a > minimal fix to stop creating partial backups in these (non-default) deep > BE setups. These notes about not about the specific commit, nor about if -r like behavior should be the default for bectl create. The notes are about if the currently "not -r" bectl create behavior should become impossible vs. being supported --or, more accurately, what layouts are possible. (In case I'm misreading the implications of the -r wording.) The primary reason I use zfs is to use bectl, not for the other kinds of reasons zfs is typically used for. I use the likes of: BE Active Mountpoint Space Created build_area_for-main-CA72 - - 1.99G 2023-09-20 10:19 main-CA72NR / 4.50G 2023-09-21 10:10 NAMECANMOUNT MOUNTPOINT zopt0 on/zopt0 . . . zopt0/ROOT onnone zopt0/ROOT/build_area_for-main-CA72 noautonone zopt0/ROOT/main-CA72noautonone zopt0/poudriere on/usr/local/poudriere zopt0/poudriere/dataon/usr/local/poudriere/data zopt0/poudriere/data/.m on /usr/local/poudriere/data/.m zopt0/poudriere/data/cache on /usr/local/poudriere/data/cache zopt0/poudriere/data/images on /usr/local/poudriere/data/images zopt0/poudriere/data/logs on /usr/local/poudriere/data/logs zopt0/poudriere/data/packages on /usr/local/poudriere/data/packages zopt0/poudriere/data/wrkdirson /usr/local/poudriere/data/wrkdirs zopt0/poudriere/jails on/usr/local/poudriere/jails zopt0/poudriere/ports on/usr/local/poudriere/ports zopt0/tmp on/tmp zopt0/usr off /usr zopt0/usr/13_0R-src on/usr/13_0R-src zopt0/usr/alt-main-src on/usr/alt-main-src zopt0/usr/home on/usr/home zopt0/usr/local on/usr/local zopt0/usr/main-src on/usr/main-src zopt0/usr/ports on/usr/ports zopt0/usr/src on/usr/src zopt0/var off /var zopt0/var/audit on/var/audit zopt0/var/crash on/var/crash zopt0/var/dbnoauto/var/db zopt0/var/db/pkgon/var/db/pkg zopt0/var/db/ports on/var/db/ports zopt0/var/log on/var/log zopt0/var/mail on/var/mail zopt0/var/tmp on/var/tmp where every "CANMOUNT on" for a zopt0/[a-z]... prefixed row ( not zopt0/ROOT/* ) is used when booting any of: zopt0/ROOT/build_area_for-main-CA72 noautonone zopt0/ROOT/main-CA72noautonone So: shared, not duplicated. The update sequence creates a snapshot of zopt0/ROOT/main-CA72 and then creates a zopt0/ROOT/new-main-CA72 from that which is then mounted and that is what the installkernel and installworld update. Dismount. Temporarily activate it. Reboot. Destroy build_area_for-main-CA72 . Rename main-CA72 to build_area_for-main-CA72 . Rename new-main-CA72 to main-CA72 . (It, then, again looks like the above.) I sometimes also temporarily have a zopt0/ROOT/alt-main-CA72 that also shares to avoid duplication. (I'll not get into the details, but build_area_for-main-CA72 is used to do the buildworld buildkernel and is what I can revert to in case of problems discovered later. I've not shown the build tree areas above, just to keep things simpler. They too are shared across the BE's.) I've no reason to want to maintain duplicates of any of that " shared across zopt0/ROOT/* " material: no deep BE setup desired. I've got such a set up (up to naming differences) as my default boot media for each of: ThreadRipper 1950
Re: (263489) (D35109) freebsd-update: restart sshd after upgrade
On Mon, 2 May 2022 at 20:17, Graham Perrin wrote: > > <https://github.com/freebsd/freebsd-src/commit/6cd1bc53160973fc421c59f66aaa7e4b37a8cebe#diff-ed3905e89b1b292bd271b3defd3ae0442a250eeed5623f5dc31aeba248b353a8R3028> > (line 3028) > > How will freebsd-update behave in this case? > > > Cannot 'status' sshd. Set sshd_enable to YES in /etc/rc.conf or use > > 'onestatus' instead of 'status'. If it's not already running nothing will happen.
Re: (263489) (D35109) freebsd-update: restart sshd after upgrade
On 03/05/2022 02:15, Graham Perrin wrote: <https://github.com/freebsd/freebsd-src/commit/6cd1bc53160973fc421c59f66aaa7e4b37a8cebe#diff-ed3905e89b1b292bd271b3defd3ae0442a250eeed5623f5dc31aeba248b353a8R3028> (line 3028) How will freebsd-update behave in this case? Cannot 'status' sshd. Set sshd_enable to YES in /etc/rc.conf or use 'onestatus' instead of 'status'. (I'd test for myself, but it's late, and I'd like to seed the thought before I forget.) Shouldn't it be user configurable if (any) service should be restarted during update / upgrade? I remember sshd not starting after upgrade in the past. I don't use freebsd-update, but doing sshd restart by hand and sometimes there are some incompatible changes which prevent sshd from starting. This "safety" sshd restart can be dangerous too. Kind regards Miroslav Lachman
(263489) (D35109) freebsd-update: restart sshd after upgrade
<https://github.com/freebsd/freebsd-src/commit/6cd1bc53160973fc421c59f66aaa7e4b37a8cebe#diff-ed3905e89b1b292bd271b3defd3ae0442a250eeed5623f5dc31aeba248b353a8R3028> (line 3028) How will freebsd-update behave in this case? Cannot 'status' sshd. Set sshd_enable to YES in /etc/rc.conf or use 'onestatus' instead of 'status'. (I'd test for myself, but it's late, and I'd like to seed the thought before I forget.)
(232921) somewhat random pw-related errors following system upgrades (was: freebsd-update(8) without an echo of "You must be root to run this.")
On 19/02/2021 21:59, Chris Rees wrote: Hey, On 16 February 2021 08:53:29 GMT, Graham Perrin wrote: <https://cgit.freebsd.org/src/tree/usr.sbin/freebsd-update/freebsd-update.sh?id=48ffe56ac5b7adb5b851d32be12b2ec0f13705a4#n555> echo "You must be root to run this." Below: is this my PEBKAM, or (with a system that is preconfigured to deny login as root) _should_ there be an echo of the requirement to run as root? mowa219-gjp4-vm-hellosystem-eol-freebsd% su - Password: su: Sorry mowa219-gjp4-vm-hellosystem-eol-freebsd% sudo grep LOCKED /etc/master.passwd root:*LOCKED*:0:0::0:0:Charlie &:/root:/bin/csh mowa219-gjp4-vm-hellosystem-eol-freebsd% sudo freebsd-update upgrade -r Sudo means that you are root. *LOCKED* just disables the root password. Chris Thanks for the clarification. As background: I spent many hours repeatedly testing freebsd-update upgrade from 12.1-RELEASE to 12.2-RELEASE-p3 (and greater) in virtual machines, trying to understand why (a bug) mysql57-server would not install following an upgrade with the root password _disabled_. Later tests included multiple consecutive successes (bug-free) with the root password _enabled_ – enough consecutive successes for me to assume that the bug was somehow caused by the *LOCKED* aspect. That period of consistent success was followed by reproduction of the bug with the root password _enabled_, at which point I realised the wrongness of my assumption. Confused by the randomness, I began to wonder whether – in rare situations – sudo might be not entirely effective. Eventually I realised, the failures to install mysql57-server were symptomatic of FreeBSD bug 232921 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232921>, which involves pwd_mkdb(8). I'll not attempt to understand why bug 232921 was not consistently reproducible during my tests, but I'm glad that it's unrelated to disabling the root password; and I no longer doubt the usefulness of sudo :-) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-update(8) without an echo of "You must be root to run this."
Hey, On 16 February 2021 08:53:29 GMT, Graham Perrin wrote: ><https://cgit.freebsd.org/src/tree/usr.sbin/freebsd-update/freebsd-update.sh?id=48ffe56ac5b7adb5b851d32be12b2ec0f13705a4#n555> > > echo "You must be root to run this." > >Below: is this my PEBKAM, or (with a system that is preconfigured to >deny login as root) _should_ there be an echo of the requirement to run > >as root? > > > >mowa219-gjp4-vm-hellosystem-eol-freebsd% su - >Password: >su: Sorry >mowa219-gjp4-vm-hellosystem-eol-freebsd% sudo grep LOCKED >/etc/master.passwd >root:*LOCKED*:0:0::0:0:Charlie &:/root:/bin/csh >mowa219-gjp4-vm-hellosystem-eol-freebsd% sudo freebsd-update upgrade -r Sudo means that you are root. *LOCKED* just disables the root password. Chris ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
freebsd-update(8) without an echo of "You must be root to run this."
<https://cgit.freebsd.org/src/tree/usr.sbin/freebsd-update/freebsd-update.sh?id=48ffe56ac5b7adb5b851d32be12b2ec0f13705a4#n555> echo "You must be root to run this." Below: is this my PEBKAM, or (with a system that is preconfigured to deny login as root) _should_ there be an echo of the requirement to run as root? mowa219-gjp4-vm-hellosystem-eol-freebsd% su - Password: su: Sorry mowa219-gjp4-vm-hellosystem-eol-freebsd% sudo grep LOCKED /etc/master.passwd root:*LOCKED*:0:0::0:0:Charlie &:/root:/bin/csh mowa219-gjp4-vm-hellosystem-eol-freebsd% sudo freebsd-update upgrade -r 13.0-BETA2 src component not installed, skipped Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching metadata signature for 12.1-RELEASE from update4.freebsd.org... done. Fetching metadata index... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/generic world/base world/doc The following components of FreeBSD do not seem to be installed: kernel/generic-dbg world/base-dbg world/lib32 world/lib32-dbg Does this look reasonable (y/n)? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Freebsd-update
On Mon, 27 Jul 2020 15:49:46 -0700 bsd-li...@bsdforge.com said On Mon, 27 Jul 2020 15:14:49 -0700 Michael Dexter edi...@callfortesting.org said > On 7/17/20 4:37 AM, Cristian Cardoso wrote: > > I would like to know if by chance in freeBSD there is some kind of log > > when the command freebsd-update fetch / install is executed? > > I looked in the documentation and found nothing about it. > > There does not appear to be a log but running it with '--debug' is very > informative. Perhaps run a typescript for each run to capture this? > > All, is the debug output something that should be logged? Aren't the installs/up(grade|date)s individually logged in /var/messages? Ahem... I mean't: /var/log/messages Sorry. :( > > Michael --Chris ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Freebsd-update
On Mon, 27 Jul 2020 15:14:49 -0700 Michael Dexter edi...@callfortesting.org said On 7/17/20 4:37 AM, Cristian Cardoso wrote: > I would like to know if by chance in freeBSD there is some kind of log > when the command freebsd-update fetch / install is executed? > I looked in the documentation and found nothing about it. There does not appear to be a log but running it with '--debug' is very informative. Perhaps run a typescript for each run to capture this? All, is the debug output something that should be logged? Aren't the installs/up(grade|date)s individually logged in /var/messages? Michael --Chris ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Freebsd-update
On 7/17/20 4:37 AM, Cristian Cardoso wrote: I would like to know if by chance in freeBSD there is some kind of log when the command freebsd-update fetch / install is executed? I looked in the documentation and found nothing about it. There does not appear to be a log but running it with '--debug' is very informative. Perhaps run a typescript for each run to capture this? All, is the debug output something that should be logged? Michael ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Freebsd-update
Hello I would like to know if by chance in freeBSD there is some kind of log when the command freebsd-update fetch / install is executed? I looked in the documentation and found nothing about it. Does anyone know if this exists? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-update: to a specific patch level - help please? [PATCH]
On 18-03-24 10:26 AM, Derek wrote: On 18-03-23 06:44 AM, Kurt Jaeger wrote: To be clear, *I've included a link to a patch to freebsd-update in my initial post, and the help I'm looking for: is to get this functionality added as a feature so others can benefit.* It works for me already, and I've already benefited. Please submit this in a PR, and post the PR number here, I'll work to get this in the tree. PR is 226893 FYI - Just awaiting any kind of feedback on the PC. Won't be starting anything until then. Derek ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-update: to a specific patch level - help please? [PATCH]
On 18-03-23 06:44 AM, Kurt Jaeger wrote: Hi! To be clear, *I've included a link to a patch to freebsd-update in my initial post, and the help I'm looking for: is to get this functionality added as a feature so others can benefit.* It works for me already, and I've already benefited. (I'm happy to flesh it out, and document it properly, but I'm very hesitant to spend the time doing it in detail and submitting a PR if I'm doing this in isolation, and nobody wants it. Please submit this in a PR, and post the PR number here, I'll work to get this in the tree. PR is 226893 Thanks! Derek ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-update: to a specific patch level - help please? [PATCH]
Hi! > To be clear, *I've included a link to a patch to freebsd-update > in my initial post, and the help I'm looking for: is to get this > functionality added as a feature so others can benefit.* It > works for me already, and I've already benefited. > > (I'm happy to flesh it out, and document it properly, but I'm > very hesitant to spend the time doing it in detail and submitting > a PR if I'm doing this in isolation, and nobody wants it. Please submit this in a PR, and post the PR number here, I'll work to get this in the tree. -- p...@opsec.eu+49 171 3101372 2 years to go ! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-update: to a specific patch level - help please? [PATCH]
On 18-03-21 05:24 PM, Rainer Duffner wrote: Am 21.03.2018 um 22:12 schrieb Derek (freebsd lists) <48225...@razorfever.net>: Hi! I was surprised when using freebsd-update, that there was no way to specify a patch level. AFAIK, the usual answer to these kinds of requests is: „Run your own freebsd-update server“. Mirroring one of the existing ones is AFAIK neither guaranteed to work nor desired by the current „administration“. Thanks for your thoughts. To be clear, *I've included a link to a patch to freebsd-update in my initial post, and the help I'm looking for: is to get this functionality added as a feature so others can benefit.* It works for me already, and I've already benefited. (I'm happy to flesh it out, and document it properly, but I'm very hesitant to spend the time doing it in detail and submitting a PR if I'm doing this in isolation, and nobody wants it. Perhaps the silence on the thread is already a good indicator of the appetite, although I fear it's my ability to sell it or myself properly.) Structurally, "run your own freebsd-update server" is a wasteful solution for a single (or much larger set of) default install(s). It makes a lot of sense for custom installations. For what should be the default approach: repeatable - version controlled - installations with the support of the FreeBSD project, it would seem that having freebsd-update support patch levels would be a far more efficient net use of people's time than the alternatives. (I was debating both running an update server, or running "behind" a hacked up mirror as well, and in fact, I feel patching freebsd-update was a great investment, for n=1.) It’s also a somewhat transient problem now because - AFAIK - FreeBSD will see packaged base and you can probably mirror those packages and snapshot the directory at any point in time. And/Or it’s just easier to create these base-packages yourselves vs. running your own freebsd-update server. This is a good point, and perhaps why it's not worth putting more time into this. I appreciate your feedback. Thanks! Derek ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-update: to a specific patch level - help please?
> Am 21.03.2018 um 22:12 schrieb Derek (freebsd lists) > <48225...@razorfever.net>: > > Hi! > > I was surprised when using freebsd-update, that there was no way to specify a > patch level. AFAIK, the usual answer to these kinds of requests is: „Run your own freebsd-update server“. Mirroring one of the existing ones is AFAIK neither guaranteed to work nor desired by the current „administration“. I’ve contemplated doing both, but never had enough heart-ache to do it and never thought the pay-off would be greater than the potential problems. It’s also a somewhat transient problem now because - AFAIK - FreeBSD will see packaged base and you can probably mirror those packages and snapshot the directory at any point in time. And/Or it’s just easier to create these base-packages yourselves vs. running your own freebsd-update server. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
freebsd-update: to a specific patch level - help please?
Hi! I was surprised when using freebsd-update, that there was no way to specify a patch level. In my day to day, I need to ensure security patches are applied. I also need to assess the impact of patches, and ensure consistency (ie. versions) in my environments. This can take time. Here's a story for context, please feel free to skip: We are planning to cut our 10.3-RELEASE infrastructure over to 11.1-RELEASE before the end of the month, because it's EoL in April. We updated and cut over our production load balancer March 6th (and patted ourselves on the back for being ahead of schedule), and within less than 12 hours, updated our backup load balancers. Unfortunately, we're now on ever so slightly different versions (-p6/-p7), and we're not affected by the -p7 problems. This makes my eye twitch slightly, especially when -p7 was the first patch of 2018. Now we need to upgrade our application servers, that are running our trusted code, and -p8 comes out. I'm nervous about just applying -p8, but I definitely want to upgrade to 11.1-RELEASE asap. After assessing the impact of -p8 on our infrastructure, I feel the security risk is relatively low in the short term (and we've waited this long anyway), but I feel the probability of introducing unintended side-effects is high, and want some time to test and asses. /story It would seem to me, for repeatable environments, that binary updates from FreeBSD that can be pinned to specific version are highly desireable. I've gone ahead and created a patch for my use here: https://github.com/derekmarcotte/freebsd/commit/009015a7dda5d1f1c46f4706c222614f17fb535c (there's a 10.3-specific one here: https://github.com/derekmarcotte/freebsd/commit/458879f36ae984add0ff525fb6c2765fcf1fba67 ) I'd be happy to open a PR, and to iterate and improve on this PoC, but if there's no support from the project, I'll keep it to myself. I guess what I'm asking is, for these reasons, is anyone willing to work with me (in mentorship+commit bits) to add this feature (maybe not this particular implementation) to freebsd-update? Thanks! Derek ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
freebsd-update and portsnap users still at risk of compromise
On July 18, John Leyden, security editor at The Register, tweeted a link to a libarchive ticket that had been sitting without a response for almost a week. tweet: https://twitter.com/jleyden/status/755016810865582081 libarchive ticket: https://github.com/libarchive/libarchive/issues/743 The ticket creator quoted an AV researcher who was likely posting to one of the many early-alert vendor lists in the age of infosec balkanization (IOW, a "courtesy heads-up" to FreeBSD users forking them money): [QUOTE] Our AV researchers have analyzed the following link that was cloud- submitted as suspect: https://gist.github.com/anonymous/e48209b03f1dd9625a992717e7b89c4f The document is from an unknown author and describes "non-cryptanalytic attacks against FreeBSD update components." The affected components are the portsnap and freebsd-update tools, both directly and indirectly. From what we can tell, the text file is part of a larger stash of documents, all with the same attack-defense style. We have other documents, dated 2014 and 2015, detailing attacks against the update systems of multiple Linux distributions and the corresponding defenses against "the adversary." We believe this to be the work of an MITM-capable advanced threat actor. Full details of our findings will be released in the coming weeks. This is a courtesy heads-up to FreeBSD users. [/QUOTE] Another poster confirmed some of the attacks: [QUOTE] Here via John Leyden's tweet. I don't have the time to test the portsnap attacks, but I can confirm that the libarchive/tar and bspatch attacks work on our 10.x machines, and I'm happy to test any libarchive/tar fixes. Judging by the painstaking amount of work put into the bspatch exploit especially, I think it's highly unlikely that the creator lacks the means to deploy it via mitm. Otherwise, I've never seen anything like this in terms of apparent work/reward. It would be comical if it weren't so horrifying. Think of all those locked-down fbsd machines that have no external-facing daemons/services and that perform only updates. Our telecommunications floor alone has several dozen. Someone needs to alert the fbsd mailing lists (-current, -security?) pronto. I'd rather not mail them myself from work. And we should also get more details on the linux distributions. [/QUOTE] I've been analyzing the document extensively since then. The targets are as follows: [1] portsnap via portsnap vulnerabilities [2] portsnap via libarchive & tar anti-sandboxing vulnerabilities [3] portsnap via bspatch vulnerabilities [4] freebsd-update via bspatch vulnerabilities Nothing has appeared in any official FreeBSD source about [1]. The libarchive developers have finally confirmed [2] and are presumably working on fixes. A FreeBSD advisory just appeared for [3] & [4] (bspatch), but users should be aware that running freebsd-update exposes their machines to the very vulnerability it's correcting (a not insignificant fact that was omitted from the advisory). Here's why: [QUOTE] * The bspatch(1) utility is executed before SHA256 verification in both * freebsd-update(8) and portsnap(8). [/QUOTE] Even worse, the patch in the FreeBSD advisory is insufficient to prevent heap corruption. I compared the patch in the FreeBSD advisory with the "defense" patch in the document, and the former contains only a subset of the checks in the latter. The document patch is in some ways cautious to an insanely paranoid degree, mistrusting the error-checking stability of system libraries and defending against compiler quirks that probably won't exist in compiler optimization intelligence for many years, if ever, though as a developer of clang-based static analyzers, I did take an interest in one of the more usual integer-overflow culprits: [ADVISORY PATCH - CONTAINS ONLY A SUBSET OF DOCUMENT PATCH] /* Sanity-check */ + if ((ctrl[0] < 0) || (ctrl[1] < 0)) + errx(1,"Corrupt patch\n"); + + /* Sanity-check */ if(newpos+ctrl[0]>newsize) errx(1,"Corrupt patch\n"); [/ADVISORY PATCH] [DOCUMENT PATCH - THE CORRESPONDING PORTION] /* Sanity-check */ - if(newpos+ctrl[0]>newsize) - errx(1,"Corrupt patch\n"); + if((ctrl[0]<0) || (ctrl[0]>INT_MAX) || + (newpos>OFF_MAX-ctrl[0]) || (newpos+ctrl[0]>newsize)) + errx(1,"Corrupt patch\n"); - /* Read diff string */ + /* Read diff string - 4th arg converted to int */ lenread = BZ2_bzRead(, dpfbz2, new + newpos, ctrl[0]); if ((lenread < ctrl[0]) || ((dbz2err != BZ_OK) && (dbz2err != BZ_STREAM_END))) errx(1, "Corrupt patch\n"); [/DOCUMENT PATCH]
freebsd-update
Hello.
Please consider a new clean command in the freebsd-update script. The modified
manual and script are located at https://github.com/textbrowser/freebsd-update.
Included are two diffs. Sorry for the long e-mail.
--- /usr/src/usr.sbin/freebsd-update/freebsd-update.8 2015-08-12
10:21:35.0 -0400
+++ ./freebsd-update.8 2016-04-02 15:16:47.780095000 -0400
@@ -119,6 +119,12 @@
.Cm command
can be any one of the following:
.Bl -tag -width "rollback"
+.It Cm clean
+Remove the contents of
+.Ar workdir .
+(default:
+.Ar /var/db/freebsd-update/
+).
.It Cm fetch
Based on the currently installed world and the configuration
options set, fetch all available binary updates.
--- /usr/src/usr.sbin/freebsd-update/freebsd-update.sh 2015-08-12
10:21:35.0 -0400
+++ ./freebsd-update.sh 2016-04-02 15:26:57.990003000 -0400
@@ -53,6 +53,7 @@
--not-running-from-cron
-- Run without a tty, for use by automated tools
Commands:
+ clean -- Clean workdir
fetch -- Fetch updates from server
cron -- Sleep rand(3600) seconds, fetch updates, and send an
email if updates were found
@@ -474,7 +475,7 @@
;;
# Commands
- cron | fetch | upgrade | install | rollback | IDS)
+ clean | cron | fetch | upgrade | install | rollback | IDS)
COMMANDS="${COMMANDS} $1"
;;
@@ -559,6 +560,25 @@
mergeconfig
}
+# Perform sanity checks in preparation of cleaning workdir.
+clean_check_params () {
+ # Check that we are root. All sorts of things won't work otherwise.
+ if [ `id -u` != 0 ]; then
+ echo "You must be root to run this."
+ exit 1
+ fi
+
+ # Check that we have a working directory.
+ _WORKDIR_bad="Directory does not exist or is not writable: "
+ if ! [ -d "${WORKDIR}" -a -w "${WORKDIR}" ]; then
+ echo -n "`basename $0`: "
+ echo -n "${_WORKDIR_bad}"
+ echo ${WORKDIR}
+ exit 1
+ fi
+ cd ${WORKDIR} || exit 1
+}
+
# Set utility output filtering options, based on ${VERBOSELEVEL}
fetch_setup_verboselevel () {
case ${VERBOSELEVEL} in
@@ -2047,6 +2067,11 @@
echo ${NOWTIME} > lasteolwarn
}
+# Clean workdir.
+clean_run() {
+ rm -fr *
+}
+
# Do the actual work involved in "fetch" / "cron".
fetch_run () {
workdir_init || return 1
@@ -3225,6 +3250,12 @@
default_params
}
+# Clean command. Allow non-interactive use.
+cmd_clean () {
+ clean_check_params
+ clean_run || exit 1
+}
+
# Fetch command. Make sure that we're being called
# interactively, then run fetch_check_params and fetch_run
cmd_fetch () {
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Devops question: freebsd-update needs a real tty to run, problem for automation
On Tue, Jan 13, 2015 at 4:14 PM, Allan Jude allanj...@freebsd.org wrote: On 2015-01-13 18:11, Craig Rodrigues wrote: Hi, Ahmed Kamal, a devops expert, is helping me to script the steps to upgrade a cluster of FreeBSD machines. For certain machines, we want to track the official FreeBSD releases and use freebsd-update to install official updates. We found that when the invocation of freebsd-update was scripted and not run via a real tty, we can into this error: freebsd-update fetch should not be run non-interactively. There are various workarounds mentioned on various web pages. However, should we modify freebsd-update so that it can work better when not run via a real tty? This would make it more devops/automation friendly. The closest thing I have found is freebsd-update cron, which can fetch the updates and run without a real tty. The only problem with freebsd-update cron is that it sleeps a random amount of time between 1 and 3600 seconds before fetching the updates. This is OK when run in a cron job, but not OK when run as part of a devops automation framework. Anybody have ideas as to the best way to proceed in fixing this in freebsd-update? -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org I think this requirement was originally added when Colin hosted the mirrors for FreeBSD update himself, and was worried about everyone scripting it to run via crontab at midnight every night. It is likely a false requirement, and can be safely removed. Dealing with the merges, only really affects version upgrades, and is less of an issue compared to being able to automate security fixes. Hi, I submitted this review: https://reviews.freebsd.org/D1665 to remove the check for an interactive tty in freebsd-update fetch. Being able to run freebsd-update fetch via automation will make it much more convenient to update clusters of FreeBSD nodes. -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Devops question: freebsd-update needs a real tty to run, problem for automation
Hi, Ahmed Kamal, a devops expert, is helping me to script the steps to upgrade a cluster of FreeBSD machines. For certain machines, we want to track the official FreeBSD releases and use freebsd-update to install official updates. We found that when the invocation of freebsd-update was scripted and not run via a real tty, we can into this error: freebsd-update fetch should not be run non-interactively. There are various workarounds mentioned on various web pages. However, should we modify freebsd-update so that it can work better when not run via a real tty? This would make it more devops/automation friendly. The closest thing I have found is freebsd-update cron, which can fetch the updates and run without a real tty. The only problem with freebsd-update cron is that it sleeps a random amount of time between 1 and 3600 seconds before fetching the updates. This is OK when run in a cron job, but not OK when run as part of a devops automation framework. Anybody have ideas as to the best way to proceed in fixing this in freebsd-update? -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Devops question: freebsd-update needs a real tty to run, problem for automation
On 1/13/2015 5:11 PM, Craig Rodrigues wrote: Hi, Ahmed Kamal, a devops expert, is helping me to script the steps to upgrade a cluster of FreeBSD machines. For certain machines, we want to track the official FreeBSD releases and use freebsd-update to install official updates. We found that when the invocation of freebsd-update was scripted and not run via a real tty, we can into this error: freebsd-update fetch should not be run non-interactively. There are various workarounds mentioned on various web pages. However, should we modify freebsd-update so that it can work better when not run via a real tty? This would make it more devops/automation friendly. The closest thing I have found is freebsd-update cron, which can fetch the updates and run without a real tty. The only problem with freebsd-update cron is that it sleeps a random amount of time between 1 and 3600 seconds before fetching the updates. This is OK when run in a cron job, but not OK when run as part of a devops automation framework. Anybody have ideas as to the best way to proceed in fixing this in freebsd-update? -- Craig sed -i '' -e 's,-t 0 ];,-t 0 ] \\ [ 0 -eq 1 ],' /usr/sbin/freebsd-update This is untested. We'll likely put it in Poudriere as well. IMHO the check should be removed in the official version. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Devops question: freebsd-update needs a real tty to run, problem for automation
On Tue, Jan 13, 2015 at 05:29:16PM -0600, Bryan Drewery wrote: On 1/13/2015 5:11 PM, Craig Rodrigues wrote: Hi, Ahmed Kamal, a devops expert, is helping me to script the steps to upgrade a cluster of FreeBSD machines. For certain machines, we want to track the official FreeBSD releases and use freebsd-update to install official updates. We found that when the invocation of freebsd-update was scripted and not run via a real tty, we can into this error: freebsd-update fetch should not be run non-interactively. There are various workarounds mentioned on various web pages. However, should we modify freebsd-update so that it can work better when not run via a real tty? This would make it more devops/automation friendly. The closest thing I have found is freebsd-update cron, which can fetch the updates and run without a real tty. The only problem with freebsd-update cron is that it sleeps a random amount of time between 1 and 3600 seconds before fetching the updates. This is OK when run in a cron job, but not OK when run as part of a devops automation framework. Anybody have ideas as to the best way to proceed in fixing this in freebsd-update? -- Craig sed -i '' -e 's,-t 0 ];,-t 0 ] \\ [ 0 -eq 1 ],' /usr/sbin/freebsd-update This is untested. We'll likely put it in Poudriere as well. IMHO the check should be removed in the official version. You do not need it in poudriere as the rexec binary emulates a tty to workaround this. Best regards, Bapt pgpTkV4xcLG1l.pgp Description: PGP signature
Re: Devops question: freebsd-update needs a real tty to run, problem for automation
On Tue, Jan 13, 2015 at 3:29 PM, Bryan Drewery bdrew...@freebsd.org wrote:
On 1/13/2015 5:11 PM, Craig Rodrigues wrote:
Hi,
Ahmed Kamal, a devops expert, is helping me to script the steps to
upgrade a cluster of FreeBSD machines. For certain machines,
we want to track the official FreeBSD releases and use freebsd-update
to install official updates.
We found that when the invocation of freebsd-update was scripted
and not run via a real tty, we can into this error:
freebsd-update fetch should not be run non-interactively.
There are various workarounds mentioned on various web pages.
However, should we modify freebsd-update so that it can work better
when not run via a real tty? This would make it more devops/automation
friendly.
The closest thing I have found is freebsd-update cron, which can fetch
the updates and run without a real tty. The only problem with
freebsd-update cron
is that it sleeps a random amount of time between 1 and 3600 seconds before
fetching the updates. This is OK when run in a cron job,
but not OK when run as part of a devops automation framework.
Anybody have ideas as to the best way to proceed in fixing this in
freebsd-update?
--
Craig
sed -i '' -e 's,-t 0 ];,-t 0 ] \\ [ 0 -eq 1 ],' /usr/sbin/freebsd-update
This is untested. We'll likely put it in Poudriere as well.
freebsd-update needs to grow a non-interactive option probably:
2375 read dummy /dev/tty
2376 ${EDITOR} `pwd`/merge/new/${F} /dev/tty
2377 done failed.merges
2378 rm failed.merges
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Devops question: freebsd-update needs a real tty to run, problem for automation
On Tue, Jan 13, 2015 at 4:09 PM, NGie Cooper yaneurab...@gmail.com wrote:
On Tue, Jan 13, 2015 at 3:29 PM, Bryan Drewery bdrew...@freebsd.org wrote:
On 1/13/2015 5:11 PM, Craig Rodrigues wrote:
Hi,
Ahmed Kamal, a devops expert, is helping me to script the steps to
upgrade a cluster of FreeBSD machines. For certain machines,
we want to track the official FreeBSD releases and use freebsd-update
to install official updates.
We found that when the invocation of freebsd-update was scripted
and not run via a real tty, we can into this error:
freebsd-update fetch should not be run non-interactively.
There are various workarounds mentioned on various web pages.
However, should we modify freebsd-update so that it can work better
when not run via a real tty? This would make it more devops/automation
friendly.
The closest thing I have found is freebsd-update cron, which can fetch
the updates and run without a real tty. The only problem with
freebsd-update cron
is that it sleeps a random amount of time between 1 and 3600 seconds before
fetching the updates. This is OK when run in a cron job,
but not OK when run as part of a devops automation framework.
Anybody have ideas as to the best way to proceed in fixing this in
freebsd-update?
--
Craig
sed -i '' -e 's,-t 0 ];,-t 0 ] \\ [ 0 -eq 1 ],' /usr/sbin/freebsd-update
This is untested. We'll likely put it in Poudriere as well.
freebsd-update needs to grow a non-interactive option probably:
2375 read dummy /dev/tty
2376 ${EDITOR} `pwd`/merge/new/${F} /dev/tty
2377 done failed.merges
2378 rm failed.merges
$ grep -nr /dev/tty `which freebsd-update`
2375:read dummy /dev/tty
2376:${EDITOR} `pwd`/merge/new/${F} /dev/tty
2405:continuep /dev/tty || return 1
2417:continuep /dev/tty || return 1
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Devops question: freebsd-update needs a real tty to run, problem for automation
On 2015-01-13 18:11, Craig Rodrigues wrote: Hi, Ahmed Kamal, a devops expert, is helping me to script the steps to upgrade a cluster of FreeBSD machines. For certain machines, we want to track the official FreeBSD releases and use freebsd-update to install official updates. We found that when the invocation of freebsd-update was scripted and not run via a real tty, we can into this error: freebsd-update fetch should not be run non-interactively. There are various workarounds mentioned on various web pages. However, should we modify freebsd-update so that it can work better when not run via a real tty? This would make it more devops/automation friendly. The closest thing I have found is freebsd-update cron, which can fetch the updates and run without a real tty. The only problem with freebsd-update cron is that it sleeps a random amount of time between 1 and 3600 seconds before fetching the updates. This is OK when run in a cron job, but not OK when run as part of a devops automation framework. Anybody have ideas as to the best way to proceed in fixing this in freebsd-update? -- Craig ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org I think this requirement was originally added when Colin hosted the mirrors for FreeBSD update himself, and was worried about everyone scripting it to run via crontab at midnight every night. It is likely a false requirement, and can be safely removed. Dealing with the merges, only really affects version upgrades, and is less of an issue compared to being able to automate security fixes. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: freebsd-update install failed
d...@gmx.com wrote on 10/24/2014 04:09: # freebsd-update install Installing updates...install: ///usr/src/contrib/tzdata/zone1970.tab: No such file or directory done. # OK, maybe the install didn't fail, and the quirk is ignorable. However, in any case, freebsd-update shouldn't try to update anything in /usr/src. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update install failed
On 2014-10-24 12:23, d...@gmx.com wrote: d...@gmx.com wrote on 10/24/2014 04:09: # freebsd-update install Installing updates...install: ///usr/src/contrib/tzdata/zone1970.tab: No such file or directory done. # OK, maybe the install didn't fail, and the quirk is ignorable. However, in any case, freebsd-update shouldn't try to update anything in /usr/src. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Do you have a src tree installed? This error is usually caused by it trying to install the update to an empty src tree, so the contrib/tzdata parent directory does not exist. It is a minor problem with freebsd-update where it gets confused the odd time a new file has to be added in a security update. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: freebsd-update install failed
Allan Jude wrote on 10/24/2014 18:29: Do you have a src tree installed? Obviously not. This error is usually Usually? You've gotta be kidding me. caused by it trying to install the update to an empty src tree, so the contrib/tzdata parent directory does not exist. It is a minor problem with freebsd-update where it gets confused the odd time a new file has to be added in a security update. It is a problem with the update package, actually. To update /usr/src, one should use Subversion. Not? If it is the job of freebsd-update to update /usr/src (when it exists), then freebsd-update should also try to apply source code security patches as well, which apparently is not the case. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update install failed
On Fri, 24 Oct 2014 19:23:00 +0200 d...@gmx.com wrote: Allan Jude wrote on 10/24/2014 18:29: Do you have a src tree installed? Obviously not. It's not at all obvious. caused by it trying to install the update to an empty src tree, so the contrib/tzdata parent directory does not exist. It is a minor problem with freebsd-update where it gets confused the odd time a new file has to be added in a security update. It is a problem with the update package, actually. To update /usr/src, one should use Subversion. Not? If it is the job of freebsd-update to update /usr/src (when it exists), then freebsd-update should also try to apply source code security patches as well, which apparently is not the case. freebsd-update can update /usr/src, it depends how it's set-up in freebsd-update.conf ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
freebsd-update install failed
Do what (is it safe to retry the install?)? log: # freebsd-update fetch Looking up update.FreeBSD.org mirrors... 5 mirrors found. Fetching public key from update5.freebsd.org... done. Fetching metadata signature for 10.0-RELEASE from update5.freebsd.org... done. Fetching metadata index... done. Fetching 2 metadata files... done. Inspecting system... done. Preparing to download files... done. Fetching 88 patches.1020304050607080 done. Applying patches... done. Fetching 4 files... done. The following files will be removed as part of updating to 10.0-RELEASE-p11: /usr/share/zoneinfo/Asia/Chongqing /usr/share/zoneinfo/Asia/Harbin /usr/share/zoneinfo/Asia/Kashgar The following files will be added as part of updating to 10.0-RELEASE-p11: /usr/share/zoneinfo/Antarctica/Troll /usr/share/zoneinfo/Asia/Chita /usr/share/zoneinfo/Asia/Srednekolymsk /usr/src/contrib/tzdata/zone1970.tab The following files will be updated as part of updating to 10.0-RELEASE-p11: /bin/freebsd-version /boot/kernel/kernel /boot/kernel/kernel.symbols /rescue/[ [...] /usr/share/zoneinfo/Pacific/Pago_Pago /usr/share/zoneinfo/zone.tab # freebsd-update install Installing updates...install: ///usr/src/contrib/tzdata/zone1970.tab: No such file or directory done. # ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
FREEBSD 10 - Error on Fetch (portsnap or freebsd-update)
Hi. i`m trying to update my FreeBSD 10 Release to Stable, but i`m not getting to fetch on portsnap and freebsd-update look: # portsnap --debug fetch Looking up portsnap.FreeBSD.org mirrors... 7 mirrors found. Fetching snapshot tag from your-org.portsnap.freebsd.org... snapshot.ssl0% of 256 B0 Bps 02m00s fetch: transfer timed out fetch: snapshot.ssl appears to be truncated: 0/256 bytes Error reading input Data invalid snapshot tag. Fetching snapshot tag from isc.portsnap.freebsd.org... snapshot.ssl 100% of 256 B 690 kBps 00m00s done. Fetching snapshot metadata... 009cb897995b7e322bb3b0495ac9a1a01c1ba82280c687 0% of 604 B0 Bps 02m00s fetch: transfer timed out fetch: 009cb897995b7e322bb3b0495ac9a1a01c1ba82280c687b30f84f782f280dc7b appears to be truncated: 0/604 bytes Exit 1 -- Att. Alisson F. Gonçalves Consultoria em BGP/FreeBSD/Redes - Grandes realizações não são feitas por impulso, mas por uma soma de pequenas realizações. (Vincent Van Gogh) E-mail: alissongoncal...@bsd.com.br Celular/Whatsapp: (67) 9694-3243 Skype: alissonx2 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update
Am 2014-01-29 22:51, schrieb Colin Percival: On 01/29/14 12:51, Lars Engels wrote: On Sat, Jan 25, 2014 at 09:11:04AM -0600, Mark Felder wrote: On Sat, Jan 25, 2014, at 5:32, Lars Engels wrote: Also using freebsd-update behind a proxy is really slow. Even with a very fast internet connection (normally download rates ca. 3 MBytes / s) downloading all the tiny binary diff files took more than 8 hours. Maybe freebsd-update's backend could create a tarball of all those diffs and provide this? Even streaming the tar instead of waiting for the freebsd-update server to produce the tarball would be an improvement. I have no experience doing that over a WAN but I don't see why it would be unreliable. Colin, what do you think? Is it possible? Anything is *possible*, but given that the number of patches available is typically at least 10x the number being fetched this doesn't seem like it would be very efficient. FWIW, the performance problems with proxies are limited to HTTP proxies which don't speak HTTP/1.1. Are you sure? I just tried it manually with telnet: # telnet proxyserver 8080 Trying IP Address... Connected to proxyserver. CONNECT www.heise.de:80 HTTP/1.1 Proxy-Authorization:Basic blahblahblahbase64 HTTP/1.1 200 Connection established GET / HTTP/1.1 HTTP/1.1 400 Bad Request IIUC the proxy itself supports HTTP/1.1 but not the webserver behind the proxy? That's the same proxy that takes hours to download the patches with httpget. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update
On Thu, 30 Jan 2014 12:07:26 +0100 Lars Engels wrote: FWIW, the performance problems with proxies are limited to HTTP proxies which don't speak HTTP/1.1. Are you sure? I just tried it manually with telnet: ... IIUC the proxy itself supports HTTP/1.1 but not the webserver behind the proxy? That's the same proxy that takes hours to download the patches with httpget. Proxy support for HTTP/1.1 on the client side doesn't imply that it supports full end-to-end pipelining. The proxy can advertise 1.1 without supporting pipelining. Even if it does that doesn't necessarily imply that it has full end-to-end pipelining. I'm not sure what the current state of squid is, but for years it translated client side HTTP 1.1 pipelining into individual HTTP 1.0 requests on the server side. I don't use freebsd-update myself, but from a quick look at the manpage I think it could benefit by extending the cron command to allow fetching a new release automatically. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update
On Sat, Jan 25, 2014 at 09:11:04AM -0600, Mark Felder wrote: On Sat, Jan 25, 2014, at 5:32, Lars Engels wrote: Also using freebsd-update behind a proxy is really slow. Even with a very fast internet connection (normally download rates ca. 3 MBytes / s) downloading all the tiny binary diff files took more than 8 hours. Maybe freebsd-update's backend could create a tarball of all those diffs and provide this? Even streaming the tar instead of waiting for the freebsd-update server to produce the tarball would be an improvement. I have no experience doing that over a WAN but I don't see why it would be unreliable. Colin, what do you think? Is it possible? pgpcfAO3phOfE.pgp Description: PGP signature
Re: freebsd-update
On 01/29/14 12:51, Lars Engels wrote: On Sat, Jan 25, 2014 at 09:11:04AM -0600, Mark Felder wrote: On Sat, Jan 25, 2014, at 5:32, Lars Engels wrote: Also using freebsd-update behind a proxy is really slow. Even with a very fast internet connection (normally download rates ca. 3 MBytes / s) downloading all the tiny binary diff files took more than 8 hours. Maybe freebsd-update's backend could create a tarball of all those diffs and provide this? Even streaming the tar instead of waiting for the freebsd-update server to produce the tarball would be an improvement. I have no experience doing that over a WAN but I don't see why it would be unreliable. Colin, what do you think? Is it possible? Anything is *possible*, but given that the number of patches available is typically at least 10x the number being fetched this doesn't seem like it would be very efficient. FWIW, the performance problems with proxies are limited to HTTP proxies which don't speak HTTP/1.1. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update
On 29 January 2014 13:51, Colin Percival cperc...@freebsd.org wrote: On 01/29/14 12:51, Lars Engels wrote: On Sat, Jan 25, 2014 at 09:11:04AM -0600, Mark Felder wrote: On Sat, Jan 25, 2014, at 5:32, Lars Engels wrote: Also using freebsd-update behind a proxy is really slow. Even with a very fast internet connection (normally download rates ca. 3 MBytes / s) downloading all the tiny binary diff files took more than 8 hours. Maybe freebsd-update's backend could create a tarball of all those diffs and provide this? Even streaming the tar instead of waiting for the freebsd-update server to produce the tarball would be an improvement. I have no experience doing that over a WAN but I don't see why it would be unreliable. Colin, what do you think? Is it possible? Anything is *possible*, but given that the number of patches available is typically at least 10x the number being fetched this doesn't seem like it would be very efficient. FWIW, the performance problems with proxies are limited to HTTP proxies which don't speak HTTP/1.1. Did you / others ever actually benchmark this? I know that Squid supports pipelined requests but only a handful (defaulting to 1) at a time, as the actual error semantics for HTTP/1.1 pipelining wasn't well defined. So flipping it around - which intermediaries that are actually in use by companies and such actually support pipelining at the level that you're doing it? -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update
On 01/29/14 14:26, Adrian Chadd wrote: On 29 January 2014 13:51, Colin Percival cperc...@freebsd.org wrote: FWIW, the performance problems with proxies are limited to HTTP proxies which don't speak HTTP/1.1. Did you / others ever actually benchmark this? The fact that performance sucks when proxies break HTTP pipelining? Yes, but it's also implied by the RTT/request limit for non-pipelined requests. I know that Squid supports pipelined requests but only a handful (defaulting to 1) at a time, as the actual error semantics for HTTP/1.1 pipelining wasn't well defined. I'm not sure what the poorly defined error semantics are, but I suppose that doesn't matter. Does Squid now reply with HTTP/1.1 headers? The phttpget code won't even try to pipeline requests unless it sees that -- as required by the HTTP specification. So flipping it around - which intermediaries that are actually in use by companies and such actually support pipelining at the level that you're doing it? I don't know. People usually don't tell me when things work. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update
Am 25.01.2014 um 16:11 schrieb Mark Felder f...@freebsd.org: On Sat, Jan 25, 2014, at 5:32, Lars Engels wrote: Also using freebsd-update behind a proxy is really slow. Even with a very fast internet connection (normally download rates ca. 3 MBytes / s) downloading all the tiny binary diff files took more than 8 hours. Maybe freebsd-update's backend could create a tarball of all those diffs and provide this? Even streaming the tar instead of waiting for the freebsd-update server to produce the tarball would be an improvement. I have no experience doing that over a WAN but I don't see why it would be unreliable. Apropos proxy: freebsd-update does not work behind a proxy that requires authentication. At least not with our proxy (which is a Sophos/Astaro „threat management appliance). That’s OK for me, because I can talk the proxy-guys here into making an exception for my FreeBSD-servers - but It’s really a nuisance because everything else (that uses libfetch) can use proxy-authentication. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update
On Jan 29, 2014, at 12:51 PM, Lars Engels lars.eng...@0x20.net wrote: On Sat, Jan 25, 2014 at 09:11:04AM -0600, Mark Felder wrote: On Sat, Jan 25, 2014, at 5:32, Lars Engels wrote: Also using freebsd-update behind a proxy is really slow. Even with a very fast internet connection (normally download rates ca. 3 MBytes / s) downloading all the tiny binary diff files took more than 8 hours. Maybe freebsd-update's backend could create a tarball of all those diffs and provide this? Even streaming the tar instead of waiting for the freebsd-update server to produce the tarball would be an improvement. I have no experience doing that over a WAN but I don't see why it would be unreliable. I implemented an export capability for $WORK last year that built and streamed a Zip archive on the fly. It worked rather well even when the archives were multiple gigabytes with tens of thousands of entries. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update
On Fri, Jan 24, 2014 at 02:40:44PM -0500, Allan Jude wrote: On 2014-01-21 15:42, Kevin Oberman wrote: On Tue, Jan 21, 2014 at 8:49 AM, John Baldwin j...@freebsd.org wrote: On Tuesday, January 21, 2014 10:46:37 am David Chisnall wrote: On 21 Jan 2014, at 07:13, Antonio Olivares olivares14...@gmail.com wrote: On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras ivo...@freebsd.org wrote: Hi, Is there any way I can avoid manually resolving hundreds of merge conflicts of the following type while using freebsd-update ? 1 current version 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 3 === 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 5 10.0-RELEASE ? I can't be the only one seeing those...? Yes, One has to manually go one by one to fix these :( I tried at one point a sed command like sed -i '' to fix these, but it did not work correctly. I see errrors when booting when I don't correct these :( I thought this was fixed already (I didn't see these in the 9.2-10-RC3 upgrade). Doesn't freebsd-update pass -F (If the files differ only by VCS Id ($FreeBSD) install the new file) to mergemaster? AFAIK it doesn't use mergemaster? I thought it used its own tool? I really want to figure out a way to let it use etcupdate instead since it handles this case even for locally modified files cleanly. Having just gone through this on a 10.0-rc5 to 10.0-RELEASE run, I can assure you that it is not completely fixed. One huge part is fixed... every file's ID line is no longer is changed on every release. OTOH, for files that are modified, thy still show up. It hit many of the sendmail .cf files. Annoying as I don't even use sendmail. Not sure if there was a good reason Colin re-invented the wheel on this. It does not use mergemaster or even a reasonable differences editor such as the one mergemaster uses. Just going to the mergemaster code for handling diffs would be a HUGE win. I am getting really tired of /CR3dddwnddn. I discussed this a bit with Colin on Wednesday during our interview with him for BSDNow.tv He had some problems with mergemaster so wrote his own tool. In 10 it ignores the $Id tags, but there are still other changes that have to either be merged or the file replaced with the new one. I am all for further improvement here. Also using freebsd-update behind a proxy is really slow. Even with a very fast internet connection (normally download rates ca. 3 MBytes / s) downloading all the tiny binary diff files took more than 8 hours. Maybe freebsd-update's backend could create a tarball of all those diffs and provide this? pgpIndNjzE60b.pgp Description: PGP signature
Re: freebsd-update
On Sat, Jan 25, 2014, at 5:32, Lars Engels wrote: Also using freebsd-update behind a proxy is really slow. Even with a very fast internet connection (normally download rates ca. 3 MBytes / s) downloading all the tiny binary diff files took more than 8 hours. Maybe freebsd-update's backend could create a tarball of all those diffs and provide this? Even streaming the tar instead of waiting for the freebsd-update server to produce the tarball would be an improvement. I have no experience doing that over a WAN but I don't see why it would be unreliable. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update
I agree with the rest of this thread. This is just awful. I'm basically forced to do source based updates when jumping major versions because freebsd-update is a nightmare to use. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update
On 2014-01-21 15:42, Kevin Oberman wrote: On Tue, Jan 21, 2014 at 8:49 AM, John Baldwin j...@freebsd.org wrote: On Tuesday, January 21, 2014 10:46:37 am David Chisnall wrote: On 21 Jan 2014, at 07:13, Antonio Olivares olivares14...@gmail.com wrote: On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras ivo...@freebsd.org wrote: Hi, Is there any way I can avoid manually resolving hundreds of merge conflicts of the following type while using freebsd-update ? 1 current version 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 3 === 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 5 10.0-RELEASE ? I can't be the only one seeing those...? Yes, One has to manually go one by one to fix these :( I tried at one point a sed command like sed -i '' to fix these, but it did not work correctly. I see errrors when booting when I don't correct these :( I thought this was fixed already (I didn't see these in the 9.2-10-RC3 upgrade). Doesn't freebsd-update pass -F (If the files differ only by VCS Id ($FreeBSD) install the new file) to mergemaster? AFAIK it doesn't use mergemaster? I thought it used its own tool? I really want to figure out a way to let it use etcupdate instead since it handles this case even for locally modified files cleanly. Having just gone through this on a 10.0-rc5 to 10.0-RELEASE run, I can assure you that it is not completely fixed. One huge part is fixed... every file's ID line is no longer is changed on every release. OTOH, for files that are modified, thy still show up. It hit many of the sendmail .cf files. Annoying as I don't even use sendmail. Not sure if there was a good reason Colin re-invented the wheel on this. It does not use mergemaster or even a reasonable differences editor such as the one mergemaster uses. Just going to the mergemaster code for handling diffs would be a HUGE win. I am getting really tired of /CR3dddwnddn. I discussed this a bit with Colin on Wednesday during our interview with him for BSDNow.tv He had some problems with mergemaster so wrote his own tool. In 10 it ignores the $Id tags, but there are still other changes that have to either be merged or the file replaced with the new one. I am all for further improvement here. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: freebsd-update
On 2014-01-24 20:31, Mark Felder wrote: I agree with the rest of this thread. This is just awful. I'm basically forced to do source based updates when jumping major versions because freebsd-update is a nightmare to use. Not tested, but maybe this works. a) use etcmerge before freebsd-upgrade and exclude /etc in freebsd-update.conf b) manually extract the sources, then use mergemaster and then run freebsd-update c) if you have more then one system fix once freebsd-update and deploy the script to the rest of the systems I use myself a mix of mergemaster and upgrade via the (kernel|src|man|...).txz and base.txz (exclude ^./etc). Going this way since 6.x and also major upgrades 6.x-7.x-8.x ... main issue on older systems is the space required by the kernel symbols. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update
On 1/24/2014 11:31 AM, Mark Felder wrote: I agree with the rest of this thread. This is just awful. I'm basically forced to do source based updates when jumping major versions because freebsd-update is a nightmare to use. I've yet to go through a freebsd-update process that didn't require a manual clean-up afterward. It's easier (and faster) to build an obj tree on my desktop, ship it to my servers via NFS over a tunnel. Another scenario I've run into more than once: - Install release m.x - Realize there's a kernel/driver bug, fixed in m-stable - Source upgrade to m-stable - Release m.z happens, contains fix - Freebsd-update upgrade to m.z The updater will discover that all of /etc differs by $Id tag. A few will have non-edit differences. The rest are either default-empty files or files not found in the distribution (pf.conf, sshd keys, etc.). Freebsd-update will force me to manually approve every single change. With mergemaster, automatic upgrade takes care of all but the edits and provides a MUCH nicer diff editor for those. Mergemaster is a 1 minute process, even on I/O-constrained hardware. I understand that when freebsd-update was written there were some problems with the existing install/merge tools used for source upgrades; but I have to wonder: what issues could be so bad that the above is the lesser evil? Freebsd-update's merge needs to learn what mergemaster's can do. Until then, freebsd-update is a non-starter, IMO. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
freebsd-update
Hi, Is there any way I can avoid manually resolving hundreds of merge conflicts of the following type while using freebsd-update ? 1 current version 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 3 === 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 5 10.0-RELEASE ? I can't be the only one seeing those...? signature.asc Description: OpenPGP digital signature
Re: freebsd-update
On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras ivo...@freebsd.org wrote: Hi, Is there any way I can avoid manually resolving hundreds of merge conflicts of the following type while using freebsd-update ? 1 current version 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 3 === 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 5 10.0-RELEASE ? I can't be the only one seeing those...? Yes, One has to manually go one by one to fix these :( I tried at one point a sed command like sed -i '' to fix these, but it did not work correctly. I see errrors when booting when I don't correct these :( Hopefully someone suggests something better, but yes I do see these as well :( Best Regards, Antonio ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update
On 21 Jan 2014, at 07:13, Antonio Olivares olivares14...@gmail.com wrote: On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras ivo...@freebsd.org wrote: Hi, Is there any way I can avoid manually resolving hundreds of merge conflicts of the following type while using freebsd-update ? 1 current version 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 3 === 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 5 10.0-RELEASE ? I can't be the only one seeing those...? Yes, One has to manually go one by one to fix these :( I tried at one point a sed command like sed -i '' to fix these, but it did not work correctly. I see errrors when booting when I don't correct these :( I thought this was fixed already (I didn't see these in the 9.2-10-RC3 upgrade). Doesn't freebsd-update pass -F (If the files differ only by VCS Id ($FreeBSD) install the new file) to mergemaster? David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update
On Tuesday, January 21, 2014 10:46:37 am David Chisnall wrote: On 21 Jan 2014, at 07:13, Antonio Olivares olivares14...@gmail.com wrote: On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras ivo...@freebsd.org wrote: Hi, Is there any way I can avoid manually resolving hundreds of merge conflicts of the following type while using freebsd-update ? 1 current version 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 3 === 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 5 10.0-RELEASE ? I can't be the only one seeing those...? Yes, One has to manually go one by one to fix these :( I tried at one point a sed command like sed -i '' to fix these, but it did not work correctly. I see errrors when booting when I don't correct these :( I thought this was fixed already (I didn't see these in the 9.2-10-RC3 upgrade). Doesn't freebsd-update pass -F (If the files differ only by VCS Id ($FreeBSD) install the new file) to mergemaster? AFAIK it doesn't use mergemaster? I thought it used its own tool? I really want to figure out a way to let it use etcupdate instead since it handles this case even for locally modified files cleanly. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update
On Tue, Jan 21, 2014 at 8:49 AM, John Baldwin j...@freebsd.org wrote: On Tuesday, January 21, 2014 10:46:37 am David Chisnall wrote: On 21 Jan 2014, at 07:13, Antonio Olivares olivares14...@gmail.com wrote: On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras ivo...@freebsd.org wrote: Hi, Is there any way I can avoid manually resolving hundreds of merge conflicts of the following type while using freebsd-update ? 1 current version 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 3 === 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z peter $ 5 10.0-RELEASE ? I can't be the only one seeing those...? Yes, One has to manually go one by one to fix these :( I tried at one point a sed command like sed -i '' to fix these, but it did not work correctly. I see errrors when booting when I don't correct these :( I thought this was fixed already (I didn't see these in the 9.2-10-RC3 upgrade). Doesn't freebsd-update pass -F (If the files differ only by VCS Id ($FreeBSD) install the new file) to mergemaster? AFAIK it doesn't use mergemaster? I thought it used its own tool? I really want to figure out a way to let it use etcupdate instead since it handles this case even for locally modified files cleanly. Having just gone through this on a 10.0-rc5 to 10.0-RELEASE run, I can assure you that it is not completely fixed. One huge part is fixed... every file's ID line is no longer is changed on every release. OTOH, for files that are modified, thy still show up. It hit many of the sendmail .cf files. Annoying as I don't even use sendmail. Not sure if there was a good reason Colin re-invented the wheel on this. It does not use mergemaster or even a reasonable differences editor such as the one mergemaster uses. Just going to the mergemaster code for handling diffs would be a HUGE win. I am getting really tired of /CR3dddwnddn. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
freebsd-update not checking disk space?
Hi, I tried to upgrade a server at work from 8.2-RELEASE-i386 to 9.0-RC1-i386 using freebsd-update.When running 'freebsd-update install' to install the new kernel, but that failed because there was insufficient disk space. This resulted in freebsd-update thinking everything is ok but left the kernel unbootable. From the screen capture: 10G# freebsd-update install Installing updates... /: write failed, filesystem is full install: ///boot/kernel/INS@SmmC: No space left on device install: ///boot/kernel/INS@lMJN: No space left on device install: ///boot/kernel/INS@ez1L: No space left on device install: ///boot/kernel/INS@D78d: No space left on device [... more patch files ..] install: ///boot/kernel/ng_bt3c.ko.symbols: No space left on device install: ///boot/kernel/ng_btsocket.ko: No space left on device [.. more destination files ..] These two types of messages are interleaved. It ends with: install: ///boot/INS@yqYd: No space left on device rmdir: ///boot/kernel: Directory not empty Kernel updates have been installed. Please reboot and run /usr/sbin/freebsd-update install again to finish installing updates. 10G# df Filesystem 1K-blocksUsed Avail Capacity Mounted on /dev/ad0s1a507630 502860-35840 108%/ So in reality the update never finished properly. More logs on request. Regards, René -- http://www.rene-ladan.nl/ GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: freebsd-update not checking disk space?
On 10/25/11 00:52, René Ladan wrote: I tried to upgrade a server at work from 8.2-RELEASE-i386 to 9.0-RC1-i386 using freebsd-update.When running 'freebsd-update install' to install the new kernel, but that failed because there was insufficient disk space. This resulted in freebsd-update thinking everything is ok but left the kernel unbootable. Yes, this is a known issue in freebsd-update -- it needs to be much smarter about detecting and handling errors. Unfortunately I haven't had time to deal with this (and it's a lot of work). -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
