Question: /usr/sbin/pkg vs /usr/local/sbin/pkg in 9.1
Hi, as I see it, pkgng is actually included in 9.1 as /usr/sbin/pkg, right? But when I define WITH_PKGNG=yes in /etc/make.conf the ports-system wants to install the pkgng-package (because it looks for pkgng in /usr/local/sbin). Is there a way to say "I have the pkg tool in base already"? Or is the pkg in base supposed to just install the pkgng from ports? Best Regards, Rainer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD 9.1-PRERELEASE
Hi, In this mailinglist I'm reading a lot about problems (re)compiling the system. At this moment I'm running: "FreeBSD 9.1-PRERELEASE (ORAC) #0 r244047: Sun Dec 9 15:33:19 CET 2012" without problems. Is it save to recompile the system with all patches? Thanks Jack Raats ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Question: /usr/sbin/pkg vs /usr/local/sbin/pkg in 9.1
On 27/12/2012 09:44, Rainer Duffner wrote: > as I see it, pkgng is actually included in 9.1 as /usr/sbin/pkg, right? /usr/sbin/pkg and /usr/local/sbin/pkg are very different. /usr/local/sbin/pkg is a binary package management system. /usr/sbin/pkg is a shim that can bootstrap the installation of /usr/local/sbin/pkg if it is not already installed, or that invokes /usr/local/sbin/pkg preserving the rest of the command line otherwise. > Is there a way to say "I have the pkg tool in base already"? pkgng is not in base and there are no plans to import it. If you are going to use pkgng then you need to install it, either from ports or by using the /usr/sbin/pkg shim to install from a pkgng package. > Or is the pkg in base supposed to just install the pkgng from ports? Indirectly. /usr/sbin/pkg installs from a pre-compiled tarball, which is generated from the ports-mgmt/pkg port. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: Question: /usr/sbin/pkg vs /usr/local/sbin/pkg in 9.1
On 27/12/2012 11:02, Matthew Seaman wrote: On 27/12/2012 09:44, Rainer Duffner wrote: as I see it, pkgng is actually included in 9.1 as /usr/sbin/pkg, right? /usr/sbin/pkg and /usr/local/sbin/pkg are very different. /usr/local/sbin/pkg is a binary package management system. /usr/sbin/pkg is a shim that can bootstrap the installation of /usr/local/sbin/pkg if it is not already installed, or that invokes /usr/local/sbin/pkg preserving the rest of the command line otherwise. Is there a way to say "I have the pkg tool in base already"? pkgng is not in base and there are no plans to import it. If you are going to use pkgng then you need to install it, either from ports or by using the /usr/sbin/pkg shim to install from a pkgng package. Why there is no plan to import it? Or is the pkg in base supposed to just install the pkgng from ports? Indirectly. /usr/sbin/pkg installs from a pre-compiled tarball, which is generated from the ports-mgmt/pkg port. Cheers, Matthew Cheers, David ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Question: /usr/sbin/pkg vs /usr/local/sbin/pkg in 9.1
On 2012-12-27 11:35, David Demelier wrote: On 27/12/2012 11:02, Matthew Seaman wrote: ... pkgng is not in base and there are no plans to import it. If you are going to use pkgng then you need to install it, either from ports or by using the /usr/sbin/pkg shim to install from a pkgng package. Why there is no plan to import it? Because pkgng is developed independently from the base system. As soon as you put a copy of it in base, it is no longer independent. :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
9.1-RC3: xorg-input-mouse, xfce4-panel
Hello :-) I have found some issues with 9.1-RC3 packages/configuration using binary packages: 1. xorg-input-mouse is old driver (?) that has the issue mentioned on the list (current?) - the mouse is not always detected at first xorg run. Please make sure 9.1-RELEASE use new mouse driver that has this issue fixed (?) and/or update default configuration to use AllowEmptyInput properly (Off). 2. I have some issues with xfce4-panel there seems to be more than one running, the panel is in configuration state at startup, sometimes a popup is displayed (about xfce4-panel) that stops the further running of the xfce4, when this popup is displayed on another monitor (in multi display configuration) this makes xfce4 startup delayed... This happens in default xfce4 configuration, when I remove all of the configuration, on a working configuration, etc. Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FS hang with suspfs when creating snapshot on a UFS + GJOURNAL setup
On a FreeBSD 8-Stable machine with UFS + GJOURNAL (no SU) I observed the same behaviour as described for UFS+SU+J in lists.freebsd.org/pipermail/freebsd-current/2012-January/030937.html. The snapshot was initiated by amanda with dump 3ubLshf 64 1048576 0 - /dev/mirror/gm0p10.journal (pid 50347) and the process creating the snapshot is /sbin/mksnap_ffs /home /home/.snap/dump_snapshot (pid 50350). The process 50350 hangs and also all following processes that tried to access the home partition, some of them work, but don't come to an end, e.g. a shell after (Ctrl T): load: 0.61 cmd: sh 52670 [suspfs] 43.46r 0.00u 0.00s 0% 2272k. All write I/O's to all gjournaled partitions are stopped. Under normal circumstances the snapshot is taken in five seconds, so I have definitiv not the problem I have described in lists.freebsd.org/pipermail/freebsd-geom/2012-May/005246.html. My system disk with root,var,usr and home is completely mirrored and gjournaled with journals in extra partitions: gpart show mirror/gm0 --> => 34 286749420 mirror/gm0 GPT (136G) 34128 1 freebsd-boot (64k) 1628601600 2 freebsd-swap (4.1G) 86017622097152 3 freebsd-swap (1.0G) 106989144194304 4 freebsd-swap (2.0G) 148932184194304 5 freebsd-swap (2.0G) 190875224194304 6 freebsd-swap (2.0G) 232818262097152 7 freebsd-ufs (1.0G) 253789788388608 8 freebsd-ufs (4.0G) 33767586 67108864 9 freebsd-ufs (32G) 100876450 185873004 10 freebsd-ufs (88G) df -h -t ufs --> FilesystemSizeUsed Avail Capacity Mounted on /dev/mirror/gm0p7.journal 989M313M596M34%/ /dev/mirror/gm0p8.journal 3.9G2.2G1.4G61%/var /dev/mirror/gm0p9.journal 31G8.6G 19G30%/usr /dev/mirror/gm0p10.journal 85G 17G 62G22%/home gmirror status --> NameStatus Components mirror/gm0 COMPLETE da6 (ACTIVE) da7 (ACTIVE) gjournal status --> Name Status Components mirror/gm0p7.journal N/A mirror/gm0p3 mirror/gm0p7 mirror/gm0p8.journal N/A mirror/gm0p4 mirror/gm0p8 mirror/gm0p9.journal N/A mirror/gm0p5 mirror/gm0p9 mirror/gm0p10.journal N/A mirror/gm0p6 mirror/gm0p10 I got some information from the hanging system with DDB: KDB: enter: Break to debugger [thread pid 11 tid 14 ] Stopped at kdb_enter+0x3b: movq$0,0x483332(%rip) db> show pcpu cpuid= 2 dynamic pcpu = 0xff807f7d0080 curthread= 0xff000235c000: pid 11 "idle: cpu2" curpcb = 0xff851d00 fpcurthread = none idlethread = 0xff000235c000: tid 14 "idle: cpu2" curpmap = 0x80889170 tssp = 0x808f65d0 commontssp = 0x808f65d0 rsp0 = 0xff851d00 gs32p= 0x808f5408 ldt = 0x808f5448 tss = 0x808f5438 db> show allpcpu Current CPU: 2 cpuid= 0 dynamic pcpu = 0x449080 curthread= 0xff0002368470: pid 11 "idle: cpu0" curpcb = 0xff85bd00 fpcurthread = none idlethread = 0xff0002368470: tid 16 "idle: cpu0" curpmap = 0x80889170 tssp = 0x808f6500 commontssp = 0x808f6500 rsp0 = 0xff85bd00 gs32p= 0x808f5338 ldt = 0x808f5378 tss = 0x808f5368 cpuid= 1 dynamic pcpu = 0xff807f7c9080 curthread= 0xff00023688e0: pid 11 "idle: cpu1" curpcb = 0xff856d00 fpcurthread = none idlethread = 0xff00023688e0: tid 15 "idle: cpu1" curpmap = 0x80889170 tssp = 0x808f6568 commontssp = 0x808f6568 rsp0 = 0xff856d00 gs32p= 0x808f53a0 ldt = 0x808f53e0 tss = 0x808f53d0 cpuid= 2 dynamic pcpu = 0xff807f7d0080 curthread= 0xff000235c000: pid 11 "idle: cpu2" curpcb = 0xff851d00 fpcurthread = none idlethread = 0xff000235c000: tid 14 "idle: cpu2" curpmap = 0x80889170 tssp = 0x808f65d0 commontssp = 0x808f65d0 rsp0 = 0xff851d00 gs32p= 0x808f5408 ldt = 0x808f5448 tss = 0x808f5438 cpuid= 3 dynamic pcpu = 0xff807f7d7080 curthread= 0xff000235c470: pid 11 "idle: cpu3" curpcb = 0xff84cd00 fpcurthread = none idlethread = 0xff000235c470: tid 13 "idle: cpu3" curpmap = 0x80889170 tssp = 0x808f6638 commontssp = 0x808f6638 rsp0 = 0xff84cd00 gs32p= 0x808f5470 ldt = 0x808f54b0 ts
Re: Question: /usr/sbin/pkg vs /usr/local/sbin/pkg in 9.1
On 27/12/2012 10:38, Dimitry Andric wrote: > On 2012-12-27 11:35, David Demelier wrote: >> On 27/12/2012 11:02, Matthew Seaman wrote: >>> pkgng is not in base and there are no plans to import it. If you are >>> going to use pkgng then you need to install it, either from ports or by >>> using the /usr/sbin/pkg shim to install from a pkgng package. >> Why there is no plan to import it? > Because pkgng is developed independently from the base system. As soon > as you put a copy of it in base, it is no longer independent. :-) Which somewhat begs the question as to why pkgng is developed independently of the base system. That is for entirely pragmatic reasons: there are rules about what you can change in the lifetime of a FreeBSD major or minor release. Which for a project of the scope of pkgng would basically mean taking many years to develop and adopt it. This is one of the sticking points that has effectively stymied development of pkg_tools over the years. By keeping pkgng out of the base we get: * Exactly the same version of pkgng for all current versions of FreeBSD -- which is important, as it means port maintainers can generally rely on solving problems one time for all versions. * The ability to develop pkgng at as rapid a pace as we can maintain. -- there is still a large amount of new functionality yet to be introduced, particularly the dependency solver, which will be quite revolutionary when it comes in. * Related to the above, we have been able to arbitrarily declare that the libpkg.so API will not be stabilized until pkg-2.0 is released. -- again, purely pragmatic and to enable as rapid development as possible. Despite this, we anticipate that there are changes to pkgng and pkgng-related changes to the ports which we won't be able to introduce until around April 2014 and the EoL of 8.3-RELEASE, which will be the last pre-pkgng release to go and hence the earliest date at which pkg_tools support can be entirely ceased. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: FreeBSD 9.1-PRERELEASE
[-questions@, as I'm not subscribed to it, and I don't see value in
cross-posting this message -- dhw]
On Thu, Dec 27, 2012 at 10:53:23AM +0100, Jack Raats wrote:
> Hi,
>
> In this mailinglist I'm reading a lot about problems (re)compiling the system.
Well, I suspect that even if a small number of those of us who rebuild
the system without problems were to post each time we did so, there
would be a fair number of complaints from all of the noise. :-}
> At this moment I'm running:
> "FreeBSD 9.1-PRERELEASE (ORAC) #0 r244047: Sun Dec 9 15:33:19 CET 2012"
> without problems.
Good.
> Is it save to recompile the system with all patches?
> ...
OK; now I'm a bit confused.
The version string you cite ("FreeBSD 9.1-PRERELEASE (ORAC) #0 r244047")
indicates that you have no modifications to the source tree -- so I'm
unclear on what "patches" you are referencing.
I have been tracking the stable/9 branch of FreeBSD (updating &
rebuilding daily) on my laptop, then using it for my day-to-day
activities. I have had very few problems with stable/9 -- I think there
may have been as many as 3 times that I had trouble rebuilding since
May.
For reference, the most recent "uname -a" outputs for me are:
FreeBSD g1-227.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #329
r244676M/244676: Tue Dec 25 05:04:52 PST 2012
r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386
FreeBSD g1-227.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #330
r244712M/244731: Thu Dec 27 04:24:05 PST 2012
r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386
(Note that while I did rebuild yesterday (Wed 26 Dec), the uname output
was unchanged, as the only changes in the sources was to "userland" (vs.
the kernel).)
Finally, note that stable/9 is a *development* branch of FreeBSD;
as such, it gets updated often; the "safety" of rebuilding is
difficult to estimate absent knowledge of both your environment and
the point to which you are considering updating. The developers
try to avoid breaking things (and that avoidance is much eaasier
with SVN, vs. CVS (IMO)), but software development is fundamentally
a human activity, and mistakes do happen from time to time.
If that's a concern, I suggest that you try such an update on a system
that is less critical than most, but which you are able to subject to
significant testing. If that works for you, you might consider upgrading
somewhat more-critical systems to the same point.
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Taliban: Evil men with guns afraid of truth from a 14-year old girl.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
pgpSXEYkvWbzV.pgp
Description: PGP signature
Re: FS hang with suspfs when creating snapshot on a UFS + GJOURNAL setup
On Thu, Dec 27, 2012 at 12:28:54PM +0100, Andreas Longwitz wrote: > On a FreeBSD 8-Stable machine with UFS + GJOURNAL (no SU) I observed the > same behaviour as described for UFS+SU+J in > lists.freebsd.org/pipermail/freebsd-current/2012-January/030937.html. > > The snapshot was initiated by amanda with > dump 3ubLshf 64 1048576 0 - /dev/mirror/gm0p10.journal (pid 50347) > and the process creating the snapshot is > /sbin/mksnap_ffs /home /home/.snap/dump_snapshot (pid 50350). > > The process 50350 hangs and also all following processes that tried to > access the home partition, some of them work, but don't come to an end, > e.g. a shell after (Ctrl T): > load: 0.61 cmd: sh 52670 [suspfs] 43.46r 0.00u 0.00s 0% 2272k. > > All write I/O's to all gjournaled partitions are stopped. Under normal > circumstances the snapshot is taken in five seconds, so I have definitiv > not the problem I have described in > lists.freebsd.org/pipermail/freebsd-geom/2012-May/005246.html. > > My system disk with root,var,usr and home is completely mirrored and > gjournaled with journals in extra partitions: > gpart show mirror/gm0 --> > => 34 286749420 mirror/gm0 GPT (136G) > 34128 1 freebsd-boot (64k) > 1628601600 2 freebsd-swap (4.1G) > 86017622097152 3 freebsd-swap (1.0G) >106989144194304 4 freebsd-swap (2.0G) >148932184194304 5 freebsd-swap (2.0G) >190875224194304 6 freebsd-swap (2.0G) >232818262097152 7 freebsd-ufs (1.0G) >253789788388608 8 freebsd-ufs (4.0G) >33767586 67108864 9 freebsd-ufs (32G) > 100876450 185873004 10 freebsd-ufs (88G) > df -h -t ufs --> > FilesystemSizeUsed Avail Capacity Mounted on > /dev/mirror/gm0p7.journal 989M313M596M34%/ > /dev/mirror/gm0p8.journal 3.9G2.2G1.4G61%/var > /dev/mirror/gm0p9.journal 31G8.6G 19G30%/usr > /dev/mirror/gm0p10.journal 85G 17G 62G22%/home > gmirror status --> > NameStatus Components > mirror/gm0 COMPLETE da6 (ACTIVE) > da7 (ACTIVE) > gjournal status --> > Name Status Components > mirror/gm0p7.journal N/A mirror/gm0p3 >mirror/gm0p7 > mirror/gm0p8.journal N/A mirror/gm0p4 >mirror/gm0p8 > mirror/gm0p9.journal N/A mirror/gm0p5 >mirror/gm0p9 > mirror/gm0p10.journal N/A mirror/gm0p6 >mirror/gm0p10 > > I got some information from the hanging system with DDB: > KDB: enter: Break to debugger > [thread pid 11 tid 14 ] > Stopped at kdb_enter+0x3b: movq$0,0x483332(%rip) > db> show pcpu > cpuid= 2 > dynamic pcpu = 0xff807f7d0080 > curthread= 0xff000235c000: pid 11 "idle: cpu2" > curpcb = 0xff851d00 > fpcurthread = none > idlethread = 0xff000235c000: tid 14 "idle: cpu2" > curpmap = 0x80889170 > tssp = 0x808f65d0 > commontssp = 0x808f65d0 > rsp0 = 0xff851d00 > gs32p= 0x808f5408 > ldt = 0x808f5448 > tss = 0x808f5438 > db> show allpcpu > Current CPU: 2 > > cpuid= 0 > dynamic pcpu = 0x449080 > curthread= 0xff0002368470: pid 11 "idle: cpu0" > curpcb = 0xff85bd00 > fpcurthread = none > idlethread = 0xff0002368470: tid 16 "idle: cpu0" > curpmap = 0x80889170 > tssp = 0x808f6500 > commontssp = 0x808f6500 > rsp0 = 0xff85bd00 > gs32p= 0x808f5338 > ldt = 0x808f5378 > tss = 0x808f5368 > > cpuid= 1 > dynamic pcpu = 0xff807f7c9080 > curthread= 0xff00023688e0: pid 11 "idle: cpu1" > curpcb = 0xff856d00 > fpcurthread = none > idlethread = 0xff00023688e0: tid 15 "idle: cpu1" > curpmap = 0x80889170 > tssp = 0x808f6568 > commontssp = 0x808f6568 > rsp0 = 0xff856d00 > gs32p= 0x808f53a0 > ldt = 0x808f53e0 > tss = 0x808f53d0 > > cpuid= 2 > dynamic pcpu = 0xff807f7d0080 > curthread= 0xff000235c000: pid 11 "idle: cpu2" > curpcb = 0xff851d00 > fpcurthread = none > idlethread = 0xff000235c000: tid 14 "idle: cpu2" > curpmap = 0x80889170 > tssp = 0x808f65d0 > commontssp = 0x808f65d0 > rsp0 = 0xff851d00 > gs32p= 0x808f5408 > ldt = 0x808f5448 > tss = 0x808f5438 > > cpuid= 3 > dynamic pcpu = 0xff807f7d7080 > curthread= 0xff000235c470: pid 11 "idle: cpu3" > curpcb
Re: FreeBSD 9.1-PRERELEASE
On Thu, Dec 27, 2012 at 11:53 AM, Jack Raats wrote: > Hi, > > In this mailinglist I'm reading a lot about problems (re)compiling the > system. At this moment I'm running: > "FreeBSD 9.1-PRERELEASE (ORAC) #0 r244047: Sun Dec 9 15:33:19 CET 2012" > without problems. > > Is it save to recompile the system with all patches? > > Thanks > Jack Raats > ___ You're seeing just the "tip of the iceberg" meaning only those who do have problems building the OS from sources and are following the mailing lists post on them. There's potentially thousands or even much more of those who are following 9-STABLE and never encounter a problem they can not solve on their own. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1-RC3: xorg-input-mouse, xfce4-panel
On Thu, 27 Dec 2012, CeDeROM wrote: Hello :-) I have found some issues with 9.1-RC3 packages/configuration using binary packages: 1. xorg-input-mouse is old driver (?) that has the issue mentioned on the list (current?) - the mouse is not always detected at first xorg run. Please make sure 9.1-RELEASE use new mouse driver that has this issue fixed (?) and/or update default configuration to use AllowEmptyInput properly (Off). Use AutoAddDevices Off instead. AEI is prone to problems. http://www.wonkity.com/~wblock/docs/html/aei.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RE: nullfs changes MFC
> -Original Message- > From: owner-freebsd-sta...@freebsd.org > [mailto:owner-freebsd-sta...@freebsd.org] On Behalf Of > Konstantin Belousov > Sent: Saturday, 8 December 2012 12:01 PM > To: f...@freebsd.org > Cc: sta...@freebsd.org > Subject: nullfs changes MFC > > Hi, > I am going to merge latest batch of the nullfs improvements > into stable/9. This will bring up significant performance > enchancements due to use of the shared locks for lookups if > the lower layer supports it, much better caching on the > nullfs layer, and proper handling of the text segments on the > nullfs. Also, it should improve the error recovery and some > corner cases with locking. > > Unfortunately, the merge would break KBI for VFS, since it > needs 5 new VOP slots, and only three spares are left. We > already are very liberal with the VFS KBI, so I do not feel > that the merge is not acceptable, due to the benefits it > brings to the nullfs. > > The merge is available at > http://people.freebsd.org/~kib/misc/nullfs_9.1.patch > Konstantin, Thank-you for these improvements. I've been running this patchset on test and build servers for a few weeks and the systems remained stable and reliable. On some fairly complex jail and nullfs environments there has been an improvement in the order of 3 to 8% for large sequential writes. Regards, Dewayne PS I've reversed out the patches now they've migrated to RELENG_9 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1-RC3: xorg-input-mouse, xfce4-panel
Hello Warren :-) I did so. I also talked about that problem some time ago. I think 1.7.2 xorg mouse driver has this fix and no manual configuration is necessary. It would be nice to include 1.7.2 in the release packages :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Anothe pkgng question: signing a repository
Hi, I'm creating my own repository and have created a key for it. I've created a CSR for it and used that to generate a certificate via our internal CA. Because there was no other information available, I used the profile that we use to generate SSL-certificates for web servers. I copied the certificate to the server and adjusted pkg.conf, but when I want to query the repository, I get: root@server:/etc/ssl/cert # pkg install net-snmpd Updating repository catalogue repo.txz 100% 219KB 219.5KB/s 219.5KB/s 00:00 pkg: error reading public key(/etc/ssl/pkg.conf): error:0906D06C:PEM routines:PEM_read_bio:no start line pkg: Invalid signature, removing repository. What does pkg expect to be in this file? openssl x509 displays the data for the certificate correctly, so I really don't know what's missing. I ktraced pkg and it is indeed reading the file. Best Regards Rainer ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1-RC3: xorg-input-mouse, xfce4-panel
There is nothing going into "release" what was not in ports tree. (There is no release packages at all, apart from ports that's just happened to be in regular tree at release time. Followed by port tree slush.) xf86-input-mouse-1.8.1 is in dev trunk xorg tree. (see -x11). -- View this message in context: http://freebsd.1045724.n5.nabble.com/9-1-RC3-xorg-input-mouse-xfce4-panel-tp5772549p5772624.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 9.1-PRERELEASE
Is ORAC some kind of patchset? Unless you see flow of tinderbox errors, -STABLE is buildable almost always. -- View this message in context: http://freebsd.1045724.n5.nabble.com/FreeBSD-9-1-PRERELEASE-tp5772515p5772627.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FS hang with suspfs when creating snapshot on a UFS + GJOURNAL setup
Konstantin Belousov wrote: > On Thu, Dec 27, 2012 at 12:28:54PM +0100, Andreas Longwitz wrote: >> On a FreeBSD 8-Stable machine with UFS + GJOURNAL (no SU) I observed the >> same behaviour as described for UFS+SU+J in >> lists.freebsd.org/pipermail/freebsd-current/2012-January/030937.html. >> >> The snapshot was initiated by amanda with >> dump 3ubLshf 64 1048576 0 - /dev/mirror/gm0p10.journal (pid 50347) >> and the process creating the snapshot is >> /sbin/mksnap_ffs /home /home/.snap/dump_snapshot (pid 50350). >> >> The process 50350 hangs and also all following processes that tried to >> access the home partition, some of them work, but don't come to an end, >> e.g. a shell after (Ctrl T): >> load: 0.61 cmd: sh 52670 [suspfs] 43.46r 0.00u 0.00s 0% 2272k. >> >> All write I/O's to all gjournaled partitions are stopped. Under normal >> circumstances the snapshot is taken in five seconds, so I have definitiv >> not the problem I have described in >> lists.freebsd.org/pipermail/freebsd-geom/2012-May/005246.html. >> >> . >> >> It seems there is a deadlock on the suspfs lock, but I could not figure >> out who holds this lock. >> Any hints how to get better diagnostic information for next time the >> error occurs are welcome. > > The > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > provides the instructions. > > The suspfs is owned by the snapshot creator. The question is, where is it > blocked. Thanks for answer. In the meantime I can reproduce the problem and got some more information. It looks that there is a deadlock between the two processes with pid 18 (g_journal switcher) and pid 7126 (/sbin/mksnap_ffs /home /home/.snap/my_snapshot): 018 0 0 45 0 016 snaplk DL??4:40,34 [g_journal switcher] 0 7126 1933 0 50 0 5836 1176 suspfs D ??0:00,44 /sbin/mksnap_ffs /home /home/.snap/my_snapshot procstat -t 18 --> PIDTID COMM TDNAME CPU PRI STATE WCHAN 18 100076 g_journal switcher g_journal switch 0 129 sleep snaplk procstat -t 7126 --> PIDTID COMM TDNAME CPU PRI STATE WCHAN 7126 100157 mksnap_ffs -1 134 sleep suspfs procstat -kk 18 --> PIDTID COMM TDNAME KSTACK 18 100076 g_journal switcher g_journal switch mi_switch+0x186 sleepq_wait+0x42 __lockmgr_args+0x49b ffs_copyonwrite +0x19a ffs_geom_strategy+0x1b5 bufwrite+0xe9 ffs_sbupdate+0x12a g_journal_ufs_clean+0x3e g_journal_switcher+0xe5e fork _exit+0x11f fork_trampoline+0xe procstat -kk 7126 --> PIDTID COMM TDNAME KSTACK 7126 100157 mksnap_ffs -mi_switch+0x186 sleepq_wait+0x42 _sleep+0x373 vn_start_write+0xdf ffs_s napshot+0xe2b ffs_mount+0x65a vfs_donmount+0xdc5 nmount+0x63 amd64_syscall+0x1f4 Xfast_syscall+0xfc >From DDB: db> show lockedvnods Locked vnodes 0xff012281a938: tag ufs, type VREG usecount 1, writecount 0, refcount 3339 mountedhere 0 flags (VV_SYSTEM) lock type snaplk: EXCL by thread 0xff000807a470 (pid 7126) with exclusive waiters pending ino 23552, on dev mirror/gm0p10.journal db> show lockedbufs buf at 0xff81efa73320 b_flags = 0xa020 b_error = 0, b_bufsize = 8192, b_bcount = 8192, b_resid = 0 b_bufobj = (0xff00080564c8), b_data = 0xff81f659e000, b_blkno = 12000, b_dep = 0 b_npages = 2, pages(OBJ, IDX, PA): (0xff000805c000, 0x5dc, 0x4a78000),(0xff000805c000, 0x5dd, 0x4a79000) lock type bufwait: EXCL by thread 0xff0002bd5000 (pid 18) buf at 0xff81f0485070 b_flags = 0x8020 b_error = 0, b_bufsize = 16384, b_bcount = 16384, b_resid = 0 b_bufobj = (0xff012281aa50), b_data = 0xff8207896000, b_blkno = 462144, b_dep = 0 b_npages = 4, pages(OBJ, IDX, PA): (0, 0xff8207896, 0x118bd9000),(0, 0xff8207897, 0x118bda000),(0, 0xff820 7898, 0x118bdb000),(0, 0xff8207899, 0x118bdc000) lock type bufwait: EXCL by thread 0xff000807a470 (pid 7126) buf at 0xff81f0df9f98 b_flags = 0xa020 b_error = 0, b_bufsize = 2048, b_bcount = 2048, b_resid = 0 b_bufobj = (0xff00080564c8), b_data = 0xff8217ad2000, b_blkno = 128, b_dep = 0 b_npages = 1, pages(OBJ, IDX, PA): (0xff000805c000, 0x10, 0x4a7a000) lock type bufwait: EXCL by thread 0xff0002bd5000 (pid 18) db> alltrace (pid 18 and 7126) Tracing command g_journal switcher pid 18 tid 100076 td 0xff0002bd5000 sched_switch() at sched_switch+0xde mi_switch() at mi_switch+0x186 sleepq_wait() at sleepq_wait+0x42 __lockmgr_args() at __lockmgr_args+0x49b ffs_copyonwrite() at ffs_copyonwrite+0x19a ffs_geom_strategy() at ffs_geom_strategy+0x1b5 bufwrite() at bufwrite+0xe9 ffs_sbupdate() at ffs_sbupdate+0x12a g_journal_ufs_clean() at g_journal_ufs_clean+0x3e g_journal_switcher() at g_journal_switcher+0xe5e fork_exit() at fork_exit+0x11f fork_trampoline() at fork_tram
Re: FS hang with suspfs when creating snapshot on a UFS + GJOURNAL setup
On Thu, Dec 27, 2012 at 06:47:05PM +0100, Andreas Longwitz wrote: > Konstantin Belousov wrote: > > On Thu, Dec 27, 2012 at 12:28:54PM +0100, Andreas Longwitz wrote: > >> On a FreeBSD 8-Stable machine with UFS + GJOURNAL (no SU) I observed the > >> same behaviour as described for UFS+SU+J in > >> lists.freebsd.org/pipermail/freebsd-current/2012-January/030937.html. > >> > >> The snapshot was initiated by amanda with > >> dump 3ubLshf 64 1048576 0 - /dev/mirror/gm0p10.journal (pid 50347) > >> and the process creating the snapshot is > >> /sbin/mksnap_ffs /home /home/.snap/dump_snapshot (pid 50350). > >> > >> The process 50350 hangs and also all following processes that tried to > >> access the home partition, some of them work, but don't come to an end, > >> e.g. a shell after (Ctrl T): > >> load: 0.61 cmd: sh 52670 [suspfs] 43.46r 0.00u 0.00s 0% 2272k. > >> > >> All write I/O's to all gjournaled partitions are stopped. Under normal > >> circumstances the snapshot is taken in five seconds, so I have definitiv > >> not the problem I have described in > >> lists.freebsd.org/pipermail/freebsd-geom/2012-May/005246.html. > >> > >> . > >> > >> It seems there is a deadlock on the suspfs lock, but I could not figure > >> out who holds this lock. > >> Any hints how to get better diagnostic information for next time the > >> error occurs are welcome. > > > > The > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html > > provides the instructions. > > > > The suspfs is owned by the snapshot creator. The question is, where is it > > blocked. > > Thanks for answer. > > In the meantime I can reproduce the problem and got some more > information. It looks that there is a deadlock between the two processes > with pid 18 (g_journal switcher) and pid 7126 (/sbin/mksnap_ffs /home > /home/.snap/my_snapshot): > > 018 0 0 45 0 016 snaplk DL??4:40,34 > [g_journal switcher] > 0 7126 1933 0 50 0 5836 1176 suspfs D ??0:00,44 > /sbin/mksnap_ffs /home /home/.snap/my_snapshot > > procstat -t 18 --> > PIDTID COMM TDNAME CPU PRI STATE WCHAN >18 100076 g_journal switcher g_journal switch 0 129 sleep snaplk > procstat -t 7126 --> > PIDTID COMM TDNAME CPU PRI STATE WCHAN > 7126 100157 mksnap_ffs -1 134 sleep suspfs > procstat -kk 18 --> > PIDTID COMM TDNAME KSTACK >18 100076 g_journal switcher g_journal switch mi_switch+0x186 > sleepq_wait+0x42 __lockmgr_args+0x49b ffs_copyonwrite > +0x19a ffs_geom_strategy+0x1b5 bufwrite+0xe9 ffs_sbupdate+0x12a > g_journal_ufs_clean+0x3e g_journal_switcher+0xe5e fork > _exit+0x11f fork_trampoline+0xe > procstat -kk 7126 --> > PIDTID COMM TDNAME KSTACK > 7126 100157 mksnap_ffs -mi_switch+0x186 > sleepq_wait+0x42 _sleep+0x373 vn_start_write+0xdf ffs_s > napshot+0xe2b ffs_mount+0x65a vfs_donmount+0xdc5 nmount+0x63 > amd64_syscall+0x1f4 Xfast_syscall+0xfc > > >From DDB: > db> show lockedvnods > Locked vnodes > > 0xff012281a938: tag ufs, type VREG > usecount 1, writecount 0, refcount 3339 mountedhere 0 > flags (VV_SYSTEM) > lock type snaplk: EXCL by thread 0xff000807a470 (pid 7126) > with exclusive waiters pending > ino 23552, on dev mirror/gm0p10.journal ... > db> alltrace (pid 18 and 7126) > > Tracing command g_journal switcher pid 18 tid 100076 td 0xff0002bd5000 > sched_switch() at sched_switch+0xde > mi_switch() at mi_switch+0x186 > sleepq_wait() at sleepq_wait+0x42 > __lockmgr_args() at __lockmgr_args+0x49b > ffs_copyonwrite() at ffs_copyonwrite+0x19a > ffs_geom_strategy() at ffs_geom_strategy+0x1b5 > bufwrite() at bufwrite+0xe9 > ffs_sbupdate() at ffs_sbupdate+0x12a > g_journal_ufs_clean() at g_journal_ufs_clean+0x3e > g_journal_switcher() at g_journal_switcher+0xe5e > fork_exit() at fork_exit+0x11f > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xff8242ca8cf0, rbp = 0 --- > > Tracing command mksnap_ffs pid 7126 tid 100157 td 0xff000807a470 > sched_switch() at sched_switch+0xde > mi_switch() at mi_switch+0x186 > sleepq_wait() at sleepq_wait+0x42 > _sleep() at _sleep+0x373 > vn_start_write() at vn_start_write+0xdf > ffs_snapshot() at ffs_snapshot+0xe2b Can you look up the line number for the ffs_snapshot+0xe2b ? I think the bug is that vn_start_write() is called while the snaplock is owned, after the out1 label in ffs_snapshot() (I am looking at the HEAD code). > ffs_mount() at ffs_mount+0x65a > vfs_donmount() at vfs_donmount+0xdc5 > nmount() at nmount+0x63 > amd64_syscall() at amd64_syscall+0x1f4 > Xfast_syscall() at Xfast_syscall+0xfc > --- syscall (378, FreeBSD ELF64, nmount), rip = 0x18069e35c, rsp = > 0x7fffe358, rbp = 0x7fffedc7 --- > > There are a lot of other - but lat
Re: Anothe pkgng question: signing a repository
On Thu, Dec 27, 2012 at 6:22 PM, Rainer Duffner wrote: > Hi, > > I'm creating my own repository and have created a key for it. > > I've created a CSR for it and used that to generate a certificate via > our internal CA. Because there was no other information available, I > used the profile that we use to generate SSL-certificates for web > servers. > > I copied the certificate to the server and adjusted pkg.conf, but when I > want to query the repository, I get: > > root@server:/etc/ssl/cert # pkg install net-snmpd > Updating repository catalogue > repo.txz > 100% 219KB 219.5KB/s 219.5KB/s 00:00 pkg: error reading public > key(/etc/ssl/pkg.conf): error:0906D06C:PEM routines:PEM_read_bio:no > start line pkg: Invalid signature, removing repository. > > > What does pkg expect to be in this file? > > > openssl x509 displays the data for the certificate correctly, so I > really don't know what's missing. > > I ktraced pkg and it is indeed reading the file. > > > > > Best Regards > Rainer See Glen Barber's page about "Maintaining your own pkgng repository". https://glenbarber.us/2012/06/11/Maintaining-Your-Own-pkgng-Repository.html HTH -Kimmo ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Anothe pkgng question: signing a repository
In article <20121227162311$6...@grapevine.csail.mit.edu>, rai...@ultra-secure.de writes: >I'm creating my own repository and have created a key for it. [...] >What does pkg expect to be in this file? A public key. It does not use X.509 (nor is there any reason why it should, although I suppose it could be made to at the cost of significant added complexity and a bootstrapping problem). -GAWollman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ipv6_addrs_IF aliases in rc.conf(5)
2012/12/26 Kimmo Paasiala :
> I've revised the patch again and updated it at gihub,
> https://gist.github.com/4362018. It can now be applied at top level
> of sources (/usr/src typically). It now does the deconfiguration in
> reverse order of the configuration, meaning the aliases configured
> with ipv6_addrs_IF are removed before the ones configured with
> ifconfig_IF_aliasN="inet6 ...".
Adapted for FreeBSD 8.2, works fine:
--- network.subr.orig 2011-02-17 05:19:39.0 +0300
+++ network.subr2012-12-28 00:46:38.0 +0400
@@ -312,6 +312,12 @@ afexists()
# 1 otherwise.
ipv6if()
{
+ # Test for $ipv6_addrs_IF. If it exists then the
+ # interface should be configured for IPv6
+ _tmpargs=$(get_if_var $_if ipv6_addrs_IF)
+ if [ -n "${_tmpargs}" ]; then
+ return 0
+ fi
if ! checkyesno ipv6_enable; then
return 1
fi
@@ -948,7 +954,12 @@ network6_interface_setup()
rtsol_interface=no
ifconfig $i inet6 ${ipv6_ifconfig} alias
fi
-
+ ipv6_addrs=`get_if_var $i ipv6_addrs_IF`
+ if [ -n "${ipv6_addrs}" ]; then
+ rtsol_available=no
+ rtsol_interface=no
+ ipv6_addrs_common ${i} alias
+ fi
# Wireless NIC cards are virtualized through the wlan interface
if ! is_wired_interface ${i}; then
case "${i}" in
@@ -1178,3 +1189,39 @@ network6_getladdr()
esac
done
}
+
+ipv6_addrs_common()
+{
+ local _ret _if _action _ip6prefix _ip6prefixes
+ local _ip6addr _prefixlen
+ local _range _ip6net _ip6low _ip6high
+ _ret=1
+ _if=$1
+ _action=$2
+ # get the prefixes from ipv6_addrs_IF variable
+ _ip6prefixes=`get_if_var $_if ipv6_addrs_IF`
+ for _ip6prefix in ${_ip6prefixes}; do
+ _ip6addr=${_ip6prefix%%/*}
+ _prefixlen=${_ip6prefix##*/}
+ _range=${_ip6addr##*:}
+ _ip6net=${_ip6addr%:*}
+ _ip6low=${_range%-*}
+ _ip6high=${_range#*-}
+ # If deleting an alias, set _prefixlen to null string.
+ if [ "${_action}" = "-alias" ]; then
+ _prefixlen=""
+ else
+ _prefixlen="prefixlen $_prefixlen"
+ fi
+ _ip6high=$(("0x${_ip6high}"))
+ _ip6count=$(("0x${_ip6low}"))
+ while [ "${_ip6count}" -le "${_ip6high}" ]; do
+ # Re-uses the _ip6addr variable from above
+ _ip6addr=$(printf "%x" "${_ip6count}")
+ eval "ifconfig ${_if} inet6
${_ip6net}:${_ip6addr} ${_prefixlen} ${_action}"
+ _ip6count=$((${_ip6count}+1))
+ _ret=0
+ done
+ done
+ return $_ret
+}
--
Non nobis Domine non nobis sed Nomini Tuo da gloriam
Phil Kulin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 9.1 minimal ram requirements
On Wed, Dec 26, 2012 at 06:02:33PM +0100, Zoran Kolic wrote: > > Seeing 9.1-RELEASE instead 9.1-PRERELASE > > or 9.1-RC4 is also a bad suprise for me... > > I assume it does not look like release is the lack > of packages. What you are seeing is behind-the-scenes preparation. The release is official when, and only when, a security-signed email is sent to freebsd-annou...@freebsd.org from the Release Engineering team. mcl ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
