Can't upgrade past 10.4-STABLE (interrupt storm?)

[Chris H]

Hello,
I've got an older laptop that I attempted to install 12 on w/o success.
Well, it installed. But was unusable. Typing anything at the console
frequently doesn't output on the screen w/o tapping one of the arrow
keys. But doing that causes other problems. As I can't really use the
output. :(
I suspected an interrupt storm of some type. But really can't say for
sure. a vmstat -i seems to show unusually high numbers for irq1: atkbd0
often ~1/3rd the number for CPU0. I can easily realize all this during
the install process from the install media. So it's easy to test.
This is a i386 based Pentium M. FreeBSD 10.4-STABLE runs like a dream.
But I'm going to need to move forward at some point, and I'd like that
some point to be now. :)
Any thoughts on how I might discover /what/ change was made from
10.4-->11* to cause this?
It has a trackpad. Should that make any difference.

Thanks!

--Chris


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: jail related inconsistencies in FreeBSD tools parameters

[Chris H]

On Fri, 22 Jun 2018 23:13:17 +0200 "Miroslav Lachman" <000.f...@quip.cz> said

I don't know if it is better to discuss it in jail@ or stable@ list so a 
do cross-post.


FreeBSD has many jail aware utilities but they are inconsistent in 
taking JID as parameter.


For example "sockstat" takes -j JID "Show only sockets belonging to the 
specified jail ID" and it means numeric ID only.
On the other hand "ps" takes -J JID "This may be either the jid or name 
of the jail.  Use -J 0 to display only host processes."
The same apply for "top", it understands jid as a number or name of the 
jail too.

Then again "cpuset" takes only numerical ID of the jail...

Shouldn't it be consistent across all FreeBSD base utilities so all of 
them can use numerical ID and name?

Good idea! Are you offering to create a patch? ;-)
It'd be my guess that given they weren't all created at the same time, nor
the same individual; that (quite probably?) the "jail" additions were also
added at different times, and by different people. So I'd imagine that
unless someone with a commit bit decides one day they'd like to take that
on. Someone(tm) maybe you? will need to propose a patch. :-)

--Chris


Should I file a PR for it?

Miroslav Lachman

PS: I am on FreeBSD 10.4 so I don't know if something is different in 
newer branches

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"



___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Console is broken after updating to 11.2-RELEASE

[Chris H]

On Fri, 22 Jun 2018 20:42:18 +0900 (JST) "Yasuhiro KIMURA"  
said


From: Warner Losh 
Subject: Re: Console is broken after updating to 11.2-RELEASE
Date: Fri, 22 Jun 2018 05:03:43 -0600

> UEFI or legacy boot? Is a BMC involved?

Legacy boot. And BMC is not involved.

Try adding the following to your loader.conf(5) file (/boot/loader.conf):

# Load SysCons driver
kern.vty=sc
# noisy boot
boot_verbose="YES"

Hope this helps!

--Chris


---
Yasuhiro KIMURA
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"



___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Odd behaviour on recent boot of 11.1 with timecounters

[Chris H]

On Tue, 2 Jan 2018 16:45:26 + "Gary Palmer"  said


On Sun, Dec 31, 2017 at 06:47:38PM +0200, Konstantin Belousov wrote:
> On Sun, Dec 31, 2017 at 03:49:13PM +, Gary Palmer wrote:
> > On Sun, Dec 31, 2017 at 04:51:47PM +0200, Konstantin Belousov wrote:
> > > On Sun, Dec 31, 2017 at 02:17:08PM +, Gary Palmer wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > I recently updated to 11.1-RELEASE-p6 and on the most recent reboot 
> > > > (after rebuilding all the necessary packages) the clock was running 
> > > > slow and NTP wouldn't sync.  I looked in /var/log/messages and I found

> > > > that for some reason, on this latest boot, it got the frequency of
> > > > TSC-low wrong.
> > > > 
> > > > Aug 24 04:55:35 my kernel: Timecounter "TSC-low" frequency 1746073190

> Hz quality 1000
> > > > Aug 26 03:11:38 my kernel: Timecounter "TSC-low" frequency 1746070760
> Hz quality 1000
> > > > Aug 26 14:12:46 my kernel: Timecounter "TSC-low" frequency 1746075204
> Hz quality 1000
> > > > Nov 19 16:01:09 my kernel: Timecounter "TSC-low" frequency 1746070746
> Hz quality 1000
> > > > Dec 27 22:28:00 my kernel: Timecounter "TSC-low" frequency 1746074808
> Hz quality 1000
> > > > Dec 27 22:51:12 my kernel: Timecounter "TSC-low" frequency 1746071892
> Hz quality 1000
> > > > Dec 28 12:50:46 my kernel: Timecounter "TSC-low" frequency 1746069704
> Hz quality 1000
> > > > Dec 28 14:03:52 my kernel: Timecounter "TSC-low" frequency 1937876448
> Hz quality 1000
> > > > 
> > > > Until the December reboots the machine was running 10.x.  Dec 27 and

> later
> > > > are part of the process to get up to 11.x.
> > > > 
> > > > Any idea why the TSC-low frequency jumped 191,806,744Hz on the last

> > > > measurement?
> > > > 
> > > > I switched to HPET temporarily via sysctl and ntp seems happy.  I'm

> just
> > > > concerned that the problem might recur on later reboots as TSC-low
> seems
> > > > to be the preferred timecounter.
> > > 
> > > Show first 100 lines of the dmesg from a verbose boot.

> > > Also check BIOS settings related to overclocking and powersaving.
> > > 
> > 
> > Hi Konstantin,
> > 
> > BIOS settings haven't been changed in 4+ years.  No overclocking, and

> > all powersaving options are at "auto" or "disabled".
> > 
> > The first 100 lines of verbose dmesg didn't seem that interesting so

> > I've included up to the end of "Device configuration finished"
> > 
> > Note that this boot didn't have the TSC-low problem, and the boot

> > that had it wasn't verbose unfortunately.
> 
> It is really the CPU identification which I wanted to see.  You have

> IvyBridge, which is known to have good TSC.

Ah

> Try to obtain verbose dmesg with mis-identified frequency.

Tried, and failed after 20+ reboots.  I've left

boot_verbose=" -v"

I believe that should read:

boot_verbose="YES"
but maybe just the occurrence of something makes it a positive.



in /boot/loader.conf to catch any boot-time wonkiness and undone it at
runtime with 


debug.bootverbose=0

in /etc/sysctl.conf as I found that the snd_hda driver is ... chatty
at runtime.

Thanks,

Gary
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"



___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: D-Link DGE530T issue

[Chris H]

On Wed, 15 Nov 2017 23:00:33 +0300 Mike Black  wrote

> Hello
> 
> I've got old PCI NIC D-Link DGE530T Rev 11 with SysKonnect chip on it.
> Years ago it worked in FreeBSD 8/9 Stable with if_sk driver.
> 
> Now I'm runnig
> 11.1-STABLE FreeBSD 11.1-STABLE #1 r323214: Sat Nov 11 19:06:20 MSK 2017
>  amd_miek@diablo.miekoff.local:/usr/obj/usr/src/sys/DIABLO64  amd64 1101502
> 1101502
> 
> But recently I plugged this card back and it's not being recognized by a
> driver.
> 
> pciconf says that is
> none0@pci0:5:1:0:   class=0x02 card=0x4b011086 chip=0x4b011086
> rev=0x11 hdr=0x00
> vendor = 'J. Bond Computer Systems'
> class  = network
> subclass   = ethernet
> bar   [10] = type Memory, range 32, base 0xfebec000, size 16384, enabled
> bar   [14] = type I/O Port, range 32, base 0xee00, size 512, enabled
> cap 01[48] = powerspec 2  supports D0 D1 D2 D3  current D3
> cap 03[50] = VPD
> 
> According /usr/share/misc/pci_vendors this D-link should have 4b011186 not
> 4b011086.
Just a hunch; But maybe it was simply a typo?
You can probably omit the additional "1" on your local copy of the source,
and try to build it again. My guess is you'll have success.
NOTE: I'm not an authority on this driver. I'm only attempting to
provide a possible solution. :)

If you *are* successful. I would advise opening a PR for this. :)

--Chris
> I looked into driver code  (if_sk) and it expects 1186 card also.
> I googled about this issue but found no one similar in a recent years
> So I'd like to know what's wrong - some changes in driver in a recent years
> or smth going wrong while OS detecting this NIC. But that's confusing,
> because this exact NIC worked years ago...
> 
> -- 
> amd_miek
> Think different.
> Just superior.
> 
>  n=sig-email_content=webmail> Без
> вирусов. www.avast.ru
>  n=sig-email_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: console-only freebsd

[Chris H]

On Sat, 7 Oct 2017 09:49:40 -0700 Freddie Cash  wrote

> On Oct 7, 2017 7:21 AM, "tech-lists"  wrote:
> 
> Hi,
> 
> I have a freebsd 11-stable installation on a (gutless) netbook. What I'd
> like is full functionality via the console[1]. One of the things it needs
> is some graphics capability but without xorg. So I'm thinking, svga or
> libSDL. For example, let's say to view a jpg file. If this is possible from
> the console, what program or port would one use to view a gif or jpg file?
> 
> [1] by console, I mean the consoles accessed via alt-f1 to alt-f7 [2]
> [2] can the number of consoles be increased?
> 
> 
> Tmux or screen will give you an unlimited number of virtual terminals using
> only a single TTY. And give you the ability to split the console into
> multiple windows.

You might also find this article by Warren Block of value:

http://www.wonkity.com/~wblock/docs/html/hiresconsole.html

--Chris
> 
> Cheers,
> Freddie
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: CAM timeouts at startup

[Chris H]

On Mon, 10 Apr 2017 10:49:59 -0700 "Mahlon E. Smith"  wrote

> Hi.  Got some new machines running 11.0-RELEASE-p8 with a small pile of SSD
> in them. 
>
> Getting some strange CAM timeouts at boot, that dramatically delay
> startup times.  These errors don't happen at all after boot, everything
> seems just fine.
> 
> Any clues / tuning suggestions are appreciated.
> 
> 
> Relevant stuff from dmesg:
> 
> mpr0:  port 0x3000-0x30ff mem
> 0x9200-0x9200,0x91f0-0x91ff at device 0.0 numa-domain 0 on
> pci3 mpr0: IOCFacts  :
> MsgVersion: 0x205
> HeaderVersion: 0x2a00
> IOCNumber: 0
> IOCExceptions: 0x0
> MaxChainDepth: 128
> NumberOfPorts: 1
> RequestCredit: 9680
> ProductID: 0x2221
> IOCRequestFrameSize: 32
> MaxInitiators: 0
> MaxTargets: 544
> MaxSasExpanders: 125
> MaxEnclosures: 126
> HighPriorityCredit: 124
> MaxReplyDescriptorPostQueueDepth: 65504
> ReplyFrameSize: 32
> MaxVolumes: 0
> MaxDevHandle: 677
> MaxPersistentEntries: 240
> mpr0: Firmware: 13.00.00.00, Driver: 13.01.00.00-fbsd
> mpr0: IOCCapabilities:
> 7a85c stDisc> 
>
> da0 at mpr0 bus 0 scbus0 target 19 lun 0
> da0:  Fixed Direct Access SPC-4 SCSI device
> da0: Serial Number S2HTNX0H701448  
> da0: 1200.000MB/s transfers
> da0: Command Queueing enabled
> da0: 915715MB (1875385008 512 byte sectors)
> da0: quirks=0x8<4K>
> 
> 
> mpr0: Sending reset from mprsas_send_abort for target ID 19
> mpr0: Unfreezing devq for target ID 19
> (da0:mpr0:0:19:0): READ(10). CDB: 28 00 6f c8 1a af 00 00 01 00 
> (da0:mpr0:0:19:0): CAM status: Command timeout
> (da0:mpr0:0:19:0): Retrying command
> (da0:mpr0:0:19:0): READ(10). CDB: 28 00 6f c8 1a af 00 00 01 00 
> (da0:mpr0:0:19:0): CAM status: SCSI Status Error
> (da0:mpr0:0:19:0): SCSI status: Check Condition
> (da0:mpr0:0:19:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset,
> or bus device reset occurred) (da0:mpr0:0:19:0): Retrying command (per
> sense data) (noperiph:mpr0:0:4294967295:0): SMID 2 Aborting
> command 0xfe00026066c0 mpr0: Sending reset from mprsas_send_abort for
> target ID 20 mpr0: Unfreezing devq for target ID 20
> (da1:mpr0:0:20:0): READ(10). CDB: 28 00 6f c8 1a af 00 00 01 00 
> (da1:mpr0:0:20:0): CAM status: Command timeout
> (da1:mpr0:0:20:0): Retrying command
> (da1:mpr0:0:20:0): READ(10). CDB: 28 00 6f c8 1a af 00 00 01 00 
> (da1:mpr0:0:20:0): CAM status: SCSI Status Error
> (da1:mpr0:0:20:0): SCSI status: Check Condition
> (da1:mpr0:0:20:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset,
> or bus device reset occurred) (da1:mpr0:0:20:0): Retrying command (per
> sense data) (noperiph:mpr0:0:4294967295:0): SMID 3 Aborting
> command 0xfe0002609750 mpr0: Sending reset from mprsas_send_abort for
> target ID 21 (da2:mpr0:0:21:0): READ(10). CDB: 28 00 6f c8 1a af 00 00 01
> 00  mpr0: (da2:mpr0:0:21:0): CAM status: Command timeout
> Unfreezing devq for target ID 21
> (da2:mpr0:0:21:0): Retrying command
> (da2:mpr0:0:21:0): READ(10). CDB: 28 00 6f c8 1a af 00 00 01 00 
> (da2:mpr0:0:21:0): CAM status: SCSI Status Error
> (da2:mpr0:0:21:0): SCSI status: Check Condition
> (da2:mpr0:0:21:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset,
> or bus device reset occurred) (da2:mpr0:0:21:0): Retrying command (per
> sense data) (noperiph:mpr0:0:4294967295:0): SMID 4 Aborting
> command 0xfe000260c7e0 mpr0: Sending reset from mprsas_send_abort for
> target ID 22 mpr0: Unfreezing devq for target ID 22
> (da3:mpr0:0:22:0): READ(10). CDB: 28 00 6f c8 1a af 00 00 01 00 
> (da3:mpr0:0:22:0): CAM status: Command timeout
> (da3:mpr0:0:22:0): Retrying command
> (da3:mpr0:0:22:0): READ(10). CDB: 28 00 6f c8 1a af 00 00 01 00 
> (da3:mpr0:0:22:0): CAM status: SCSI Status Error
> (da3:mpr0:0:22:0): SCSI status: Check Condition
> (da3:mpr0:0:22:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset,
> or bus device reset occurred) (da3:mpr0:0:22:0): Retrying command (per
> sense data) (noperiph:mpr0:0:4294967295:0): SMID 5 Aborting
> command 0xfe0002614f10 mpr0: Sending reset from mprsas_send_abort for
> target ID 25 mpr0: Unfreezing devq for target ID 25
> (da6:mpr0:0:25:0): READ(10). CDB: 28 00 6f c8 1a af 00 00 01 00 
> (da6:mpr0:0:25:0): CAM status: Command timeout
> (da6:mpr0:0:25:0): Retrying command
> (da6:mpr0:0:25:0): READ(10). CDB: 28 00 6f c8 1a af 00 00 01 00 
> (da6:mpr0:0:25:0): CAM status: SCSI Status Error
> (da6:mpr0:0:25:0): SCSI status: Check 

Re: if_iwm crashes kernel when loaded from /boot/loader.conf

[Chris H]

On Fri, 07 Apr 2017 14:38:40 + Tommi Pernila 
wrote

> On Fri, 7 Apr 2017 at 16.27, Tomasz CEDRO  wrote:
> 
> > Hello,
> >
> > I noticed a problem when loading if_iwm from /boot/loader.conf kernel
> > crashes as it cannot load module firmware dead loop occurs. Adding
> > iwm8000Cfw before if_iwm does not help.
> >
> > Loading if_iwm on a running system works fine and gives operational wifi.
> >
> > Intel Corporation Wireless 8260 class=0x028000 card=0x10108086
> > chip=0x24f38086 rev=0x3a hdr=0x00
> >
> > --
> > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> 
> 
> This has been happening to my Intel 8260 as well.
> It seems to be a known bug.
Has anyone opened a pr(1)?
At least that way, it would be recorded as a problem.

--Chris
> 
> I circumvent it by manually loading the wifi modules after boot. This
> doesn't crash the system.
> 
> As a dirty hack? You could add the loading as a script and automatically
> load the modules when the FreeBSD is fully up and running.
> 
> Br,
> 
> Tommi
>


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: how can I make freebsd wait for usb to become active? Or delay mountroot?

[Chris H]

On Mon, 13 Feb 2017 19:00:39 + tech-lists  wrote

> Hello stable@,
> 
> system: 11-stable r313553
> 
> In the kernel there is an option for scsi delay.
It should be enough to bump the kern.cam.scsi_delay=
a couple hundred at a time, until you find the "sweet spot".
You might also try the autoboot_delay= option instead. It
might give your USB port enough time to come ready.

> Is there also one for
> usb? Perhaps not in the kernel but elsewhere. I can't find it.
> 
> The problem is seen especially where the bootable device is usb. The
> boot process starts and dumps me at mountroot where I wait for a short
> time until the usb stick is properly detected (bright white writing at
> the console). The usb stick is plugged into a usb3 port. For example:
> 
> [snip]
> 
> usbus0: 5.0Gbps Super Speed USB v3.0
> usbus1: 12Mbps Full Speed USB v1.0
> usbus2: 480Mbps High Speed USB v2.0
> usbus3: 12Mbps Full Speed USB v1.0
> ugen0.1: <0x1022 XHCI root HUB> at usbus0
> uhub0: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
> ugen1.1:  at usbus1
> uhub1:  on usbus1
> ugen2.1:  at usbus2
> uhub2:  on usbus2
> ugen3.1:  at usbus3
> uhub3:  on usbus3
> usbus4: 480Mbps High Speed USB v2.0
> ugen4.1:  at usbus4
> uhub4:  on usbus4
> acpi_tz0: _CRT value is absurd, ignored (255.1C)
> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
> ada0:  ACS-2 ATA SATA 3.x device
> cd0 at ahcich1 bus 0 scbus1 target 0 lun 0
> cd0:  Removable CD-ROM SCSI device
> cd0: Serial Number 1415TP277450E0H6H
> cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes)
> cd0: Attempt to query device size failed: NOT READY, Medium not present
> - tray open
> ada0: Serial Number JA1006103G0ALV
> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
> ada0: Command Queueing enabled
> ada0: 953869MB (1953525168 512 byte sectors)
> SMP: AP CPU #3 Launched!
> SMP: AP CPU #1 Launched!
> SMP: AP CPU #2 Launched!
> Timecounter "TSC" frequency 1597045198 Hz quality 1000
> Trying to mount root from ufs:/dev/da0p2 [rw]...
> uhub3: 5 ports with 5 removable, self powered
> uhub1: 5 ports with 5 removable, self powered
> uhub0: 4 ports with 4 removable, self powered
> Root mount waiting for: usbus4 usbus2 usbus0
> ugen0.2:  at usbus0
> umass0 on uhub0
> umass0: 
> on usbus0
> umass0:  SCSI over Bulk-Only; quirks = 0x8100
> umass0:3:0: Attached to scbus3
> uhub2: 5 ports with 5 removable, self powered
> uhub4: 5 ports with 5 removable, self powered
> ugen0.3:  at usbus0
> ukbd0 on uhub0
> ukbd0:  on usbus0
> kbd2 at ukbd0
> Root mount waiting for: usbus4
> ugen4.2:  at usbus4
> mountroot: waiting for device /dev/da0p2...
> Mounting from ufs:/dev/da0p2 failed with error 19.
> 
> Loader variables:
>   vfs.root.mountfrom=ufs:/dev/da0p2
>   vfs.root.mountfrom.options=rw
> 
> Manual root filesystem specification:
>   : [options]
>   Mount  using filesystem 
>   and with the specified (optional) option list.
> 
> eg. ufs:/dev/da0s1a
> zfs:tank
> cd9660:/dev/cd0 ro
>   (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
> 
>   ?   List valid disk boot devices
>   .   Yield 1 second (for background tasks)
>   Abort manual input
> 
> mountroot> Trying to mount root from ufs:/dev/da0p2 []...
> mountroot: waiting for device /dev/da0p2...
> Mounting from ufs:/dev/da0p2 failed with error 19.
> 
> mountroot>
> 
> [snip]
> 
> Then this happens:
> 
> (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
> (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
> (probe0:umass-sim0:0:0:0): Retrying command
> da0 at umass-sim0 bus 0 scbus3 target 0 lun 0
> da0: < USB DISK 3.0 PMAP> Removable Direct Access SPC-4 SCSI device
> da0: Serial Number 070B4722335D3288
> da0: 400.000MB/s transfers
> da0: 30176MB (61800448 512 byte sectors)
> da0: quirks=0x3
> 
> so now at the mountroot prompt I enter ufs:/dev/da0p2 (which is a value
> that mountroot already had) and carry on booting:
> 
> mountroot> Trying to mount root from ufs:/dev/da0p2 []...
> re0: link state changed to DOWN
> re0: link state changed to UP
> ums0 on uhub0
> ums0:  on usbus0
> ums0: 16 buttons and [XYZT] coordinates ID=2
> uhid0 on uhub0
> uhid0:  on usbus0
> 
> [...]
> 
> The same sort of thing happens on an 11-stable r313043 desktop, only
> this time I'm not booting from usb. The system comes up, I get a login
> prompt, then five or ten seconds later usb wakes up having detected the
> usb3 external HD.
> 
> How can I fix this?
> 
> thanks,
> -- 
> J.
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send 

Re: pkg upgrade problem with Perl 5.24

[Chris H]

On Fri, 13 Jan 2017 16:38:59 + Matthew Seaman <matt...@freebsd.org> wrote

> On 2017/01/13 16:31, Chris H wrote:
> > As a general rule:
> > install from pkg(8) remove with pkg(8)
> > install from ports(7), remove with ports(7)
> > 
> 
> Sorry -- this is completely bogus.
Not entirely.

>  You can freely mix and match either
> way. Just make sure that the package names match up.
> 
> In fact the ports removes packages using pkg(8), so it all comes down to
> the same thing in the end.
That is the *intended* outcome, to be sure. *But* as noted in the OP[1],
and from some edge cases I've personally run into; the "general rule"
I listed, does apply. :)
> 
> Cheers,
> 
> Matthew

I have now removed the package using pkg delete -f -n perl5-5.24.1.r4_1 and was
then able to install from ports without problems:

[1] root@gw2:/usr/ports/lang/perl5.24 # pkg info perl5.24-5.24.1.r5_1
perl5.24-5.24.1.r5_1
Name   : perl5.24
Version: 5.24.1.r5_1
Installed on   : Thu Jan 12 17:53:45 2017 CET
Origin : lang/perl5.24

--Chris


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: pkg upgrade problem with Perl 5.24

[Chris H]

On Fri, 13 Jan 2017 15:43:41 + Holger Kipp  wrote

> Dear all,
> 
> I upgraded Perl to 5.24(1.r4_1) (via pkg upgrade).
> When I now try to install the latest version from ports (1.r5_1), the system
> can’t install the new version because of the older version, but can’t
> deinstall(*) the older version (eg. via make deinstall && make reinstall).
> 
> 
> 
> root@gw2:/usr/ports/lang/perl5.24 # pkg info | grep perl
> p5-Data-Dumper-2.161   Stringified perl data structures, suitable for
> both printing and eval p5-Pg-2.1.1_4,1Interface for using
> perl5 to access PostgreSQL databases p5-Scalar-List-Utils-1.45,1Perl
> subroutines that would be nice to have in the perl core perl5-5.24.1.r4_1
>  Practical Extraction and Report Language 
>
> so currently via pkg upgrade I got perl5-5.24.1.r4_1, which perl itself
> confirms: root@gw2:/usr/ports/lang/perl5.24 # perl -v
> 
> This is perl 5, version 24, subversion 1 (v5.24.1) built for
> amd64-freebsd-thread-multi (with 1 registered patch, see perl -V for more
> detail) 
>
> This is then obviously the version from FreeBSD repository.
> 
> If I try to install the latest version from ports (perl5-5.24.1.r5_1), I get
> the following (make install just to get the messages): 
>
> 
> root@gw2:/usr/ports/lang/perl5.24 # make install
> ===>  Installing for perl5.24-5.24.1.r5_1
> ===>  Checking if perl5.24 already installed
> ===>   Registering installation for perl5.24-5.24.1.r5_1
> Installing perl5.24-5.24.1.r5_1...
> pkg-static: perl5.24-5.24.1.r5_1 conflicts with perl5-5.24.1.r4_1 (installs
> files into the same place).  Problematic file: /usr/local/bin/perl5.24.1
> *** Error code 70
> 
> Stop.
> make[1]: stopped in /usr/ports/lang/perl5.24
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/ports/lang/perl5.24
> 
> 
> Deinstalling the existing version does not work:
> 
> root@gw2:/usr/ports/lang/perl5.24 # make deinstall
> ===>  Deinstalling for perl5.24
> ===>   perl5.24 not installed, skipping
> 
> But according to pkg info it is installed:
> 
> root@gw2:/usr/ports/lang/perl5.24 # pkg info perl5
> perl5-5.24.1.r4_1
> Name   : perl5
> Version: 5.24.1.r4_1
> Installed on   : Thu Jan 12 12:51:03 2017 CET
> Origin : lang/perl5.24
> 
> 
> This sees to be a bit strange.
> 
> (*) I have now removed the package using pkg delete -f -n perl5-5.24.1.r4_1
> and was then able to install from ports without problems: 
>
> root@gw2:/usr/ports/lang/perl5.24 # pkg info perl5.24-5.24.1.r5_1
> perl5.24-5.24.1.r5_1
> Name   : perl5.24
> Version: 5.24.1.r5_1
> Installed on   : Thu Jan 12 17:53:45 2017 CET
> Origin : lang/perl5.24
> 
> 
> Any ideas what happened here? I’m not sure if this is expected behaviour.
> 
> Many thanks and best regards,
> Holger
As a general rule:
install from pkg(8) remove with pkg(8)
install from ports(7), remove with ports(7)

That said; I didn't notice any evidence of which version of
FreeBSD, you're running (uname -a) --
It's important where Perl is concerned.

How about make.conf(5)? Anything interesting in there;
DEFAULT_VERSIONS+=
or
WITH_PKGNG=

HTH

--Chris


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: vt console driver and default vga mode: breaking POLA

[Chris H]

On Fri, 9 Sep 2016 11:59:45 +0200 Borja Marcos  wrote

> Hi
> 
> I apologise for being late on this, but I just noticed. The new vt console
> driver has a very important change in behavior, replacing the ancient
> “BIOS” text mode with a graphic VGA mode. 
>
> I don’t know how many people relies on BIOS serial redirection for
> consoles, but at least HP’s iLO system offers the possibility of accessing
> the console through a ssh connection instead of requiring a bloated Java
> console, and it’s a very convenient feature. But it only works in pure
> “BIOS text mode” (the old sc console driver used this mode as a default).
> 
> I would rather change the default behavior of vt to hw.vga.textmode=1 so that
> its behavior mimics the old sc driver.
> 
> I know the current fad is to hide boot messages with panda bears and
> beautiful butterflies revolving around them, but boot messages are critical
> when diagnosing problems. 
LOL
>
> I should have chimed in earlier, I know. But anyway it’s a very minor
> change. 
>
> 
> 
> 
> What do you think?
+1
It might also be worth mentioning that (most?) NVIDIA card
users users will also suffer from this (non text mode).
> 
> 
> 
> 
> Borja.
> 
--Chris


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Looking for libvgl users

[Chris H]

On Tue, 21 Jun 2016 09:33:11 -0400 Ed Maste  wrote

> Prompted by a recent discussion of the vt(4) console I would like to
> send this query to -stable. When posted to -current about 1.5 years
> ago it received only one private reply pointing out an example vgl(3)
> consumer. Please see the original request and let me know if you use
> vgl(3).
FWIW I ran a quick
# cd /usr/ports; find . | xargs grep vgl
Which returned quite a few entries, as well as unrelated.
In case it helps. Some of the possibly notable ones include:
/devel/sdl12
/korean/man-doc/pkg-plist:share/man/ko_KR.eucKR/man3/vgl.3.gz
/games/digger-vgl
/japanese/groff/files/mdoc.local.in:.ds str-Lb-libvgl  Video Graphics
Library (libvgl, \-lvgl)
/misc/compat4x
/misc/compat5x
/misc/compat6x
/misc/compat7x
/x11/virtualgl

There were also matches in binary files; jdk, gnome(2|3), xorg, teX,
and ghostscript. But I didn't pursue it any further.

--Chris

> 
> On 27 October 2014 at 11:26, Ed Maste  wrote:
> > vgl(3) is a graphics library for syscons(4) that provides some basic
> > graphics operations (e.g. some mode setting, bitmaps, boxes,
> > ellipses). Right now it does not support the newer vt(4) console.
> >
> > In order to help determine the priority of a porting effort to add
> > vt(4) support I'd like to better understand where vgl is being used
> > now. I'd be interested in hearing about both open source software
> > using vgl as well as proprietary or internal applications. So if
> > you're using vgl I'd appreciate a follow up (in private is fine) with
> > a brief description of your use case.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: unbound and ntp issuse

[Chris H]

I'm playing catchup on my INBOX, so apologies in advance, if this has
already been satisfactorily answered...
On Mon, 6 Jun 2016 16:50:18 +0300 Slawa Olhovchenkov  wrote

> On Mon, Jun 06, 2016 at 09:33:02AM -0400, Lowell Gilbert wrote:
> 
> > Slawa Olhovchenkov  writes:
> > 
> > > On Fri, Jun 03, 2016 at 02:34:18PM -0400, Lowell Gilbert wrote:
> > >
> > >> Slawa Olhovchenkov  writes:
> > >> 
> > >> > Default install with local_unbound and ntpd can't be functional with
> > >> > incorrect date/time in BIOS:
> > >> >
> > >> > Unbound requred correct time for DNSSEC check and refuseing queries
> > >> > ("Jul 1 20:17:29 yellowrat unbound: [3444:0] info: failed to prime
> > >> > trust anchor -- DNSKEY rrset is not secure . DNSKEY IN")
> > >> >
> > >> > ntpd don't have any numeric IP of ntp servers in ntp.conf -- only
> > >> > symbolic names like 0.freebsd.pool.ntp.org, as result -- can't
> > >> > resolve (see above, about DNSKEY).
> > >> 
> > >> I can't see how this would happen. DNSSEC doesn't seem to be required in
> > >> a regular install as far as I can see. Certainly I don't have any
> > >
> > > I don't know reasson for enforcing DNSSEC in regular install.
> > > I am just select 'local_unbound' at setup time and enter '127.0.0.1' as
> > > nameserver address.
> > 
> > That's not enough to configure unbound as a fully recursive DNS
> > server.
> 
> What I am missing?
> Need to fix unbound setup scripts? bsdinstall scripts?
> As I see unbound setup scripts detects 127.0.0.1 in resolv.conf and
> configured unbound as fully recursive DNS server.
May I suggest ntpdate(8)?
Find a reliable time server in your region, and once found add it
*early* in your rc.conf(5). Well, ahead of your unbound stanza. ie;

hostname="..."
ifconfig_re0="inet ... netmask ..."
defaultrouter="..."
ntpdate_enable="YES"
ntpdate_hosts="a reliable regional time server"

..

unbound_enable="YES"
..

ALSO. Since you're upstream will, in all likelihood have informed
you of a preferred set of 2 name servers. Place one of them in your
hosts(5) file. This will help ensure that ntpdate(8) can reliably
discover your regional time server.

That should get you where you want to go. :-)

--Chris
> 
> > If your system gets its address through DHCP, it is probably
> > getting DNS server addresses as well, and would work fine *without* your
> > configuring any of the DNS state.
> 
> I am have static address and don't getting DNS server address.
> 
> > >> problem on any of my systems, and I've never configured an anchor on the
> > >> internal systems.
> > >> 
> > >> > IMHO, ntp.conf need to include some numeric IP of public ntp servers.
> > >> 
> > >> Ouch; that's a terrible idea, for several different reasons.
> > >
> > > What else?
> > 
> > All the normal reasons that hard-coding IP addresses is a bad idea; they
> > can change, you're encouraging a lot of people to use the same ones, etc.
> 
> And how to resolve this issuse:
> 
> - default install with unbound as recursive DNS server (by default
>   enforcing DNSSEC)
> - ntp time synchronisation
> - stale CMOS time (2008 year)


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: fetch(1) always dumps core - openssl issue?

[Chris H]

On Wed, 9 Mar 2016 21:28:48 -0800 Xin Li <delp...@delphij.net> wrote

> On 3/9/16 19:09, Chris H wrote:
> > Greetings,
> > I just built/installed world/kernel on a fresh
> > STABLE-9 box. Now building ports almost always results
> > in fetch(1) dumping core. It appears that this happens
> > on ssl enabled hosts. Resulting in fetch dropping to
> > distcache.freebsd.org.
> > I see a lot of noise on the lists regarding openssl
> > issues recently. So thought I'd mention this, in hopes
> > of finding a solution.
> 
> Please update to r296597+.
> 
> Cheers,
Will do. Thank you very much!


--Chris

--


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

fetch(1) always dumps core - openssl issue?

[Chris H]

Greetings,
I just built/installed world/kernel on a fresh
STABLE-9 box. Now building ports almost always results
in fetch(1) dumping core. It appears that this happens
on ssl enabled hosts. Resulting in fetch dropping to
distcache.freebsd.org.
I see a lot of noise on the lists regarding openssl
issues recently. So thought I'd mention this, in hopes
of finding a solution.

Thanks!

--Chris

--


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Why must X open TCP by default?

[Chris H]

On Wed, 2 Mar 2016 20:50:11 -0500 kpn...@pobox.com wrote

> On Wed, Mar 02, 2016 at 02:54:53PM -0800, Chris H wrote:
> > #!/bin/sh -
> > /usr/local/bin/startx -- -nolisten tcp
> > 
> > exit
> > 
> > which seems to get the job done, and allow me to be lazy
> > at the CLI. :-)
> 
> Personally, I'd go with:
> 
> #!/bin/sh -
> exec /usr/local/bin/startx -- -nolisten tcp
> 
> Because then I have one fewer processes running cluttering up my ps listings,
> and because the exit code from startx will now naturally be picked up by
> the parent program. What if, for example, startx crashes? Your script
> will hide that fact. With exec no information is lost.

Crap. Good point(s); points I should have already recognized.
I'm apparently not firing on all cylinders today.
Thanks, Neal, for taking the time to give me a Wake Up call! :-)

> 
> -- 
> Kevin P. Nealhttp://www.pobox.com/~kpn/

--Chris


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Why must X open TCP by default?

[Chris H]

On Wed, 2 Mar 2016 15:59:57 -0500 Brandon Allbery <allber...@gmail.com> wrote

> On Wed, Mar 2, 2016 at 3:56 PM, Chris H <bsd-li...@bsdforge.com> wrote:
> 
> > Good catch, by both you, and Brandon. I just tried it. But
> > sockstat(1) still reports 6000 being open. Closing the X
> > server, and session, reveal that 6000 is no longer open.
> > Bummer.
> >
> 
> Check 'man 7 Xserver' to verify the option needed. You might also have to
> check the xserverrc file (I don't recall where it is offhand and can't
> really check right now, but startx is a shell script and the default
> xserverrc will be set near the top) to see if it is overriding the option.
> In that case you could copy the xserverrc to ~/.xserverrc (make sure it's
> chmod +x) and edit that copy to force nolisten tcp, or for multiple users
> you'd edit the master xserverrc but may need to remember to re-edit after
> system updates.
> 
Thanks for the pointers Brandon. I had already consulted them,
but (as with your clarification) I glossed over it all a bit
too quickly. I saw the difference as:  -nolisten && --nolisten
rather than as intended: -- -nolisten
Once I discovered that, the command worked as intended.
OTOH I was unable to discover a way to make the -nolisten
option GLOBAL. eg; Xorg will *never* listen on a tcp port.
While I could have edited /usr/local/etx/X11/xinit/xinitrc
I didn't want to alter it, lest upgrading refuse to update
it with the newer version. So I simply created an ~/startx
file containing:

#!/bin/sh -
/usr/local/bin/startx -- -nolisten tcp

exit

which seems to get the job done, and allow me to be lazy
at the CLI. :-)

Thanks again, to both you, and Freddie for taking the time
to respond with such useful info!

--Chris


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Why must X open TCP by default?

[Chris H]

On Wed, 2 Mar 2016 12:44:18 -0800 Freddie Cash <fjwc...@gmail.com> wrote

> On Wed, Mar 2, 2016 at 12:40 PM, Chris H <bsd-li...@bsdforge.com> wrote:
> 
> > Hello,
> >  This is regarding 9-STABLE. All of the 9-STABLE boxes
> > that have Xorg installed, and running on them, insist on
> > opening TCP port 6000; as reported by sockstat(1)
> >
> > Xorg   1295  1  tcp6   *:6000*:*
> > Xorg   1295  3  tcp4   *:6000*:*
> >
> > I see that the (current(ish)) documentation indicates
> > that this option is off, by default, and can be enabled
> > by passing -listen_tcp to startx(1). This seems to hold
> > true, as all of my -CURRENT boxes do not show port 6000
> > as being open while X is running. So my question is;
> > how can I prevent X from opening tcp ports?
> > I attempted;
> > startx -nolisten tcp
> >
> 
> ​Does the following work (note the extra -- in the command)?​
> 
> ​startx -- -nolisten tcp​
Hello, Freddie.
Good catch, by both you, and Brandon. I just tried it. But
sockstat(1) still reports 6000 being open. Closing the X
server, and session, reveal that 6000 is no longer open.
Bummer.

Thanks to both of you for the fast, and informative reply!

--Chris


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Why must X open TCP by default?

[Chris H]

Hello,
 This is regarding 9-STABLE. All of the 9-STABLE boxes
that have Xorg installed, and running on them, insist on
opening TCP port 6000; as reported by sockstat(1)

Xorg   1295  1  tcp6   *:6000*:*
Xorg   1295  3  tcp4   *:6000*:*

I see that the (current(ish)) documentation indicates
that this option is off, by default, and can be enabled
by passing -listen_tcp to startx(1). This seems to hold
true, as all of my -CURRENT boxes do not show port 6000
as being open while X is running. So my question is;
how can I prevent X from opening tcp ports?
I attempted;
startx -nolisten tcp
startx -nolisten_tcp
but no joy. Is there an option available for xorg.conf(5)?
Maybe like
DisableTCP true
or
Option "DisableTCP" "true"
I couldn't find any hints in the man pages.
Anyway, any input greatly appreciated.

Thanks!

--Chris


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: mergemaster woes at STABLE

[Chris H]

On Fri, 15 Jan 2016 17:38:05 +0100 Michael Grimm 
wrote

> Hi,
> 
> starting a couple of weeks ago, I do see mergemaster complaining after
> "mergemaster -iFU": 
>
> stat: ./have: stat: No such file or directory
> /usr/sbin/mergemaster: arithmetic expression: expecting primary: " ~18 &
> 4095 &  "
> install: invalid file mode: ./have
> *** FATAL ERROR: Unable to install ./have to /
> 
> This is on two different servers running 10.2-STABLE (r293911). I couldn't
> find similar reports at google, but I might have missend something.
> 
> Any idea where to look for?
Just a hunch; but looks like an unterminated quote --
", or ' without the closing ", or '

--Chris
> 
> Thanks and regards,
> Michael
>


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: freebsd-update incorrect hashes

[Chris H]

On Wed, 23 Dec 2015 14:22:51 +0100 rai...@ultra-secure.de wrote

> Am 2015-12-23 13:25, schrieb Aristedes Maniatis:
> > I've had problems with freebsd-update for many years now. It is by far
> > the least reliable component of FreeBSD since I started with the
> > operating system back at 3.4 in 1999.
> > 
> > Anyhow, I'm usually able to get past the exceedingly slow downloads
> > and errors to the upgrade process, but this time nothing I do will get
> > me to the end. I've tried deleting /var/db/freebsd-update but several
> > hours later I was at the same place again. The internet link is fast,
> > but with a web proxy in this location, some downloads are slightly
> > delayed while the virus scanner on the proxy does its thing. Perhaps
> > 3-5 seconds delayed.
> 
> 
> 
> The problem is phttpget or the proxy, depending on the point of view.
> 
> Some proxies have (had) problems with the pipelined http requests that 
> phttpget seems to use.
> 
> apt (Debian/Ubuntu) has, too - but they can be disabled altogether 
> there.
> 
> http://webcache.googleusercontent.com/search?q=cache:OwcOVJamJOoJ:https://www
> .astaro.org/gateway-products/web-protection-web-filtering-application-visibil
> ity-control/55213-http-pipelining-broken-after-upgrade-utm-9-3-a.html+=1
> l=de=clnk=ch 
>
> IMO, there should be an option to use wget instead of phttpget. Or at 
> least disable the request-pipelining.
> There was a PR with patches floating around to make freebsd-update use 
> wget, but it never gained traction.
> 
> Also, didn't phttpget have problems with proxies needing authentication?
> I usually have authentication at the proxy disabled for *.freebsd.org 
> for this reason.
I concur, to the extent that phttpget[1] runs pretty much "blind".
As it it, phttpget blindly accepts any 200 response, and drops
any other response. What does this mean? Why would/could this be
a problem? It slurps all 200 responses; meaning; if the response
is not a file, but a web page asking for some kind of response
from you, *that's* what phttpget downloads. It also means that
if the 200 response is a web page indicating that the file you
are looking for has moved, and has a link to it's new location.
Then *that's* what phttpget downloads. The possibility's go on,
and on. But you get the picture. :)

--Chris

[1] http://www.daemonology.net/phttpget/


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: unknown file

[Chris H]

On Sat, 26 Sep 2015 17:23:43 +0200 Zoran Kolic  wrote

> Someone knows what "TsxKxSc0ySU" file is?
> This shows up in graphical mode, from time to time, today
> twice, in user directory. Binary, just over 5 kb.
> 
> Zoran
I've never seen a file with that name, but it looks like be some
sort of "temp" file often associated with a daemon (a pid file), or
some such. They're often located in /var/run, or /tmp. Have you
asked file(1) about it?

HTH

--Chris
> 
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Buildworld failure on stable

[Chris H]

On Wed, 26 Aug 2015 18:38:46 +0100 Matt Smith f...@xtaz.co.uk wrote

 On Aug 26 12:27, Matt Smith wrote:
 On Aug 26 13:10, Slawa Olhovchenkov wrote:
 Hardware error or memory exhausted
 
 It does appear to be something along those lines. It's not memory
 exhaustion as it has around 2GB free at the point it fails. However I've
 deleted /usr/obj and started the buildworld again and it failed in a
 different place with the same error. I'm trying it again without -j4 to
 see what happens. But isn't looking too good. :(
 
 Look like hardware error.
 RAM/CPU/MB
 
 Interestingly it *always* manages to succesfully compile clang etc and 
 it has no issues compiling things from ports. It fails compiling 
 something from lib like openssl or kerberos.  Doesn't buildworld build 
 a bootstrap version of clang and then use that version to compile the 
 rest of it? I might try downgrading my sources back to the version 
 that I last succesfully compiled just to prove it one way or the other 
 to myself.
 
 
 So, been doing some testing. It looks like a -j4 problem with the latest 
 sources. If I buildworld with -j1 then it compiles with no issues at 
 all. If I compile r286908 with -j4 then it compiles with no issues at 
 all. If I try and compile r287155 with -j4 then I get the bus errors. So 
 I'm not convinced at all that it's hardware related at the moment.
Not saying it is. But it still could be a region of CPU cache that
never got exercised, or in the right (same) manner.
Maybe use a CPU/RAM test program, just to be sure?

--Chris
 
 -- 
 Matt
 ___
 freebsd-stable@freebsd.org mailing list
 https://lists.freebsd.org/mailman/listinfo/freebsd-stable
 To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: 8-stable crashing recently in ufsdirhash

[Chris H]

On Wed, 05 Aug 2015 09:30:28 -1000 parv p...@bitter-almonds.com wrote

 On August 5, 2015 4:10:14 AM HST, Ian L
 wrote:
 On Tue, 2015-08-04 at 23:54 -1000, parv wrote:
  Please CC me as I cannot properly use my laptop, Thinkpad X200
 (i386).
  
  8-stable has been crashing a lot since source update of Jul 2015[0].
 After building debug kernel, kgdb shows lock reversal order  in
 ufsdirhash. File systems (/, var, misc) are all UFS, with var  misc
 having soft updates enabled.
  
  Crash had happened just after boot (during mktemp); when I tried to
 delete a directory (/misc/obj); when I tried to edit (vi /etc/fstab) so
 that / would be mounted readonly. Most recent crash ...
  
  http://imagebin.ca/v/2B50NARvIHsH
  
  Any clue would be appreciated.
 ...
 When you say you built a debug kernel, does that include option
 WITNESS_KDB?  If so, remove that so you can find the real error.  LORs
 related to ufs_dirhash have been reported for years, and nobody with
 the
 appropriate skills seems to be interested in fixing them; they just get
 declared to be harmless.
 
 I will try that as soon as I can. Currently after every little fs operation,
 I am thrown in debugger-reboot-fsck cycle. As such I cannot do anything.
 
 This is my own damn fault because the non-debug kernel would run for some
 random but meaningful amount of time before crash  reboot. I tried booting
 /boot/kernel.old/kernel from boot prompt but that presented debugger soon
 after boot. 

 BTW is it possible to set kernel.old to boot next time at boot prompt?
It might be somewhat easier to boot from the boot-only/install
CD/DVD, and then choose rescue mode.
After you've gotten there. Simply mount / in read/write, them open
it's /boot/loader.conf, and add the following:
kernel=kernel.old
boot_single=YES

and save it. You can then remove the CD/DVD, and reboot which will land
you in single-user mode, from your kernel.old/kernel.
Assuming it booted to that kernel OK, you can run fsck -f
After it finishes, don't forget to re-edit /boot/loader.conf, and
comment those lines you added earlier -- well at least:
boot_single=YES

HTH

--Chris

 
 
 -- 
 
 ___
 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-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: Swap Usage

[Chris H]

On Wed, 29 Jul 2015 17:41:33 -0700 Doug Hardie bc...@lafn.org wrote

 I have several FreeBSD 9.3 systems that are using swap and I can’t figure
 out what is doing it.  The key system has 6GB swap and currently it has over
 2GB in use.  ps shows only a kernel module [intr] with a W status.  Obviously
 that isn’t using the space.  No other process shows a W in its status.  I
 suspect this is somewhat related to the use of mmap in one application. 
 However, all of the mmaps in that application are file backed and thus
 shouldn’t use swap.  How do I figure out what that swap space is being used
 for? 
Maybe top(1)?
top -P
for example. At least you could see who's chewing all your memory. Which
should be a good clue as to who's responsible for swap usage.

--Chris

 
 ___
 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-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: 10.2-Beta i386..what's wrong..?

[Chris H]

On Fri, 24 Jul 2015 09:50:52 +0100 Matthew Seaman matt...@freebsd.org wrote

 On 07/24/15 07:58, Holm Tiffe wrote:
  ..interrestingly people here seem to focus my problem to ZFS.. but my
  problem was to build an raid over 4 disks on my old i386 machine and that
  failed with 2 different approaches.
  
  I'm accepting that ZFS is a too big thing for the i386 architecture
  and I possibly should leave it alone on that machine.
  
  But my 2nd try with gvinum failed also ...why?
 
 I've had success using a combination of gstripe and gmirror to create a
 RAID10 over 4 drives:
 
 % gstripe status
   Name  Status  Components
 stripe/st0  UP  mirror/gm2
 mirror/gm1
 % gmirror status
   NameStatus  Components
 mirror/gm2  COMPLETE  da0 (ACTIVE)
   da1 (ACTIVE)
 mirror/gm1  COMPLETE  da2 (ACTIVE)
   da3 (ACTIVE)
 
 This is a separate data area though -- system boots from some different
 drives.  I can't remember if it is possible to boot from a gstripe.
While it hasn't been since around the beginning of 8. I can confirm
it's possible to boot from a gstripe(8).

--Chris
 
 Cheers,
 
 Matthew


___
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: 10.2-Beta i386..what's wrong..?

[Chris H]

On Thu, 23 Jul 2015 23:48:06 + Glen Barber g...@freebsd.org wrote

 On Thu, Jul 23, 2015 at 07:40:42PM -0400, Jason Unovitch wrote:
   ..uh top quoting..
  
   Trying to mount root from zfs:zroot/ROOT/default [].
  
   Fatal double fault:
   eip = 0xc0b416f5
   esp = 0xe2673000
   ebp = 0xe2673008
   cpuid =0; apic id = 00
   panic: double fault
   cpuid = 0
   KDB stack backtrace:
   #0 0xc0b72832 at kdb_backtrace+0x52
   #1 0xc0b339cb at vpanic+0x11b
   #2 0xc0b338ab at panic+0x1b
   #3 0xc10556 at dblfault_handler+0xab
   Uptime: 11s
   ..
  
  Looks like the panic I received on my Soekris Net6501-70.
  
  Fixed in stable/10 in r285759:
  https://svnweb.freebsd.org/changeset/base/285759
  
  Fixed in stable/9 in r285760:
  https://svnweb.freebsd.org/changeset/base/285760
  
  
  Herbert, in https://bugs.FreeBSD.org/201642 I had tracked down the commit
  that caused the issue on our Soekris 6501s.  Only between r284297 -
  r285662 in HEAD and between r284998 - r285756 in stable/10 should be
  affected. 
  Ok, it is 10.2-BETA so I've tried 10.1-Release next...exactly the same,
  ok tried 9.3-RELEASE .. the same!
  
  Holm, if you are seeing this on 9.3-RELEASE and 10.1-RELEASE I'm not
  entirely convinced the cause is the same.
  
 
 ZFS on i386 requires KSTACK_PAGES=4 in the kernel configuration to work
 properly, as noted in the 10.1-RELEASE errata (and release notes, if
 I remember correctly).
 
 We cannot set KSTACK_PAGES=4 in GENERIC by default, as it is too
 disruptive.  If you are using ZFS on i386, you *must* build your own
 kernel for this.  It is otherwise unsupported by default.
Shouldn't there be a GENERIC kernel with the KSTACK_PAGES=4 option
defined, available? Maybe with one of the bootonly MEMSTICKS, or
something? I know, it's (mostly) crazy to attempt ZFS on an i386. But
it's pretty difficult for someone on 8.x to build a 9.x, or 10.x kernel.
If all they've got is i386 hardware.

Just a thought.

--Chris
 
 Glen


___
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: 10.2-Beta i386..what's wrong..?

[Chris H]

On Fri, 24 Jul 2015 01:00:03 + Glen Barber g...@freebsd.org wrote
..
 FreeBSD kernel grew since 10.1-RELEASE, so this is not unexpected.
Not trying to hijack the thread, or anything.
But on that note; does FreeBSD keep a graph, or anything that indicates
kernel [size] over major versions?

I'm sure I'm not the only one that would find this interesting. :)

--Chris
 
 Glen


___
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: How to track stable on multiple servers?

[Chris H]

On Mon, 1 Jun 2015 16:19:46 +0300 Kimmo Paasiala kpaas...@gmail.com wrote

 On Mon, Jun 1, 2015 at 4:10 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote:
  I have some set of FreeBSD servers in public internet and continue to
  find optimal way for track -stable branch.
 
  Handbook give next metods:
 
  1. Tracking -security branch by freebsd-update.
 I want -stable, -security don't have wanted features.
 
  2. svn  rebuilding world localy. To long and wery badly automated,
 bad version synchronisation between servers.
 
  3. svn  rebuilding world on build server, install localy by NFS.
 Servers in public internet, I am to be  afraid exposing NFS to
 public internet. Also, need to have localy /etc/{make,src}.conf in
 sync with build server. Also badly automated.
 
  4. Build private freebsd-update-server and build (simularity to
 security btanch) updates for -stable.
 Need essentially dedicated server -- during build system time
 changed and this is may be raise side effects.
 freebsd-update work wery long time (hours) and accumulate a lot of
 garbage:
 
  # du -ms /var/db/freebsd-update/
  2010/var/db/freebsd-update/
 
 freebsd-update-server/freebsd-update too bugly and debuggint is not
 easy.
 config mergering working worse mergemaster.
 Don't allow to repair damaged files (freebsd-update IDS detect
 changes but don't repair this).
 
  5. nanobsd.
 Don't automatic save /etc and etc.
 pkg updated throw system image update and reboot. Unaccpetable.
 
 
  Something else?
 
 
 When I had to something like this I went with option 3. It's not
 completely automated as you say because of /etc/(make|src).conf but
 there are no better options at the moment because /usr/obj is not
 self contained because its contents and interpretation depends on
 auxillary files, the /etc/make.conf and /etc/src.conf files.
 
 -Kimmo
I go with a variation of option 3, using jails, and a combination of
building packages, and using dump(8), and restore(8) (when needed).

--Chris
 ___
 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-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: [CFT] Call for testing pkg 1.5.0

[Chris H]

On Tue, 31 Mar 2015 21:03:23 +0200 Baptiste Daroussin b...@freebsd.org wrote

 Hi all,
 
 We just released pkg 1.5.0 beta1 (in ports-mgmt/pkg-devel),
 
..
 Please test and report as much bugs as you can!
 We could be very grateful if regressions tests could be provided along with
 the bug reports :)
 
 Plan is to release 1.5.0 as soon as possible
 
 Best regards,
 Bapt
Hello, Baptiste.
I just wanted to take the time to thank you for all the
work you've put into this.

Thanks!

--Chris


___
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: Significant memory leak in 9.3p10?

[Chris H]

On Thu, 26 Mar 2015 14:03:45 -0700 Kevin Oberman rkober...@gmail.com wrote

 On Thu, Mar 26, 2015 at 12:46 PM, J David j.david.li...@gmail.com wrote:
 
  On Mon, Mar 16, 2015 at 7:52 PM, J David j.david.li...@gmail.com wrote:
   On Mon, Mar 16, 2015 at 7:24 PM, Konstantin Belousov
   kostik...@gmail.com wrote:
   There are a lot of possibilities to create persistent anonymous shared
   memory objects.  Not complete list is tmpfs mounts, swap-backed md
  disks,
   sysv shared memory, possibly posix shared memory (I do not remember
  which
   implementation is used in stable/9).
  
   If that's the explanation, how could it be
   detected/measured/investigated/resolved/prevented?
  
   Under ordinary circumstances, machines will go run like this for
  days/weeks:
  
   Mem: 549M Active, 3623M Inact, 567M Wired, 3484K Cache, 827M Buf, 3156M
  Free
   Swap: 1024M Total, 1024M Free
  
   Then, when this happens, it rapidly degrades from that to so bad that
   processes start getting killed for being out of swap space.
 
  These FreeBSD machines running out of swap space and dying continues
  to be a daily problem causing outages and unscheduled reboots.  Is
  there really no way to even research what might be causing the
  problem?
 
  (Widening the cross-posting in the hopes of eliciting more help, so
  the brief summary of the problem orginally posted to freebsd-stable is
  that an unknown actor consumes all the user-space memory in the
  system, including swap space, to the point where processes are killed
  for being out of swap space, but if every process on the machine is
  stopped, very little of the user-space memory in use is freed.
  Original message with more details is here:
  https://lists.freebsd.org/pipermail/freebsd-stable/2015-March/081986.html
  .)
 
  There are no tmpfs mounts or md disks, so it would have to be one of
  the other causes.  How can FreeBSD's use of persistent, anonymous
  shared memory objects be investigated, measured, or controlled so we
  can get a handle on this issue?
 
 
 This is just a shot in the dark and not a really likely one, but I have had
 issues with Firefox leaking memory badly. I can free the space by killing
 firefox and restarting it.
 
 It seems to be linked to certain web sites, probably javascript. I have not
 been able to confirm which one does it. It just will start growing until
 the system slows to a crawl as too many things are swapped out. Normally my
 system does not touch swap.
I can confirm this -- both regular, as well as ESR. Upgrading firefox
[ultimately] has little-to-no effect. I have experienced this for near
2yrs. I suspect the [firefoxes] js engine. Any one of any number of
sites could/would/will cause it.

As Kevin already noted; stopping firefox, and starting it again,
seems the only solution.
 
 If it is in user space, top should show it under RES.
 --
 Kevin Oberman, Network Engineer, Retired
 E-mail: rkober...@gmail.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

--Chris


___
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: Significant memory leak in 9.3p10?

[Chris H]

On Thu, 26 Mar 2015 20:28:15 -0400 J David j.david.li...@gmail.com wrote

 On Thu, Mar 26, 2015 at 8:25 PM, Chris H bsd-li...@bsdforge.com wrote:
  As Kevin already noted; stopping firefox, and starting it again,
  seems the only solution.
 
 The machines in questions are servers, they do not run Firefox or any
 GUI.  And whatever is using the memory does not show up on ps or top.
Fair enough. I'm still getting caught up, on the thread.

Maybe another shot in the dark. But speaking of Servers. We
ran into trouble with a web server generating *enormous* error
logs -- a runaway script. The result was, even tho there was
far more than adequate space for the swelling log(s). Memory,
and eventually Swap usage, began to climb quite steadily.

Like I said; maybe a shot in the dark. But just thought I'd
mention it.
 
 Thanks!
--Chris

--


___
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: There has to be a better way of merging /etc during a major freebsd-update

[Chris H]

On Tue, 10 Mar 2015 14:08:21 -0500 Adam Vande More amvandem...@gmail.com
wrote

 On Tue, Mar 10, 2015 at 2:01 PM, Chris H bsd-li...@bsdforge.com wrote:
 
   
  
   https://svnweb.freebsd.org/base?view=revisionrevision=221780
  
   I'd venture to guess the script will work fine on older installs, but
   testing should be done first.
  Isn't that pretty much what the -F flag, I mentioned does?
  -FIf the files differ only by VCS Id ($FreeBSD) install the
 new file.
 
 
 Op asked for a freebsd-update solution which excludes any mergemaster
 solution short of at least a partial rewrite.
Ahem... right you are! Speaking of reading things, it'd
kill me to read more closely, before replying. :P
Sorry, Adam.

--Chris
 
 -- 
 Adam
 ___
 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-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: No sound on 10.1-RELEASE

[Chris H]

On Wed, 11 Mar 2015 23:09:31 +0100 Piotr Kubaj pku...@riseup.net wrote

 On 03/11/15 02:12, Chris H wrote:
  On Tue, 10 Mar 2015 12:15:22 +0100 Piotr Kubaj pku...@riseup.net wrote
  
  On 03/08/15 22:15, Chris H wrote:
  On Sun, 08 Mar 2015 19:14:47 +0100 Piotr Kubaj pku...@riseup.net wrote
 
  On 03/07/15 01:55, Chris H wrote:
  On Sat, 07 Mar 2015 00:08:38 +0100 Piotr Kubaj pku...@riseup.net
  wrote 
  I've got MSI X99 motherboard and am using it with UEFI installation of
  8---BIG-SNIP---
 
  I'm not sure what may be wrong in dmesg.boot so I've uploaded it here:
  http://pastebin.com/pP0KXp4v
  Out of the 4 MSI boards I that I have; 3 run the same
  Realtek ALC893 HDA CODEC that yours does. The other, the
  Realtek ALC1200 HDA CODEC. All four of them work. But I
  notice 1 notable difference; that yours reports 2
  HDA interfaces:
  hdac0: NVIDIA (0x0fbb) HDA Controller
  and
  hdac1: Intel Wellsburg HDA Controller
  I see hdac0 is disregarded (unused) whereas
  hdac1 is enabled, and functioning. I think your problems
  quite possibly lies in your (sound) system attempting to
  use the first HDA device in the list, which is effectively
  disabled. If you can determine a way to tell KDE, and friends
  to use the 2nd HDA. Things may well go as intended.
  None of the 4 MSI boards I have display 2 HDA's, as yours
  does.
  If you have any additional questions, you may well find
  the FreeBSD forums already have answers to your issue. This
  is where I originally found answers to my issues, when I
  first started using these boards.
 
  HTH
 
  KDE is definitely using OSS as chosen in its settings (I also use its
  own mixer which can do the same as Xfce's). I also use VLC's Phonon
  backend because Gstreamer is said to cause problems, but that also works
  on 3 other computers.
 
  I don't think it's KDE's fault, as it also happens when I kill KDE
  (service kdm4 stop) and do cat /dev/random  /dev/dsp. Of course, I have
  vol and pcm maxed out.
  If your speakers are amplified, you should hear them pop,
  when the kernel finds, and creates/attaches the driver(s) to
  it. Same would be true, if you were wearing your headphones
  when bouncing your box.
  I'm quite sure that the sound system is defaulting the the first
  HDA presented. Which, in your case, is the one that is disabled/
  non-operational. It's not KDE per se; but how the software
  decides, by default, to hook sound up. If you had a sound
  control panel available in KDE. You *should* be able to
  *choose* which sound device to use. In your case, provided
  it's even seen, it would be the *2nd* HDA. The sound control
  panel should also present the *status* of the sound device
  that it's using. Which, in your case, would indicate everything
  as being muted, and/or unavailable.
  On the box I'm writing this from, the HDA/CODEC is the
  Realtek ALC893, as yours is. I have it hooked up to a 700 watt
  external amplifier that I use as sound for my entire house.
  With the amplifier turned on, if I bounce the box (reboot)
  I hear a pop when the kernel detects/attaches to the
  sound chip. These are the relevant, and only sound related
  devices, created/listed in /dev:
  
  cd0
  
  dsp0.0
  dsp1.0
  dsp2.0
  dsp4.0
  
  midistat
  mixer0
  mixer1
  mixer2
  mixer4
  
  sndstat
  
  If I'm not mistaken, you're probably running GENERIC, which
  has *also* loaded snd_hda, and possibly/probably, others.
  Which accounts for the additional HDA listing in dmesg(8).
  What I would do, if I were you, is build/install a
  custom kernel, stripped of any device not available
  on your MB. This is the first thing I do, after a fresh
  install, and, as you're discovering, for good reason. :)
  You should also find, by doing so, that your system performs
  much better, as a result.
  The *only* sound related listings I have in my KERNCONF file,
  is:
  speaker # PC beeper
  sound # geneic sound
  snd_hda # Realtec CODEC HDA
  Last, and only because I have to say it;
  you *are* sure that you have your headphones/speakers
  plugged into the *correct* jack, right? ;-)
  Hey! It happens. :)
  
  --Chris
  
  --
  
  
 I've deleted all other drivers except for snd_hda and sound but NVIDIA
 interfaces also use snd_hda driver. Also, I have already set up
 hw.snd.default_unit=4, which is the analog Intel interface (included in
 my 1st mail). I'm not sure how I should choose the default device in
 KDE, since it's chosen in hw.snd.default_unit. I'm not sure how you are
 able to hear a pop when sound devices are detected because it doesn't
 work that way on any of my other PC's (6 in total).
Well, I'm only able to share my own experiences. The 3 with Realtek
chips, all make a light pop sound during boot. The one I happen to be
writing this from emits the following in dmesg(8)

hdacc0: Realtek ALC1200 HDA CODEC at cad 0 on hdac0
hdaa0: Realtek ALC1200 Audio Function Group at nid 1 on hdacc0
hdaa0: Subsystem ID: 0x103c2a72

pcm0: Realtek ALC1200 (Analog 2.0+HP/2.0

Re: No sound on 10.1-RELEASE

[Chris H]

On Wed, 11 Mar 2015 23:34:30 +0100 Piotr Kubaj pku...@riseup.net wrote

 On 03/11/15 02:12, Chris H wrote:
  On Tue, 10 Mar 2015 12:15:22 +0100 Piotr Kubaj pku...@riseup.net wrote
  
  On 03/08/15 22:15, Chris H wrote:
  On Sun, 08 Mar 2015 19:14:47 +0100 Piotr Kubaj pku...@riseup.net wrote
 
  On 03/07/15 01:55, Chris H wrote:
  On Sat, 07 Mar 2015 00:08:38 +0100 Piotr Kubaj pku...@riseup.net
  wrote 
  I've got MSI X99 motherboard and am using it with UEFI installation of
  8---BIG-SNIP---
 
  I'm not sure what may be wrong in dmesg.boot so I've uploaded it here:
  http://pastebin.com/pP0KXp4v
  Out of the 4 MSI boards I that I have; 3 run the same
  Realtek ALC893 HDA CODEC that yours does. The other, the
  Realtek ALC1200 HDA CODEC. All four of them work. But I
  notice 1 notable difference; that yours reports 2
  HDA interfaces:
  hdac0: NVIDIA (0x0fbb) HDA Controller
  and
  hdac1: Intel Wellsburg HDA Controller
  I see hdac0 is disregarded (unused) whereas
  hdac1 is enabled, and functioning. I think your problems
  quite possibly lies in your (sound) system attempting to
  use the first HDA device in the list, which is effectively
  disabled. If you can determine a way to tell KDE, and friends
  to use the 2nd HDA. Things may well go as intended.
  None of the 4 MSI boards I have display 2 HDA's, as yours
  does.
  If you have any additional questions, you may well find
  the FreeBSD forums already have answers to your issue. This
  is where I originally found answers to my issues, when I
  first started using these boards.
 
  HTH
 
  KDE is definitely using OSS as chosen in its settings (I also use its
  own mixer which can do the same as Xfce's). I also use VLC's Phonon
  backend because Gstreamer is said to cause problems, but that also works
  on 3 other computers.
 
  I don't think it's KDE's fault, as it also happens when I kill KDE
  (service kdm4 stop) and do cat /dev/random  /dev/dsp. Of course, I have
  vol and pcm maxed out.
  If your speakers are amplified, you should hear them pop,
  when the kernel finds, and creates/attaches the driver(s) to
  it. Same would be true, if you were wearing your headphones
  when bouncing your box.
  I'm quite sure that the sound system is defaulting the the first
  HDA presented. Which, in your case, is the one that is disabled/
  non-operational. It's not KDE per se; but how the software
  decides, by default, to hook sound up. If you had a sound
  control panel available in KDE. You *should* be able to
  *choose* which sound device to use. In your case, provided
  it's even seen, it would be the *2nd* HDA. The sound control
  panel should also present the *status* of the sound device
  that it's using. Which, in your case, would indicate everything
  as being muted, and/or unavailable.
  On the box I'm writing this from, the HDA/CODEC is the
  Realtek ALC893, as yours is. I have it hooked up to a 700 watt
  external amplifier that I use as sound for my entire house.
  With the amplifier turned on, if I bounce the box (reboot)
  I hear a pop when the kernel detects/attaches to the
  sound chip. These are the relevant, and only sound related
  devices, created/listed in /dev:
  
  cd0
  
  dsp0.0
  dsp1.0
  dsp2.0
  dsp4.0
  
  midistat
  mixer0
  mixer1
  mixer2
  mixer4
  
  sndstat
  
  If I'm not mistaken, you're probably running GENERIC, which
  has *also* loaded snd_hda, and possibly/probably, others.
  Which accounts for the additional HDA listing in dmesg(8).
  What I would do, if I were you, is build/install a
  custom kernel, stripped of any device not available
  on your MB. This is the first thing I do, after a fresh
  install, and, as you're discovering, for good reason. :)
  You should also find, by doing so, that your system performs
  much better, as a result.
  The *only* sound related listings I have in my KERNCONF file,
  is:
  speaker # PC beeper
  sound # geneic sound
  snd_hda # Realtec CODEC HDA
  Last, and only because I have to say it;
  you *are* sure that you have your headphones/speakers
  plugged into the *correct* jack, right? ;-)
  Hey! It happens. :)
  
  --Chris
  
  --
  
  
 A small update: I can set hw.snd.default_unit=5 and sound works through
 the front panel, but not so through the back panel. I have tried any
 other value from 0 to 7 and the sound works with the back panel on
 Windows so it's connected properly.
Good(ish) news. I just recalled something that might prove
somewhat helpful in diagnosing your issue. I don't know
about yours; but if I unplug the speakers, or headphones, I
get a lot of noise on the console, regarding the event. It
indicated what was disconnected in such a way, that you might
well be able to compare the output with that of dmesg, to find
out what == what.

All the best.

--Chris

--


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable

Re: There has to be a better way of merging /etc during a major freebsd-update

[Chris H]

On Tue, 10 Mar 2015 13:05:40 +0100 Peter Olsson list-freebsd-sta...@jyborn.se
wrote

 This flag to mergemaster saved a lot of work when I did
 upgrades the old way, with cvsup and the make steps and
 then mergemaster:
 
 # Install the new file if it differs only by VCS Id ($FreeBSD)
 FREEBSD_ID=yes
 
 Is there some equivalent to this flag in freebsd-update/merge?
Hello, Peter.
This has probably been answered by now. But just in case.
I believe what you're looking for is:
mergemaster -vF

This is my [chosen] default. I also find it helpful,
as a safety net to
cp _Rp /etc /eetc

prior to the mergemaster(8) step.

On a related note. I'm not very fond of mergemaster. As
a result, I recently took on maintaining
sysutils/etcmerge. sysutils/etcupdate, is also a
[mergemaster] related port.

Hope this helps.

--Chris
 
 I just did my first major upgrade (8.4-RELEASE-p24 -
 9.3-RELEASE-p10) with freebsd-update. It took more than
 an hour of manual keyboard activity, most of which could
 probably be done automatically. (And here I thought that
 computers were supposed to free us from tedious routine
 work...)
 
 First robotically pressing dd..j.ZZ in a lot of files.
 Occasionally combined with / to find more places that
 needed changing in files that didn't fit in the screen.
 Eg sendmail.cf.
 
 Of all these files that needed manual editing I had made
 my own changes in only one file (/etc/hosts), the rest of
 them just had this kind of change:
 
 The following file could not be merged automatically: /etc/rc.d/nisdomain
 Press Enter to edit this file in vi and resolve the conflicts
 manually...
 
  current version
 # $FreeBSD: src/etc/rc.d/nisdomain,v 1.5.2.2 2013/03/28 13:02:44 svnexp Exp $
 ===
 # $FreeBSD: releng/9.3/etc/rc.d/nisdomain 193197 2009-06-01 04:55:13Z dougb $
  9.3-RELEASE
 
 And then, after all these edits, I had to wade through entering
 y to Does this look reasonable (y/n)? for all these files!
 This is of course a necessary step to avoid being bitten by
 any  ===  lines left behind by mistake (easy to do when
 you lose your concentration after more than a hundred files),
 but most of this step could be entirely avoided by automatically
 accepting the ID changes.
 (I amused myself by counting all files during this stage.
 I had to answer y to about 320 files, most of which only
 had changes in the ID.)
 
 This was my first upgrade from 8.4 to 9.3. I have 30 more to go
 before the 8.4 EoL this summer. I see 30 completely unnecessarily
 wasted hours in my future...
 And think of the combined lost man hours worldwide in these upgrades!
 Merge seems to be a really stupid choice for major upgrades.
 (Unless of course there is some flag to freebsd-update which makes
 this kind of change automatically accepted. But I see no such flag
 in man freebsd-update in 8.4, 9.3 or 10.1.)
 
 And yes, I could maybe copy most of /etc from the first
 upgraded server to the rest of them before upgrading, but
 that seems error-prone and not really a good solution for
 every FreeBSD user.
 
 -- 
 Peter Olsson
 ___
 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-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: No sound on 10.1-RELEASE

[Chris H]

On Tue, 10 Mar 2015 12:15:22 +0100 Piotr Kubaj pku...@riseup.net wrote

 On 03/08/15 22:15, Chris H wrote:
  On Sun, 08 Mar 2015 19:14:47 +0100 Piotr Kubaj pku...@riseup.net wrote
  
  On 03/07/15 01:55, Chris H wrote:
  On Sat, 07 Mar 2015 00:08:38 +0100 Piotr Kubaj pku...@riseup.net wrote
 
  I've got MSI X99 motherboard and am using it with UEFI installation of
8---BIG-SNIP---
 
  I'm not sure what may be wrong in dmesg.boot so I've uploaded it here:
  http://pastebin.com/pP0KXp4v
  Out of the 4 MSI boards I that I have; 3 run the same
  Realtek ALC893 HDA CODEC that yours does. The other, the
  Realtek ALC1200 HDA CODEC. All four of them work. But I
  notice 1 notable difference; that yours reports 2
  HDA interfaces:
  hdac0: NVIDIA (0x0fbb) HDA Controller
  and
  hdac1: Intel Wellsburg HDA Controller
  I see hdac0 is disregarded (unused) whereas
  hdac1 is enabled, and functioning. I think your problems
  quite possibly lies in your (sound) system attempting to
  use the first HDA device in the list, which is effectively
  disabled. If you can determine a way to tell KDE, and friends
  to use the 2nd HDA. Things may well go as intended.
  None of the 4 MSI boards I have display 2 HDA's, as yours
  does.
  If you have any additional questions, you may well find
  the FreeBSD forums already have answers to your issue. This
  is where I originally found answers to my issues, when I
  first started using these boards.
  
  HTH
 
  KDE is definitely using OSS as chosen in its settings (I also use its
  own mixer which can do the same as Xfce's). I also use VLC's Phonon
  backend because Gstreamer is said to cause problems, but that also works
  on 3 other computers.
  
 I don't think it's KDE's fault, as it also happens when I kill KDE
 (service kdm4 stop) and do cat /dev/random  /dev/dsp. Of course, I have
 vol and pcm maxed out.
If your speakers are amplified, you should hear them pop,
when the kernel finds, and creates/attaches the driver(s) to
it. Same would be true, if you were wearing your headphones
when bouncing your box.
I'm quite sure that the sound system is defaulting the the first
HDA presented. Which, in your case, is the one that is disabled/
non-operational. It's not KDE per se; but how the software
decides, by default, to hook sound up. If you had a sound
control panel available in KDE. You *should* be able to
*choose* which sound device to use. In your case, provided
it's even seen, it would be the *2nd* HDA. The sound control
panel should also present the *status* of the sound device
that it's using. Which, in your case, would indicate everything
as being muted, and/or unavailable.
On the box I'm writing this from, the HDA/CODEC is the
Realtek ALC893, as yours is. I have it hooked up to a 700 watt
external amplifier that I use as sound for my entire house.
With the amplifier turned on, if I bounce the box (reboot)
I hear a pop when the kernel detects/attaches to the
sound chip. These are the relevant, and only sound related
devices, created/listed in /dev:

cd0

dsp0.0
dsp1.0
dsp2.0
dsp4.0

midistat
mixer0
mixer1
mixer2
mixer4

sndstat

If I'm not mistaken, you're probably running GENERIC, which
has *also* loaded snd_hda, and possibly/probably, others.
Which accounts for the additional HDA listing in dmesg(8).
What I would do, if I were you, is build/install a
custom kernel, stripped of any device not available
on your MB. This is the first thing I do, after a fresh
install, and, as you're discovering, for good reason. :)
You should also find, by doing so, that your system performs
much better, as a result.
The *only* sound related listings I have in my KERNCONF file,
is:
speaker # PC beeper
sound # geneic sound
snd_hda # Realtec CODEC HDA
Last, and only because I have to say it;
you *are* sure that you have your headphones/speakers
plugged into the *correct* jack, right? ;-)
Hey! It happens. :)

--Chris

--


___
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: There has to be a better way of merging /etc during a major freebsd-update

[Chris H]

On Tue, 10 Mar 2015 06:58:07 -0700 Chris H bsd-li...@bsdforge.com wrote

 On Tue, 10 Mar 2015 13:05:40 +0100 Peter Olsson
 list-freebsd-sta...@jyborn.se wrote
 
  This flag to mergemaster saved a lot of work when I did
  upgrades the old way, with cvsup and the make steps and
  then mergemaster:
  
  # Install the new file if it differs only by VCS Id ($FreeBSD)
  FREEBSD_ID=yes
  
  Is there some equivalent to this flag in freebsd-update/merge?
 Hello, Peter.
 This has probably been answered by now. But just in case.
 I believe what you're looking for is:
 mergemaster -vF
 
 This is my [chosen] default. I also find it helpful,
 as a safety net to
 cp _Rp /etc /eetc
Ahem... On the off chance it wasn't obvious.
The above line /should/ have read
cp -Rp /etc /eetc
___^

Sorry.

--Chris
 
 prior to the mergemaster(8) step.
 
 On a related note. I'm not very fond of mergemaster. As
 a result, I recently took on maintaining
 sysutils/etcmerge. sysutils/etcupdate, is also a
 [mergemaster] related port.
 
 Hope this helps.
 
 --Chris
  
  I just did my first major upgrade (8.4-RELEASE-p24 -
  9.3-RELEASE-p10) with freebsd-update. It took more than
..
  
  -- 
  Peter Olsson
  ___
  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-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-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: There has to be a better way of merging /etc during a major freebsd-update

[Chris H]

On Tue, 10 Mar 2015 10:17:18 -0500 Adam Vande More amvandem...@gmail.com
wrote

 On Tue, Mar 10, 2015 at 7:05 AM, Peter Olsson list-freebsd-sta...@jyborn.se
  wrote:
 
  This flag to mergemaster saved a lot of work when I did
  upgrades the old way, with cvsup and the make steps and
  then mergemaster:
 
 
 https://svnweb.freebsd.org/base?view=revisionrevision=221780
 
 I'd venture to guess the script will work fine on older installs, but
 testing should be done first.
Isn't that pretty much what the -F flag, I mentioned does?
-FIf the files differ only by VCS Id ($FreeBSD) install the
   new file.
In all honesty, I too got stuck answering y ~100 times, way
back when. And decided I needed to either find a better way,
or see if the mergemaster(8) had any secrets I wasn't
aware of. ;-)

--Chris
 
 -- 
 Adam
 ___
 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-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: Is there a linux_base available for RELENG_9?

[Chris H]

On Tue, 10 Mar 2015 11:29:12 + Pete French petefre...@ingresso.co.uk
wrote

  Indeed. Having read UPDATING prior to the attempted upgrade, I
  followed the advise to add 'compat.linux.osrelease=2.6.18'
  to sysctl.conf(5). And rebooted.
 
 If you rebooted then it should have been set - and you should
 not have needed to do it manually.
 
  But what turned out to be the *actual* solution, was to use
  sysctl(8). Applying it directly fixed it. :-)
 
 This should not have been necessary if you rebooted. I think
 you should try and find out what went wrong, as otherwise this
 will not work when you reboot next time and you will have to set it
 by hand on each reboot.
 
 It sounds like you did all the right things - nt sure why it didnt
 work for you.
 
 Have you rebooted since ? What is the value after rebooting now ?
Hello Peter, and thank you for the reply.
I only just now got a chance to bounce the box.
I first
sysctl compat.linux.osrelease=2.6.16
as that's what it reported, after the [kern/world] install,
and before/during my attempts to install -c6.
I then confirmed the setting via sysctl, then confirmed
sysctl.conf(5) had the
sysctl compat.linux.osrelease=2.6.18
setting listed. Bounced the box, and the sysctl.conf
settings took. I have absolutely no idea why it wouldn't
work as stated in UPDATING, or after loading it in
sysctl.conf, yesterday. But it *apparently* works now.
I think, under the circumstances, I'd do well to
continue to monitor that setting for awhile. Fortunately,
given it's FreeBSD, and a server, I won't have a need
to bounce it very often.

Thanks again, Peter, for taking the time to reply.

--Chris
 
 -pete.
 ___
 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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Is there a linux_base available for RELENG_9?

[Chris H]

I performed av svn update for both src (r279796),
and ports (r380829) last night. building/installing
world/kernel, went as one would hope. Upgrading ports
was a different story. Given this box has an nVidia card.
I usually start by upgrading emulators/linux_base; which
according to UPDATING; meant linux_base-f10 -- linux_base-c6.
I deinstalled x11/nvidia-driver, followed by
emulators/linux_base-f10. I then attempted to make install
emulators/linux_base-c6, which resulted in a message
that it wasn't supported. So I simply cd'd to
emulators/linux_base-f10, followed by make install. Which
resulted in a CVE message; indicating it was vulnerable
to glib issues. I'm now stuck w/o hardware support for
my video card, and unable to effectively follow
a safe port upgrade path, that enables me to keep the
options I have chosen for my currently installed ports.
Is there a *safe* linux_base available?

Thank you for all your time, and consideration.

--Chris

--


___
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: Is there a linux_base available for RELENG_9?

[Chris H]

On Mon, 09 Mar 2015 20:45:11 -0400 Adam McDougall mcdou...@egr.msu.edu wrote

 On 03/09/2015 20:44, Chris H wrote:
  I performed av svn update for both src (r279796),
  and ports (r380829) last night. building/installing
  world/kernel, went as one would hope. Upgrading ports
  was a different story. Given this box has an nVidia card.
  I usually start by upgrading emulators/linux_base; which
  according to UPDATING; meant linux_base-f10 -- linux_base-c6.
  I deinstalled x11/nvidia-driver, followed by
  emulators/linux_base-f10. I then attempted to make install
  emulators/linux_base-c6, which resulted in a message
  that it wasn't supported.
 
 What was the exact error?
Thank you very much for the reply, Adam.
It was:
===  linux_base-f10-10_9 has known vulnerabilities:
linux_base-f10-10_9 is vulnerable:
glibc -- gethostbyname buffer overflow
CVE: CVE-2015-0235
WWW: http://portaudit.FreeBSD.org/0765de84-a6c1-11e4-a0c1-c485083ca99c.html

Thanks, again!

--Chris
 
 ___
 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-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: Is there a linux_base available for RELENG_9?

[Chris H]

On Mon, 9 Mar 2015 18:41:59 -0700 Freddie Cash fjwc...@gmail.com wrote

 Re-read the error message you pasted into the email. Pay particular
 attention to the part after 2.6, the last two digits. :)
 
 2.6.16 != 2.6.18
 
 The latter is what needs to be in sysctl.conf, or (as you discovered)
 entered via sysctl(8). You will need to put the correct values into
 sysctl.conf, though, for it to be set correctly at boot.
Indeed. Having read UPDATING prior to the attempted upgrade, I
followed the advise to add 'compat.linux.osrelease=2.6.18'
to sysctl.conf(5). And rebooted.
But what turned out to be the *actual* solution, was to use
sysctl(8). Applying it directly fixed it. :-)

Maybe update UPDATING? ;-)

--Chris
 
 Cheers,
 Freddie
 On Mar 9, 2015 6:07 PM, Chris H bsd-li...@bsdforge.com wrote:
 
  On Tue, 10 Mar 2015 00:51:06 + Gary Palmer gpal...@freebsd.org wrote
 
   On Mon, Mar 09, 2015 at 05:44:55PM -0700, Chris H wrote:
I performed av svn update for both src (r279796),
and ports (r380829) last night. building/installing
world/kernel, went as one would hope. Upgrading ports
was a different story. Given this box has an nVidia card.
I usually start by upgrading emulators/linux_base; which
according to UPDATING; meant linux_base-f10 -- linux_base-c6.
I deinstalled x11/nvidia-driver, followed by
emulators/linux_base-f10. I then attempted to make install
emulators/linux_base-c6, which resulted in a message
that it wasn't supported. So I simply cd'd to
emulators/linux_base-f10, followed by make install. Which
resulted in a CVE message; indicating it was vulnerable
to glib issues. I'm now stuck w/o hardware support for
my video card, and unable to effectively follow
a safe port upgrade path, that enables me to keep the
options I have chosen for my currently installed ports.
Is there a *safe* linux_base available?
   
Thank you for all your time, and consideration.
  
   If you set
  
   sysctl compat.linux.osrelease=2.6.18
  
   you can install linux_base-c6 on RELENG_9
  
   It works well enough at least for nvidia-driver, as my main desktop
   is 9.3-RELEASE-p9 and has nvidia-driver and linux_base-c6-6.6_3
   installed
  
   Remember to put
  
   compat.linux.osrelease=2.6.18
  
   into /etc/sysctl.conf so it's preserved on startup
  
   I believe if you read the message from linux_base-c6 that's basically
   what it told you to do.
  Thanks for the reply, Gary.
  Right you are. That's exactly what I did to stage for the upgrade;
  entered 'compat.linux.osrelease=2.6.18' into etc/sysctl.conf
  rebooted, deinstalled x11/nvidia-driver, emulators/linux_base-f10,
  cd emulators/linux_base-c6; make install
  which led to:
  ===  linux_base-c6-6.6_3 compat.linux.osrelease: 2.6.16 is not supported,
  please use 2.6.18, BEWARE this is highly experimental.
  *** [all] Error code 1
 
  Stop in /usr/ports/emulators/linux_base-c6.
 
  Thanks! and sorry for not being more detailed in the first place.
 
  --Chris
  
   Regards,
  
   Gary
   ___
   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-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-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: Is there a linux_base available for RELENG_9?

[Chris H]

On Tue, 10 Mar 2015 00:51:06 + Gary Palmer gpal...@freebsd.org wrote

 On Mon, Mar 09, 2015 at 05:44:55PM -0700, Chris H wrote:
  I performed av svn update for both src (r279796),
  and ports (r380829) last night. building/installing
  world/kernel, went as one would hope. Upgrading ports
  was a different story. Given this box has an nVidia card.
  I usually start by upgrading emulators/linux_base; which
  according to UPDATING; meant linux_base-f10 -- linux_base-c6.
  I deinstalled x11/nvidia-driver, followed by
  emulators/linux_base-f10. I then attempted to make install
  emulators/linux_base-c6, which resulted in a message
  that it wasn't supported. So I simply cd'd to
  emulators/linux_base-f10, followed by make install. Which
  resulted in a CVE message; indicating it was vulnerable
  to glib issues. I'm now stuck w/o hardware support for
  my video card, and unable to effectively follow
  a safe port upgrade path, that enables me to keep the
  options I have chosen for my currently installed ports.
  Is there a *safe* linux_base available?
  
  Thank you for all your time, and consideration.
 
 If you set
 
 sysctl compat.linux.osrelease=2.6.18
 
 you can install linux_base-c6 on RELENG_9
 
 It works well enough at least for nvidia-driver, as my main desktop
 is 9.3-RELEASE-p9 and has nvidia-driver and linux_base-c6-6.6_3 
 installed
 
 Remember to put
 
 compat.linux.osrelease=2.6.18
 
 into /etc/sysctl.conf so it's preserved on startup
 
 I believe if you read the message from linux_base-c6 that's basically
 what it told you to do.
Thanks for the reply, Gary.
Right you are. That's exactly what I did to stage for the upgrade;
entered 'compat.linux.osrelease=2.6.18' into etc/sysctl.conf
rebooted, deinstalled x11/nvidia-driver, emulators/linux_base-f10,
cd emulators/linux_base-c6; make install
which led to:
===  linux_base-c6-6.6_3 compat.linux.osrelease: 2.6.16 is not supported,
please use 2.6.18, BEWARE this is highly experimental.
*** [all] Error code 1

Stop in /usr/ports/emulators/linux_base-c6.

Thanks! and sorry for not being more detailed in the first place.

--Chris
 
 Regards,
 
 Gary
 ___
 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-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: Is there a linux_base available for RELENG_9?

[Chris H]

On Tue, 10 Mar 2015 01:11:10 + Gary Palmer gpal...@freebsd.org wrote

 On Mon, Mar 09, 2015 at 06:09:04PM -0700, Chris H wrote:
  On Tue, 10 Mar 2015 00:51:06 + Gary Palmer gpal...@freebsd.org wrote
  
   On Mon, Mar 09, 2015 at 05:44:55PM -0700, Chris H wrote:
I performed av svn update for both src (r279796),
and ports (r380829) last night. building/installing
world/kernel, went as one would hope. Upgrading ports
was a different story. Given this box has an nVidia card.
I usually start by upgrading emulators/linux_base; which
according to UPDATING; meant linux_base-f10 -- linux_base-c6.
I deinstalled x11/nvidia-driver, followed by
emulators/linux_base-f10. I then attempted to make install
emulators/linux_base-c6, which resulted in a message
that it wasn't supported. So I simply cd'd to
emulators/linux_base-f10, followed by make install. Which
resulted in a CVE message; indicating it was vulnerable
to glib issues. I'm now stuck w/o hardware support for
my video card, and unable to effectively follow
a safe port upgrade path, that enables me to keep the
options I have chosen for my currently installed ports.
Is there a *safe* linux_base available?

Thank you for all your time, and consideration.
   
   If you set
   
   sysctl compat.linux.osrelease=2.6.18
   
   you can install linux_base-c6 on RELENG_9
   
   It works well enough at least for nvidia-driver, as my main desktop
   is 9.3-RELEASE-p9 and has nvidia-driver and linux_base-c6-6.6_3 
   installed
   
   Remember to put
   
   compat.linux.osrelease=2.6.18
   
   into /etc/sysctl.conf so it's preserved on startup
   
   I believe if you read the message from linux_base-c6 that's basically
   what it told you to do.
  Thanks for the reply, Gary.
  Right you are. That's exactly what I did to stage for the upgrade;
  entered 'compat.linux.osrelease=2.6.18' into etc/sysctl.conf
  rebooted, deinstalled x11/nvidia-driver, emulators/linux_base-f10,
  cd emulators/linux_base-c6; make install
  which led to:
  ===  linux_base-c6-6.6_3 compat.linux.osrelease: 2.6.16 is not supported,
  please use 2.6.18, BEWARE this is highly experimental.
  *** [all] Error code 1
  
  Stop in /usr/ports/emulators/linux_base-c6.
  
  Thanks! and sorry for not being more detailed in the first place.
 
 For some reason your sysctl.conf setting didn't take.  You should
 investigate why and resolve that and then the port should work.
 
 A temporary work around would be to run
 
 sysctl compat.linux.osrelease=2.6.18
 
 from a root shell, but it won't last past reboot.
LOL right you are *again*.
Immediately after replying to your last response, I checked
the current status of 'compat.linux.osrelease'
which, as you might have guessed, returned 2.18.
So I simply entered it manually, followed by
cd'ing to emulators/linux_base-c6;make install.
Which went beautifully.

SO. In my humble defense; UPDATING indicated sysctl.conf(5),
when it *actually* meant sysctl(8). :-)

Thank you very much, for taking the time to respond, Gary!

--Chris
 
 Regards,
 
 Gary


___
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: No sound on 10.1-RELEASE

[Chris H]

On Sun, 08 Mar 2015 19:14:47 +0100 Piotr Kubaj pku...@riseup.net wrote

 On 03/07/15 01:55, Chris H wrote:
  On Sat, 07 Mar 2015 00:08:38 +0100 Piotr Kubaj pku...@riseup.net wrote
  
  I've got MSI X99 motherboard and am using it with UEFI installation of
  10.1 (BIOS mode doesn't work with FreeBSD). At first, sound worked
  properly (even in KDE), but now it doesn't. I'm not sure what happened,
  since snd_hda is in kernel (I use GENERIC). I've checked all possible
  values of hw.snd.default_unit and turned off KDE to check what happens
  when doing cat /dev/random  /dev/dsp (it does nothing).
  Attached below is dmesg and /dev/sndstat.
 
  -8---
  
  Installed devices:
  pcm0: NVIDIA (0x0071) (HDMI/DP 8ch) (play)
  pcm1: NVIDIA (0x0071) (HDMI/DP 8ch) (play)
  pcm2: NVIDIA (0x0071) (HDMI/DP 8ch) (play)
  pcm3: NVIDIA (0x0071) (HDMI/DP 8ch) (play)
  pcm4: Realtek ALC892 (Rear Analog 5.1/2.0) (play/rec) default
  pcm5: Realtek ALC892 (Front Analog) (play/rec)
  pcm6: Realtek ALC892 (Rear Digital) (play)
  pcm7: USB audio (rec)
  Honestly, this could potentially go a lot of different directions;
  software/driver(s)/setup...
  It might be helpful to get the pinouts. The kernel
  (dmesg(8)) will provide it for you. You can see them by;
  loader.conf(5)
  adding the following to /boot/loader.conf:
  
  boot_verbose=YES
  
  or by simply selecting boot verbose on the loader menu
  6 -- boot verbose
  
  and then getting the results from dmesg(8)
  /var/run/dmesg.boot
  
  If everything looks as anticipated, you might check that
  your software is using the right sound system (OSS).
  I've had very good experiences on these sound systems by
  installing
  audio/xfce4-mixer
  doing so, always seems to get the correct settings for
  everything on these boards -- even if you never use
  the application.
  Because these boards can be so troublesome where sound
  is concerned; I used to have a script that would both
  check, as well as set everything up. But I can't seem
  to locate it ATM.
  
  HTH
  
  --Chris
  ___
  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
  
  
 I'm not sure what may be wrong in dmesg.boot so I've uploaded it here:
 http://pastebin.com/pP0KXp4v
Out of the 4 MSI boards I that I have; 3 run the same
Realtek ALC893 HDA CODEC that yours does. The other, the
Realtek ALC1200 HDA CODEC. All four of them work. But I
notice 1 notable difference; that yours reports 2
HDA interfaces:
hdac0: NVIDIA (0x0fbb) HDA Controller
and
hdac1: Intel Wellsburg HDA Controller
I see hdac0 is disregarded (unused) whereas
hdac1 is enabled, and functioning. I think your problems
quite possibly lies in your (sound) system attempting to
use the first HDA device in the list, which is effectively
disabled. If you can determine a way to tell KDE, and friends
to use the 2nd HDA. Things may well go as intended.
None of the 4 MSI boards I have display 2 HDA's, as yours
does.
If you have any additional questions, you may well find
the FreeBSD forums already have answers to your issue. This
is where I originally found answers to my issues, when I
first started using these boards.

HTH
 
 KDE is definitely using OSS as chosen in its settings (I also use its
 own mixer which can do the same as Xfce's). I also use VLC's Phonon
 backend because Gstreamer is said to cause problems, but that also works
 on 3 other computers.


--Chris

--


___
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: No sound on 10.1-RELEASE

[Chris H]

On Sat, 07 Mar 2015 00:08:38 +0100 Piotr Kubaj pku...@riseup.net wrote

 I've got MSI X99 motherboard and am using it with UEFI installation of
 10.1 (BIOS mode doesn't work with FreeBSD). At first, sound worked
 properly (even in KDE), but now it doesn't. I'm not sure what happened,
 since snd_hda is in kernel (I use GENERIC). I've checked all possible
 values of hw.snd.default_unit and turned off KDE to check what happens
 when doing cat /dev/random  /dev/dsp (it does nothing).
 Attached below is dmesg and /dev/sndstat.
 
-8---

 Installed devices:
 pcm0: NVIDIA (0x0071) (HDMI/DP 8ch) (play)
 pcm1: NVIDIA (0x0071) (HDMI/DP 8ch) (play)
 pcm2: NVIDIA (0x0071) (HDMI/DP 8ch) (play)
 pcm3: NVIDIA (0x0071) (HDMI/DP 8ch) (play)
 pcm4: Realtek ALC892 (Rear Analog 5.1/2.0) (play/rec) default
 pcm5: Realtek ALC892 (Front Analog) (play/rec)
 pcm6: Realtek ALC892 (Rear Digital) (play)
 pcm7: USB audio (rec)
Honestly, this could potentially go a lot of different directions;
software/driver(s)/setup...
It might be helpful to get the pinouts. The kernel
(dmesg(8)) will provide it for you. You can see them by;
loader.conf(5)
adding the following to /boot/loader.conf:

boot_verbose=YES

or by simply selecting boot verbose on the loader menu
6 -- boot verbose

and then getting the results from dmesg(8)
/var/run/dmesg.boot

If everything looks as anticipated, you might check that
your software is using the right sound system (OSS).
I've had very good experiences on these sound systems by
installing
audio/xfce4-mixer
doing so, always seems to get the correct settings for
everything on these boards -- even if you never use
the application.
Because these boards can be so troublesome where sound
is concerned; I used to have a script that would both
check, as well as set everything up. But I can't seem
to locate it ATM.

HTH

--Chris
 ___
 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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Who hacked the FreeBSD website?

[Chris H]

Greetings,
 I was performing a ports search, and noticed that all the links
providing more information about each port goes to the FreeBSD
404 page. For example, autotrace-0.31.1_23;
The link to it is:
http://www.freebsd.org/home/indexbuild/tindex/ports/graphics/autotrace
the Long description link is:
http://www.freebsd.org/home/indexbuild/tindex/ports/graphics/autotrace/pkg-descr?revision=HEAD

Both of which return:

Page not found.
Oh no. :(

Any chance FreeBSD has a backup of the web site?

___
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: No, the FreeBSD website was not hacked.... (Re: Who hacked the FreeBSD website?)

[Chris H]

 Please don't use subject lines like that for broken links...
Sorry. I was sure that the ports page was rendered as an automated process.
Making it unlikely that such a dramatic change in pathing would be highly 
unlikely,
if not impossible.

 On Tue, Oct 08, 2013 at 08:00:14AM -0700, Chris H wrote:
 Greetings,
  I was performing a ports search, and noticed that all the links
 providing more information about each port goes to the FreeBSD
 404 page. For example, autotrace-0.31.1_23;
 The link to it is:
 http://www.freebsd.org/home/indexbuild/tindex/ports/graphics/autotrace
 the Long description link is:
 http://www.freebsd.org/home/indexbuild/tindex/ports/graphics/autotrace/pkg-descr?revision=HEAD


 It looks like the paths are messed up somehow.  I'll take a look asap.
Aren't changes like this verified before roll out?

--Chris

 Glen

 Both of which return:

 Page not found.
 Oh no. :(

 Any chance FreeBSD has a backup of the web site?

 ___
 freebsd-...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-www
 To unsubscribe, send any mail to freebsd-www-unsubscr...@freebsd.org


___
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.2-PRE: switch off that stupid Nakatomi Socrates

[Chris H]

 On Sep 27, 2013, at 3:06 PM, David Demelier wrote:

 On 21.09.2013 12:40, Matthew Seaman wrote:
 On 21/09/2013 11:31, O. Hartmann wrote:
 I'd like to switch off this silly Nakatomi Socrates message which
 reminds me on Linux and their childish naming schemes.

 It is only cosmetics, but it bothers me whenever I switch on the laptop.

 I guess there is a switch already prsent to have in the bootloader
 config?

 It's turned off by default in more recent 9.2-STABLE

 Otherwise:

 loader_logo=orb

 in /boot/loader.conf  -- see loader.conf(5)

 Cheers,

 Matthew


 Hi,

 I have loader_logo=orb and I still have a message at the right bottom
 with that stupid joke.


 Named Releases is far from a joke.

 Maybe you'd like something a bit more boring like 9.2-RELEASE

 The fact is... there is (and only ever will be) one iteration of FreeBSD 9.2.

 I assume that you have had no clue up until this point that there was yet
 another BSD 9.2. A fictitious version of BSD in a 1980's film, named...

   Nakatomi Socrates

 Yeah, we could have decided to let the opportunity pass; to show that we're
 the first BSD to ever hit 9.2 out of all the flavors, producing the first ever
 non-fictitious BSD 9.2...

 But where would the fun be in that?

 Rest assured... I've not seen *any* hollywood films with a number higher
 than 9.2... so our future looks pretty darn boring.

 The name for 10.0-RELEASE could very well be NULL or boring ol'

   10.0-RELEASE
I nominate
HAL 2000
for 10-RELEASE
Of course it would need to be bold red blinking text.
maybe using an ASCII escape sequence for those not using Graphics Mode?

-- sorry. I couldn't resist. :P

--Chris

 But one thing is clear.

 There is a real tangible benefit to seeing the version on the boot screen.

 As we move to integrate BE's into the Forth boot screen, it may become
 paramount to know what version of loader(8) you're using.

 So please try not to be so judge-mental about these things.

 This is a real tangible improvement and simply because you've heard
 that those crazy people in Linux-land are naming their releases...

 That had zero bearing on why we did it. We may never name another release
 ever again.

 I personally would like to see loader(8) set the value to include an SVN 
 revision
 so that everytime you rebuild loader(8), the version info updates; displayed
 prominently in the bottom right corner (which of course... you'll again be 
 free to
 override it if you don't like it... just as you are free to completely 
 disable the
 entire menu by adding beastie_disable=YES to loader.conf(8)).
 --
 Devin

 _
 The information contained in this message is proprietary and/or confidential. 
 If you are not
 the intended recipient, please: (i) delete the message and all copies; (ii) 
 do not disclose,
 distribute or use the message in any manner; and (iii) notify the sender 
 immediately. In
 addition, please be aware that any message addressed to our domain is subject 
 to archiving
 and review by persons other than the intended recipient. Thank you.
 ___
 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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

ports/gimp mostly broken - ports/182069: [PATCH] devel/py-gobject: Fix GFlags messages

[Chris H]

Greetings,
 I sent a PR for troubles I was having with ports/gimp, and other programs
(ports) that depend on lang/python (Python-2.7), after an upgrade. In my
quest to find a resolution to this problem, I stumbled on to this PR (patch):
ports/182069: [PATCH] devel/py-gobject: Fix GFlags messages
( http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/182069 ). Which was
submitted on the 14th of this month, and appears to reconcile th(is|ese)
issues. What is the patch schedule? In other words; when do patches
that appear to be good, and have no apparent consequences, get pushed
into the ports tree?

Thank you for all your time, and consideration.

--Chris


___
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

Please remove Perl from ports

[Chris H]

Greetings,
 I currently manage several RELENG_8 servers. Recent changes in the
manner in which base  ports must be managed have resulted in more
than a fair amount of grief. the migration from cv(sup) -- subversion
required re-working long standing, carefully crafted management
procedures to be pitched to the trash, and re-invented. A recent change
to the Perl installation structure presents an entire new set of headaches,
rendering up(grading|dating) near, if not completely impossible. Case in
point; an i386 8.3-STABLE box with it's last update just prior to the
Perl structure change, began a new update this morning via portmaster(8).
As it reached 163/300 upgrade targets, the process died with a missing
dependency error -- p5-XML-Simple. Exploring /var/db/pkg revealed that
it had already been installed/upgraded (p5-XML-Simple-2.20). Any
attempt to re-install/forceably upgrade the module failed with
p5-XML-Simple-2.20 not installed. According to /usr/ports/UPDATING;
20130612:
  AFFECTS: users of  lang/perl* and any port that depends on it
  AUTHOR: a...@freebsd.org

  lang/perl5.12 has been upgraded from version 5.12.4 to 5.12.5
  lang/perl5.14 has been upgraded from version 5.14.2 to 5.14.4
  lang/perl5.16 has been upgraded from version 5.16.2 to 5.16.3

  The directory structure where Perl is installed has also been modified:
  major.minor is now used instead of major.minor.patchlevel.

  The perl-after-upgrade script has been removed.

  Please rebuild all Perl ports and all ports that depend on it:

  # portmaster -r perl
or
  # portupgrade -rf perl
or
  # pkg install -fR perl

# portmaster -r perl
=== perl is not installed
=== Aborting update

Hmm...
# ls /usr/local/lib/perl5
5.14 5.14.2 site_perl

Yep. Perl is installed.

Any attempt to upgrade/update *any* Perl, or Perl related
ports fail. I think it's probably fair to say, that the
restructuring of the Perl installation is the cause -- no?
How does reading, and following the instruction(s) provided
in /usr/ports/UPDATING help, or resolve such matters?
WHY was this change *required*? How does this help FreeBSD's
base users? Couldn't th(is|ese) changes been given enough
forethought to have provided tools/procedures that guarantee/
ensure that those affected, can make the transition smoothly?
That those who's income is directly affected by FreeBSD, be
relatively unencumbered by the changes?
While I recognize that many might argue that updating more
frequently would eliminate most -- if not all of these issues.
I can only say, that that _shouldn't_ be the case. For many,
schedules don't always permit this, and if given the right
tools, this wouldn't be an issue at all.
While I also recognize that those whom haven't experienced
these issues, all of this might just sound like a rant. I
don't believe that all of the problems generated by the
changes needed to have occurred.
So, in the end; why did Perl have to be relocated? Is my only
recourse at this point to
# cd /
# rm -rf .
slib the DVD into the slot, and push the reset button?

Thank you for all your time, and consideration in this matter.

--chris

___
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: Please remove Perl from ports

[Chris H]

Greetings Mark, and thank you for your thoughtful reply.
 I can't comment on the perl changes directly, but I can assure you that
 if you use port-mgmt/pkg  (pkgng) and build your ports into packages via
 ports-mgmt/poudriere you will have zero upgrade problems -- a simple
 pkg upgrade will handle the scenario properly. I really haven't tried
 following UPDATING with portmaster/portupgrade to see what happens. I'd
 suspect that portmaster is doing something wrong, but further
 investigation is really necessary to have a solid conclusion of what
 happened on your server(s).
While that sounds real nice. The *current* upgrade will need to
*successfully* complete, before attempting to jump tracks, and
re-create an up(grade|date) policy. :)

 For the first time in ages the ports environment on FreeBSD is rapidly
 evolving. There are many, many new features that benefit the whole of
 the userbase and will ease support and deployment across the board.
 We're trying to limit turbulence, but sometimes things are
 unforeseeable. This is the nature of the incredible flexibility of
 FreeBSD's ports;
there's more than one way to do something.
Sounds a bit Perlish. :)

Thanks again.

--chris

 ___
 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-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: Please remove Perl from ports

[Chris H]

Greetings Patrick, and thank you for the reply.
 Le Thu, 1 Aug 2013 08:31:45 -0700 (PDT),
 Chris H bsd-li...@1command.com a écrit :

 Greetings,
  I currently manage several RELENG_8 servers. Recent changes in the
 manner in which base  ports must be managed have resulted in more
 than a fair amount of grief. the migration from cv(sup) -- subversion
 required re-working long standing, carefully crafted management
 procedures to be pitched to the trash, and re-invented. A recent
 change to the Perl installation structure presents an entire new set
 of headaches, rendering up(grading|dating) near, if not completely
 impossible.

 that's not new. A perl upgrade was always painful.
 I suggest to use poudriere to build yours packages and pkgng to
 manage them. As poudriere produces a consistent set of packages,
 an upgrade is painless (pkg upgrade -f) and you can deploy them on
 several machines.

 In fact poudriere and pkg saved me :)
While that all sounds dreamy. I don't think setting something
like that up on a *half* up(graded|dated) server, should even be
considered. Much less even possible. :(

Thanks again, for taking the time to respond.

--chris


 Regards.
 ___
 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-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: Please remove Perl from ports

[Chris H]

Greetings Mark, and thank you kindly for your extremely thoughtful, and 
informative reply.
 On Thu, Aug 1, 2013, at 11:07, Chris H wrote:
 While that all sounds dreamy. I don't think setting something
 like that up on a *half* up(graded|dated) server, should even be
 considered. Much less even possible. :(


 Oh, it's more than possible.

 1) Install poudriere, minimal configuration if you have ZFS, bit more if
 you use UFS
 2) # poudriere ports -c   # creates ports tree for build env
 3) # poudirere jail -c -j your_buildjail_name -a arch -v X.X-RELEASE   #
 creates your build jail for your release+architecture
 4) put your /etc/make.conf in
 /usr/local/etc/poudriere.d/your_buildjail_name-make.conf
 5) copy your /var/db/ports (port options) to
 /usr/local/etc/poudirere.d/your_buildjail_name-options/
 6) poudriere bulk -j your_buildjail_name -f list_of_ports.txt

 wait a bit as it builds all your packages in a cleanroom environment

 7) configure /usr/local/etc/pkg.conf to point to these packages
 (file://usr/local/poudriere/data/packages/your_buildjail_name-default/)
 8) pkg update
 9) pkg upgrade

 that will probably fix you up, but there might be a small dragon or two
Greatly appreciated. While it looks, at first, a bit daunting. I
can't imagine a better introduction.

Thanks again.

--chris

 ___
 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-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: Please remove Perl from ports

[Chris H]

Greetings Stephen, and thank you for your thoughtful reply.
 On 08/01/2013 10:31 AM, Chris H wrote:

 So, in the end; why did Perl have to be relocated? Is my only
 recourse at this point to
 # cd /
 # rm -rf .

 When I get into this kind of bad situation, I usually do something
 slightly less drastic:
 # pkg_delete -a
 # find -d /usr/local -type d -exec rmdir {} \;
 This last command removes empty directories in /usr/local (it also
 produces lots of error messages when it tries to remove non-empty
 directories).  Then I look through the contents of /usr/local,
 especially if there is anything in /usr/local/etc or /usr/local/libexec
 where some of my manually changed configuration files reside.  And then
 I delete any crud left over that I know I don't need.

 After that, I rebuild all the ports from scratch.

 Finally, I do understand why you feel the need to vent, and I don't want
 to belittle your feelings of frustration.  But I do think everyone is
 trying their best.
I believe this for the most part, as well. Being, and having been involved
in a vast multitude of large projects, over the years. Has given me a
keen understanding of all the burdens, one can come to expect. The many,
many hours w/o sleep. The seemingly never ending stress that comes from
frequently running right up to, or beyond deadlines. Having to greet rabid
users with a calm tone, and a smile. As such, and with the nearly 30yrs.
using *BSD, I have come to expect quite a bit more, than I have experienced,
in recent months. Make no mistake; I have no intention of throwing the
baby out w/ the bath water here. But *recent* changes have given me cause
for alarm. That the BSD I have come to know, love, and greatly depend on.
Is becoming something *quite* different. And if I don't say something, how
will those the make the changes know what their user base thinks? How
will they know what affects those changes has on them?
Frankly, I *still* have no idea why it was _so_ important to change the
install structure for Perl on FreeBSD. That the (possible) outcome of
such a change, should have little, no concern. I can assure you, I am not
an edge case. My first (recent) up(grade|date) experience caused me great
pain. I spent much time in the forums helping others. Sharing solutions
I have found. In fact, I try to spend as much time, as I can, helping
others in forums, with their (FreeBSD related) problems.
 I like to tell people that running FreeBSD or Linux
 is like owning a souped up sports car - usually it runs really well, but
 it often needs a lot of attention.  (Windows is like driving a cheap car
 that breaks down all the time, but engine is designed in such a way as
 to be totally inaccessible with regards to repairs.  And Apple is like
 driving a BMW - it mostly works well but you pay a lot for it.)
Easy does it. You're treading on shaky ground here. ;)
I'm rather fond of my 735i, and I couldn't imagine life w/o it.
In fact, I'm looking to replace the OBC with a FreeBSD powered version --
assuming the dust from recent events, settles down. :)

Best wishes, and thanks again for your reply.

--chris




___
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

Does the image on isc.portsnap.freebsd.org have a virus?

[Chris H]

Greetings,
 I know this sounds crazy, and apologies if I am. But I have 2 RELENG_8 servers;
1 amd64, and 1 i386. about 3 wks ago, I migrated from cv(sup) updating, to svn 
on
the amd64 box.
After removing cv(sup) related folders, and the ports folder, I used:
portsnap fetch
After the fetch completed I ran:
portsnap extract
which verified/patched  extracted the image to /usr/ports.
Tonight, I initiated the same procedure on the i386 server. _BUT_ upon 
completion of
the fetch, it proceeded to verify/patch  extract; _not_ to /usr/ports, but to
/var/db/portsnap/ports. re-examining /etc/portsnap.conf, and re-reading the 
portsnap(8) man
page, reveals that _both_ .conf files are identical, as were the version(s) 
used on both
boxes. An additional attempt to portsnap fetch, resulted in the same 
(unorthodox) behavior.
What gives?!

Thank you for all your time, and consideration.

--chris

___
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: Does the image on isc.portsnap.freebsd.org have a virus?

[Chris H]

Greetings, and thank you for your response.
 On 31/07/2013 15:44, Chris H wrote:
 Greetings,
   I know this sounds crazy, and apologies if I am. But I have 2 RELENG_8 
 servers;
 1 amd64, and 1 i386. about 3 wks ago, I migrated from cv(sup) updating, to 
 svn on
 the amd64 box.
 After removing cv(sup) related folders, and the ports folder, I used:
 portsnap fetch
 After the fetch completed I ran:
 portsnap extract
 which verified/patched  extracted the image to /usr/ports.
 Tonight, I initiated the same procedure on the i386 server. _BUT_ upon 
 completion of
 the fetch, it proceeded to verify/patch  extract; _not_ to /usr/ports, but 
 to
 /var/db/portsnap/ports. re-examining /etc/portsnap.conf, and re-reading the 
 portsnap(8)
 man
 page, reveals that _both_ .conf files are identical, as were the version(s) 
 used on both
 boxes. An additional attempt to portsnap fetch, resulted in the same 
 (unorthodox)
 behavior.
 What gives?!

 Are you watching as it started or when it finished?

 /var/db/portsnap is used by portsnap to download updates that it uses to
 generate the /usr/ports files.

 Just guessing but it may also extract and patch files there before
 moving them to /usr/ports
Yep. I'm watching it.
In the first instance, /usr/ports was removed (before initiating portsnap). But 
before
the second attempt, I performed a mkdir /usr/ports. But in the end, the results 
were
the same;
portsnap fetch fetched the image, verified the image,
extracted to /var/db/portsnap/ports, then patched, and exited.
I did _not_ issue portsnap fetch  portsnap extract.
So I guess portsnap extract is a noop. Guess it's time to update the portsnap(8)
man pages to indicate portsnap fetch is no longer an option.

Thanks again, for the reply.

--chris



 ___
 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-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: Does the image on isc.portsnap.freebsd.org have a virus?

[Chris H]

 On 01/08/2013 00:28, Chris H wrote:

 In the first instance, /usr/ports was removed (before initiating portsnap). 
 But before
 the second attempt, I performed a mkdir /usr/ports. But in the end, the 
 results were
 the same;
 portsnap fetch fetched the image, verified the image,
 extracted to /var/db/portsnap/ports, then patched, and exited.
 I did _not_ issue portsnap fetch  portsnap extract.
 So I guess portsnap extract is a noop. Guess it's time to update the 
 portsnap(8)
 man pages to indicate portsnap fetch is no longer an option.

 'portsnap fetch' downloads the relevant data to /var/db/portsnap
 'portsnap extract' extracts the files to /usr/ports
 'portsnap update' updates existing files in /usr/ports

 So on a clean system you use portsnap fetch extract
 Then to update later you use portsnap fetch update

 (you can give multiple commands to portsnap in one go)

 If fetch extract works on amd64 and not i386 then you should submit a
 problem report so that it can be fixed.
Greetings,
 Yes, I know. That's how it's _supposed_ to work. :)
I guess a send(2) pr is in order.

Thanks for the reply.

--chris



 ___
 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-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: Bind in FreeBSD, security advisories

[Chris H]

 On Tue, Jul 30, 2013, at 8:32, Daniel Kalchev wrote:


 This is very much an situation like replacing gcc with clang/llvm.
 However, in the case of BIND we have no licensing problems, stability
 problems, performance problems etc --- just concerns that BIND generates
 many SAs -- which might be actually good indicator, as it demonstrates
 that BIND is worked on.


 There's a man with a name whose initials match DJB that would strongly
 disagree. Now he's not always the best person to reference, but he's
 made a succinct point with his own software, whether or not you like
 using it.

 Unbound/NSD are suitable replacements if we really need something in
 base, and they have been picked up by OpenBSD for a good reason --
 clean, secure, readable, maintainable codebases and their use across the
 internet and on the ROOT servers is growing.

 I personally see no reason to remove BIND from base. If someone does not
 want BIND in their system, they could always use the WITHOUT_BIND build
 switch.

 I'd be inclined to agree if it wasn't such a wholly insecure chunk of
 code. You don't see people whining about Sendmail in base when they
 prefer Postfix or Exim, but Sendmail doesn't have a new exploit every
 week. You do tend to need an MTA for getting messages off the system
 more than you need a local recursor/cache, but at least it's not causing
 you maintenance headaches. If you consider the possibility that a large
 enough percentage of users really desire a local recursor/cache it
 should be our duty to give them the best option available.

+1
Sorry to do that. But I simply couldn't have expressed it better, myself.

 ___
 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-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: Bind in FreeBSD, security advisories

[Chris H]

 On 30.07.2013, at 19:49, Peter Maxwell pe...@allicient.co.uk wrote:

 I personally prefer qmail over sendmail
 but I wouldn't suggest qmail should be in base for the reason that sendmail
 is the de facto standard on *nix shaped systems.


 One can argue that BIND is the de facto standard on *nix shaped systems too.

Considering the topic, and how many times it's come up. I'm not sure that's 
anything to
be proud of. ;)


 Daniel
 ___
 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-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: Trouble building release with docs

[Chris H]

 On Sat, 20 Jul 2013, Daniel O'Connor wrote:

 Hi,
 I am trying to do a full (customised) release of 9.1 but I am having trouble 
 building the
 docs. If I use NODOC it builds fine, but without that I get..
 [andenes 7:04] /usr/src/release #/usr/bin/time make release 
 BUILDNAME=$BUILDNAME
 make -C /usr/src/release  BUILDNAME=9.1-GENESIS obj
 make -C /usr/src/release  BUILDNAME=9.1-GENESIS ftp cdrom memstick
 cd /usr/src/release/doc  make all install clean 'FORMATS=html txt'
 INSTALL_COMPRESSED='' URLS_ABSOLUTE=YES DOCDIR=/usr/obj/usr/src/release/rdoc
 === en_US.ISO8859-1 (all)
 === en_US.ISO8859-1/relnotes (all)
 /usr/bin/grep '^?xml version=.*?' article.xml  article.parsed.xml.tmp
 grep: article.xml: No such file or directory
 *** [article.parsed.xml] Error code 2

 Stop in /usr/src/release/doc/en_US.ISO8859-1/relnotes.
 *** [all] Error code 1

 Stop in /usr/src/release/doc/en_US.ISO8859-1.
 *** [all] Error code 1

 Stop in /usr/src/release/doc.
 *** [reldoc] Error code 1

 Stop in /usr/src/release.
 *** [release] Error code 1

 Stop in /usr/src/release.
0.48 real 0.37 user 0.10 sys

 There is article.sgml though.. I have installed textproc/docproj and I can 
 build /usr/docs
 fine.

 What does svn say about that file?

% cd /usr/src/release/doc/en_US.ISO8859-1/relnotes/
% svn stat

 The article.sgml suggests a leftover file from an earlier /usr/src that
 was not removed before svn checkout.  That does not explain why
 article.xml is missing, though.  It is present on my 9-stable and
 8-stable checkouts.  Maybe a mixed or partial checkout?

FWIW, it wasn't in my checkout from July 2, either (8-STABLE)

--Chris

 ___
 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-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: What are the ideal ranges for kern.ipc.shm*?

[Chris H]

Greetings Alberto, and thank you for the reply.
 On Fri, Jul 12, 2013 at 5:24 AM, Chris H bsd-li...@1command.com wrote:
 Greetings,
  Over the years using the xfce4 desktop, I would occasionally receive
 SHM ERROR messages. As they never interfered (so's I could notice), I
 always put off attempting to track the cause down. However, now having
 performed a fairly major upgrade (~1yr since last), The error appears
 to greatly affect KDE4 (used to use kde3) applications I run within
 xfce4. The windows don't re-draw correctly, and I receive additional
 errors,as well:
 ...
 Resource id:  0x0
 X Error: BadDrawable (invalid Pixmap or Window parameter) 9
   Major opcode: 62 (X_CopyArea)
   Resource id:  0x0
 ...
 After much searching, it would appear to be related to the
 kern.ipc.shm* values.

 $ cat /usr/ports/x11-toolkits/qt4-gui/pkg-message

 Qt paint engine makes common use of shared memory. To avoid MIT-SHM
 errors (i.e., blank windows), you probably need to raise shared memory
 limits in loader.conf(5). The following should be safe values for the
 KDE Plasma Desktop:

 kern.ipc.shmall=32768
 kern.ipc.shmmni=1024
 kern.ipc.shmseg=1024

Yes, I followed those instructions when I received the message after the
upgrade from qt3 -- qt4. Entering those numbers in loader.conf(5) caused
the server to freeze and re-boot ~20 seconds after starting X.

--chris
 --
 Alberto Villa, FreeBSD committer avi...@freebsd.org
 http://people.FreeBSD.org/~avilla
 ___
 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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

What are the ideal ranges for kern.ipc.shm*?

[Chris H]

Greetings,
 Over the years using the xfce4 desktop, I would occasionally receive
SHM ERROR messages. As they never interfered (so's I could notice), I
always put off attempting to track the cause down. However, now having
performed a fairly major upgrade (~1yr since last), The error appears
to greatly affect KDE4 (used to use kde3) applications I run within
xfce4. The windows don't re-draw correctly, and I receive additional
errors,as well:
...
Resource id:  0x0
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 62 (X_CopyArea)
  Resource id:  0x0
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 62 (X_CopyArea)
  Resource id:  0x0
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 62 (X_CopyArea)
  Resource id:  0x0
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode: 62 (X_CopyArea)
  Resource id:  0x0
QCoreApplication::postEvent: Unexpected null receiver
...
After much searching, it would appear to be related to the
kern.ipc.shm* values.
pertinent details follow:
FreeBSD udns 8.4-STABLE FreeBSD 8.4-STABLE #3: Tue Jul  2 13:41:21 PDT 2013
root@udns:/usr/obj/usr/src/sys/AMD64  amd64
with 64Gb ram, and 3 cores, and nvidia-driver-308.88_1.
# ipcs -M
shminfo:
shmmax: 33554432(max shared memory segment size)
shmmin:1(min shared memory segment size)
shmmni:  192(max number of shared memory identifiers)
shmseg:  128(max shared memory segments per process)
shmall: 8192(max amount of shared memory in pages)

Thank you for all your time, and consideration.

--chris

___
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

perl upgrade woes -- how to best reconcile?

[Chris H]

Greetings,
 As my upgrade also required the change to subversion, it's been quite a 
challenge.
I've nearly sorted out all the loose ends. But have a real issue with the
path change for Perl. Yes, I've read UPDATING.
For the most part, I upgraded all the ports via portmaster(8). But apparently
that doesn't get it. While Perl seems to work, I receive a few errors, and have 
nearly
no access to the (info|man)pages. An example error:
perlinfo Date::Manip::Offset
Subroutine path redefined at /usr/local/lib/perl5/5.12/BSDPAN/BSDPAN.pm line 29.
Subroutine canonical_path redefined at 
/usr/local/lib/perl5/5.12/BSDPAN/BSDPAN.pm line 33.
Subroutine perl_version redefined at /usr/local/lib/perl5/5.12/BSDPAN/BSDPAN.pm 
line 42.
Subroutine perl_arch redefined at /usr/local/lib/perl5/5.12/BSDPAN/BSDPAN.pm 
line 47.
Subroutine builds_port redefined at /usr/local/lib/perl5/5.12/BSDPAN/BSDPAN.pm 
line 51.
Subroutine builds_standalone redefined at 
/usr/local/lib/perl5/5.12/BSDPAN/BSDPAN.pm line 66.

How do I best sort this all out. I _really_ miss the perl_after_upgrade script, 
that
used to accompany this process.

Thank you for all your time, and consideration.

--chris

___
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: perl upgrade woes -- how to best reconcile?

[Chris H]

Greetings Fabian, and thank you for your reply.
 Hello Chris

 On 09.07.2013 11:18, Chris H wrote:
 How do I best sort this all out. I _really_ miss the perl_after_upgrade 
 script, that
 used to accompany this process.

 I also had some challenges with this perl upgrade, but I used
 portupgrade. In the end I created a custom script based on the
 output from 'portupgrade -nrf perl' which did the following:

 #!/usr/local/bin/bash
 set -e
 portupgrade -f lang/perl5.12
 portupgrade -f converters/p5-MIME-Base64
 portupgrade -f devel/p5-Test-Harness
 portupgrade -f devel/p5-Locale-Maketext-Simple
 [...]

 This script does abort, when a single command fails, so you see
 what fails and you can fix it. Eventually you will need to check
 dependencies and rebuild one of the ports now, which is later in
 the script. When the failed port did build, then remove the
 already done ports from the script and restart it.

 At the end I also did check the folders in /usr/local/lib/perl5/
 for left overs in the folders from the old perl version. I then
 used pkg_which to find out to which port the belongs and did also
 a portupgrade -f for this port too.

Thanks for that. I also considered cobbling a script to reconcile
things, but in the end, felt simply un-installing Perl and the
some 200 modules would be both faster, and less prone to failure.


 In the end everything was fine, but it took a little more effort,
 as I had around 235 ports to rebuild. But as long as you stay
 with e.g. perl 5.12.x, it is easier then before with the
 perl_after_upgrade script for minor updates.

I ran into problems in my first attempt to use portmaster(8), issuing
portmaster -a. It failed on a number of ports, and I was forced to run
it several times. I had some difficulty with it given that not all the
options are quite clear -- -s, for example. One can only infer it's
action(s) from the context it used within the man(1) page, it doesn't
literally explain it's intent.
In the end, I was forced to perform many make reinstall jobs, which
left the dependency records _way_ out-of-whack -- pkg_info:
pkg_info: corrupted record (pkgdep line without argument), ignoring.
Forcing me to resolve the issue by cobbling  running the following:
grep ^@pkgdep /var/db/pkg/*/+CONTENTS | awk '{ if (NF != 2) { print $1 } }' | 
cut -d':' -f1
I redirected the output to a file, where I then cat | sort -u to
another file, which left me with a list of the ports to reconcile.
performing a portmaster --check-depends resolved the problem.
I guess the only _sure-fire_ way to resolve my issue, is to catalog
all of my installed Perl modules, and remove Perl 5.12, and the
modules. re-install Perl 5.12.5, and cobble a script to install all the
modules I currently have installed.
My perl5 tree currently looks like:
/usr/local/lib/perl5/5.12/man/
man3/
whatis
/usr/local/lib/perl5/5.12.4/
man3/
whatis
What a mess!
In the end, I guess the moral of the story is; don't upgrade.
I've been on BSD since the late 70's, and as such, am no stranger
to the upgrade path. But recent experience seems to show, things
aren't getting any easier (or necessarily better). :(

 The next big challenge then will be the upgrade to e.g. 5.14.x or
 5.16.x.

I don't think I'm even willing to go there, after this mess.

Thanks again, for taking the time to respond.

--chris


 bye
 Fabian
 ___
 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-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: perl upgrade woes -- how to best reconcile?

[Chris H]

Greetings Mark, and thank you for your reply.
 Is there a reason you're avoiding poudriere/pkg ? It's simple to setup and
 extremely reliable. Your headaches go away because all of your package
 upgrades get built in a jail and you don't have a half-broken system while
 waiting for portmaster to run.
I was introduced to poudriere when I solicited recommendations from the list
prior to this upgrade -- portupgrade(1) | portmaster(8) -- which is more 
effective for large
upgrade?
After examining this port, it was clear that my whole upgrade scheme would
have to completely change. While it would be nice to build everything, and
then push the builds onto the target box. This is not an immediate option.
Tho it is my intention to create a box to produce packages targeted for all
of my servers. While I realize that poudriere doesn't require a separate box
to do this work, I wasn't willing to take on yet another change, just to
perform this upgrade. As it was; I was going from 8.3-STABLE -- 8.4 
(cv)sup -- subversion 1.7 -- subversion 1.8 -- and this was just to get to
8.4. I made the solicitation to the list, because my normal choice was using
portupgrade(1). But given that it wasn't all that uncommon to run into database
issues, and sometimes even upgrading portupgrade itself; given the extra
dependencies. I ultimately decided on portmaster(8) because it required nothing
that the system didn't already provide. I also don't believe that when facing
issues, that adding additional variables makes the process any more stable --
especially given that I'm already not dealing with a completely stable system.
Anyway, you asked. So now you know. :)

Thanks again, for taking the time to respond.

--chris


 ___
 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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Where's the docs for FreeBSD maintenance with Subversion?

[Chris H]

Greetings,
 I've _finally_ managed to get a break in my work schedule that coincides with
a period where pointyhat isn't barfing on my ARCH. So I was able to (cv)sup src 
 ports.
Update the kernel successfully, and (after hours of work), managed to upgrade 
ports. But
as (cv)sup was discontinued ~3 months ago, the ports aren't well synced, and 
I'm now
working on a fairly wobbly system. I'm on RELENG_8 (8.4), and would like to 
sync my src 
ports via the (now defacto) subversion method. My previous experience is with 
the client
meerly for the sake of obtaining the src, and building -- _not_ maintaining a 
tree. I've
read what little is available in the handbook, and much of the Subversion book. 
But there are
clearly different procedures/nuances where FreeBSD maintenance is concerned, 
both in the
building of Subversion, and it's usage, where FreeBSD is concerned. The biggest 
questions
in this regard, is;
1) what to do with my current INDEX-8  INDEX-8.db files?
2) what of the distfiles directory
Do I simply copy them over, and check them in?
Surely I'm not the only one that still has questions in this regard.

Thank you for all your time, and consideration.

--chris

___
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: Where's the docs for FreeBSD maintenance with Subversion?

[Chris H]

 In message b8cefc405bcd2f7248f4c260a9148296.authentica...@ultimatedns.net,
   Chris H (bsd-li...@1command.com) wrote:
 Greetings,
  I've _finally_ managed to get a break in my work schedule that coincides 
 with
 a period where pointyhat isn't barfing on my ARCH. So I was able to (cv)sup 
 src  ports.
 Update the kernel successfully, and (after hours of work), managed to 
 upgrade ports. But
 as (cv)sup was discontinued ~3 months ago, the ports aren't well synced, and 
 I'm now
 working on a fairly wobbly system. I'm on RELENG_8 (8.4), and would like to 
 sync my src 
 ports via the (now defacto) subversion method. My previous experience is 
 with the client
 meerly for the sake of obtaining the src, and building -- _not_ maintaining 
 a tree. I've
 read what little is available in the handbook, and much of the Subversion 
 book. But there
 are
 clearly different procedures/nuances where FreeBSD maintenance is concerned, 
 both in the
 building of Subversion, and it's usage, where FreeBSD is concerned. The 
 biggest questions
 in this regard, is;
 1) what to do with my current INDEX-8  INDEX-8.db files?
 2) what of the distfiles directory
 Do I simply copy them over, and check them in?

 When I converted from csup to svn I did the following - which seems to
 work. :-)

 1. mv /usr/ports /usr/ports.old
 2. mkdir /usr/ports
 3. svn checkout into /usr/ports
 4. mv /usr/ports.old/distfiles /usr/ports

 When I do a svn update it ignores distfiles.

 I hope this terse reply helps.

Perfect! Thanks.

--chris



 Cheers,
Nick.
 --


 ___
 svn-src-stabl...@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-stable-8
 To unsubscribe, send any mail to svn-src-stable-8-unsubscr...@freebsd.org


___
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: portupgrade(1) | portmaster(8) -- which is more effective for large upgrade?

[Chris H]

 In article 5e20544e3580a75759c3858f31894dc9.authentica...@ultimatedns.net,
 bsd-li...@lcommand.com writes:

 I haven't upgraded my tree(s) for awhile. My last attempt to rebuild
after an updating
src  ports, resulted in nearly installing the entire ports tree, which
is why I've
waited so long. Try as I might, I've had great difficulty finding
something that will
_only_ upgrade what I already have installed, _and_ respect the
options used during the
original make  make install, or those options expressed in make.conf.

 Having just gone through this in two different environments, I can
 very very strongly recommend doing the following.  It's not the easy
 button of the TV commercials, but it will make things much much
 easier in the future.

 1) Switch your system to pkgng if you haven't already.  Unfortunately,
 this will not result in the right ports being marked as automatic,
 so you'll need to do a bit of post-conversion surgery:

   # pkg set -A 1 -g '*'
   # pkg query -e '%#r==0' '%n-%v: %c'

 Then look through the output of pkg query to identify the leaf
 packages that are the ones you actually wanted explicitly to have
 installed.  For each one of those:

   # pkg set -A 0 packagename

 Create a list of your desired packages:

   # pkg query -e '%a==0' '%o'  pkg-list

 Clean up the unnecessary local packages:

   # pkg autoremove

 (You can iterate the last three steps, aborting pkg autoremove each
 time but the last, until it doesn't offer to remove anything you care
 about keeping.)

 Repeat this process for each machine, and merge the resulting pkg-list
 files using sort -u.  Make sure that pkgng is enabled for ports in
 /etc/make.conf.

 2) Install and set up poudriere.  Copy /var/db/ports, /etc/src.conf,
 and /etc/make.conf to /usr/local/etc (possibly with local variations
 as described in poudriere(8) under the heading CUSTOMISATION).

 3) Run poudriere options for each jail and setname (if you created
 any sets following the customization section referenced above),
 providing the package list you constructed, to make sure that any new
 options are configured as you require them.

 4) Run poudriere bulk for each jail and setname (if you created
 any), providing the package list as before.  This will create a pkgng
 repository for each jail and set, which you can serve by HTTP (using
 your choice of Web server) or SSH (with pkgng 1.1+), and all of these
 packages will have been built in a clean jail and (if their
 dependencies were specified correctly) will have no library
 inconsistencies.

 5) Configure your client machines to reference the appropriate
 repository created in step (4).

 6) Run pkg upgrade -fy on all of your machines, and resolve any
 inconsistencies by pkg remove-ing the offending local package.

 That seems like a lot of work, and it is, but having done it, there's
 a huge benefit the next time you want to do update your systems:

 a) Update the ports tree (how you do this depends on how you set up
 poudriere -- see the man page).

 b) Repeat step (3).

 c) Repeat step (4).

 d) Check the ports UPDATING file for any warnings about packages you
 are about to install.  If it tells you to do pkg install -fR
 somepackage, then do those.

 e) Run pkg upgrade -y to upgrade any remaining packages.

 Even for just three machines it was worth going through this process
 -- and worth unifying all of my package sets and options.  Since I now
 do one build instead of three, I'm no longer so ocncerned about
 minimizing dependencies; it's no big deal if some X libraries get
 installed on my server.

 -GAWollman
Greetings,
WOW! Thank you for the _very_ informative reply, Garrett.
_Greatly_ appreciated.

--Chris

 ___
 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-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: portupgrade(1) | portmaster(8) -- which is more effective for large upgrade?

[Chris H]

 Warren Block wrote:
 On Wed, 26 Jun 2013, Chris H wrote:
 On Wed, 26 Jun 2013, Chris H wrote:

 Okay, look up the last time you installed or upgraded a port:
 % ls -ltr /var/db/pkg

 The last one is the most recently modified. Update your ports tree,
 follow all the steps that apply to your system since that date.

 That should say all the steps in /usr/ports/UPDATING that apply to your
 system since that date.

 There is a nice command that helps you to list only relevant entries
 from UPDATING (entries from UPDATING for already installed ports)

 pkg_updating -d MMDD

 Where MMDD is the last time you did ports update, for example
 pkg_updating -d 20120923

 Miroslav Lachman
Greetings Miroslav,
That _is_ nice. Thank you for taking the time post this.
That'll help quite a bit!

--Chris

 ___
 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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

portupgrade(1) | portmaster(8) -- which is more effective for large upgrade?

[Chris H]

Greetings,
 I haven't upgraded my tree(s) for awhile. My last attempt to rebuild after an 
updating
src  ports, resulted in nearly installing the entire ports tree, which is why 
I've
waited so long. Try as I might, I've had great difficulty finding something 
that will
_only_ upgrade what I already have installed, _and_ respect the options used 
during the
original make  make install, or those options expressed in make.conf.
As portupgrade(1)  portmaster(8) appear to be the most used in this scenario,
I'm soliciting opinions on which of these works best, or if there is something 
else to
better manage this situation. Is there such a thing as a FreeBSD upgrade easy 
button?

Thank you for all your consideration.

--chris

___
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: portupgrade(1) | portmaster(8) -- which is more effective for large upgrade?

[Chris H]

 Am 26.06.2013 18:42, schrieb Chris H:
 Greetings,
  I haven't upgraded my tree(s) for awhile. My last attempt to rebuild after 
 an updating
 src  ports, resulted in nearly installing the entire ports tree, which is 
 why I've
 waited so long. Try as I might, I've had great difficulty finding something 
 that will
 _only_ upgrade what I already have installed, _and_ respect the options 
 used during the
 original make  make install, or those options expressed in make.conf.
 As portupgrade(1)  portmaster(8) appear to be the most used in this 
 scenario,
 I'm soliciting opinions on which of these works best, or if there is 
 something else to
 better manage this situation. Is there such a thing as a FreeBSD upgrade 
 easy button?

 Thank you for all your consideration.

 Chris,

 this time around, you will again rebuild almost your entire ports tree
 because some basic ports, such as Perl.

 Also, you will rarely be able to only upgrade what you already have
 installed because sometimes ports grow new requisite other ports you do
 not already have.

 I haven't used portupgrade in a long time because there was a period
 where it had fallen to bit-rot, but both tools are being maintained now.

 portupgrade has the decided advantage of being able to continue building
 some ports if another port failed as long as the failed port is not
 itself a requisite port for one that is yet to be built; portmaster
 bails out at the first error.

 portmaster, on the other hand, has a rebuild everything approach in
 the manual page, and can be used to list only leaf ports -- but that
 approach will require you to deinstall all ports so that the machine
 becomes unusable while it builds.

 There are other approaches, like using portmaster just to list this
 ports tree, and then use Tinderbox or poudriere to build packages in a
 chroot, and then only deinstall and install if you have all packages
 built successfully - but I am not familiar with automating this, not
 familiar with poudriere, and it requires a bit of work to get your
 options transferred to these build systems.  Such a build all packages
 first before you start deinstalling would reduce the downtime, though.

 Hope that helps a little.

 Best regards
 Matthias Andree

Greetings, and thank you for your reply.
I understand that portupgrade _will_ pull in other dependencies _as needed_ -- 
I _do_ read
the man(1) pages. :)
But it installed (pulled in) far more than those dependencies actually required.
I believe, due to the fact that it doesn't appear to honor the original build
options recorded in /var/db/ports/portname/options. Nor, do I recall that it
honored /etc/make.conf -- make.conf(5). Maybe things have changed? I don't see 
it.
Oh, and should it not have been clear; I _do_ anticipate the upgrade to 
re-build
most everything, as that is why I'm trying to find a mass upgrader port, to 
do the
dirty work. Also should it not have been clear in the beginning; I am _not_ 
doing
anything more than upgrading everything _within_ my current version; eg; no 
major point
upgrade, or anything.

Thank you again, for taking the time to respond.

--chris

___
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: portupgrade(1) | portmaster(8) -- which is more effective for large upgrade?

[Chris H]

 On Wed, 26 Jun 2013, Chris H wrote:

 But it installed (pulled in) far more than those dependencies actually 
 required.

 It may bring in build dependencies, but should be no different than
 manually installing ports.

 I believe, due to the fact that it doesn't appear to honor the original build
 options recorded in /var/db/ports/portname/options. Nor, do I recall that 
 it
 honored /etc/make.conf -- make.conf(5). Maybe things have changed?

 Both portupgrade and portmaster did and do honor these.  Both are
 automated versions of installing the ports manually.  That can be
 overridden with mis-recommended BATCH variable.  Don't do that.

 I don't see it. Oh, and should it not have been clear; I _do_
 anticipate the upgrade to re-build most everything, as that is why
 I'm trying to find a mass upgrader port, to do the dirty work.
 Also should it not have been clear in the beginning; I am _not_ doing
 anything more than upgrading everything _within_ my current version;
 eg; no major point upgrade, or anything.

 Okay, look up the last time you installed or upgraded a port:
 % ls -ltr /var/db/pkg

 The last one is the most recently modified.  Update your ports tree,
 follow all the steps that apply to your system since that date.  If any
 ports are left to upgrade at the end, use either port upgrade program
 with -a.

 I recommend portmaster.  It does almost everything portupgrade does, but
 without the overhead of Ruby or bdb.
Greetings Warren, and thank you for your reply.

Sounds like the plan. I'll take your advice, and run with it.
Gave me just the confidence I needed. :)

Thanks again, for taking the time to reply.

--Chris

 ___
 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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

t_delta 16.0106d62009e53600 too long -- Should I be concerned?

[Chris H]

Greetings,
 I received the following last night:

Feb 10 23:31:20 udns kernel: t_delta 16.0106d62009e53600 too long
Feb 10 23:31:36 udns kernel: t_delta 15.fefb2d70ffb0bf00 too short

While I'm _guessing_ disk, I'm not sure from where it originates.
Should I be concerned?

Thank you for all your time, and consideration.

--Chris

___
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: So I whip out a FTDI-based multiport Serial USB Adapter....

[Chris H]

 On 2/4/2013 9:33 PM, Karl Denninger wrote:
 On 2/4/2013 9:02 PM, Karl Denninger wrote:
 On 2/4/2013 4:32 PM, Charles Sprickman wrote:
 On Feb 4, 2013, at 5:00 PM, Ian Lepore wrote:

 On Mon, 2013-02-04 at 16:31 -0500, Charles Sprickman wrote:
 On Feb 4, 2013, at 4:13 PM, Ian Lepore wrote:

 On Mon, 2013-02-04 at 14:58 -0600, Karl Denninger wrote:
 On 2/4/2013 2:06 PM, Ian Lepore wrote:
 On Mon, 2013-02-04 at 12:57 -0600, Karl Denninger wrote:
 ... and plug it into FreeBSD 9.1-Stable with the rev ID FreeBSD
 9.1-STABLE #16 r244942

 and it returns

 ugen4.4: vendor 0x0409 at usbus4
 uhub6: vendor 0x0409 product 0x0050, class 9/0, rev 2.00/1.00, addr 
 4
 on usbus4
 uhub_attach: port 1 power on failed, USB_ERR_STALLED
 uhub_attach: port 2 power on failed, USB_ERR_STALLED
 uhub_attach: port 3 power on failed, USB_ERR_STALLED
 uhub_attach: port 4 power on failed, USB_ERR_STALLED
 uhub_attach: port 5 power on failed, USB_ERR_STALLED
 uhub_attach: port 6 power on failed, USB_ERR_STALLED
 uhub_attach: port 7 power on failed, USB_ERR_STALLED
 uhub6: 7 ports with 7 removable, self powered

 Yuck.

 The last time it was working was on a FreeBSD 7 box (yeah, I know,
 rather old) but I never had problems there.  And it appears that all 
 of
 the device declarations that I used to have to put in the kernel as
 non-standard stuff are now in GENERIC, so I would expect it to work.

 Ideas as to what may have gotten hosed up here?

 Those messages all seem to be related to a hub. Vendor ID 0x0409 is 
 NEC.

 FTDI's vendor ID is 0x0403, and FTDI stuff works fine in FreeBSD 9 and
 10; I use it all the time.  Sometimes aftermarket vendors who use 
 FTDI's
 parts program different vendor/product info and IDs have to be added 
 to
 code to recognize them, that's the only trouble one usually 
 encounters.

 -- Ian
 Well, that sorta kinda worked.

 Except that it still is identifying it as a hub too, and the two 
 collide
 and crash the stack.

 But I can't find anything that is looking at the PID (0x0050) or the
 definition (HUB_0050) anywhere in the code.

 I'll go pull the NEC defs and set up something else instead of simply
 adding it to the FTDI probe list.

 It seems to me you have a problem with a hub (perhaps the root hub or a
 motherboard hub if you don't have an external one) and this has nothing
 to do with the ftdi device at all.
 I assume we're talking about a multi-port usb to serial adapter, correct?

 If so, they generally do have a hub included in the device.

 Example:

 ugen1.3: vendor 0x0409 at usbus1
 uhub4: vendor 0x0409 product 0x0050, class 9/0, rev 2.00/1.00, addr 3 
 on usbus1
 uhub4: 7 ports with 7 removable, self powered

 Then the individual ports look like this:

 ugen1.4: FTDI at usbus1
 uftdi0: FT232R USB UART on usbus1
 ugen1.5: FTDI at usbus1
 uftdi1: FT232R USB UART on usbus1
 (etc.)

 We use these for serial console ports, they're (relatively) cheap and 
 have generally
 been well supported.

 The above info is from an 8.3 box.

 Just wanted to clarify that there is likely a hub in the serial box Karl 
 is working
 with…

 Charles
 Oh, interesting.  The biggest ftdi dongle I have is 4 ports, using the
 ftdi 4232 chip.  I guess to get more ports than that, folks are now
 using an internal hub and multiple ftdi chips.
 These multiport things have been around for a long time.  Someone at ISC 
 recommended
 them when we were looking to replace some unsupported RocketPort cards.  
 Not affiliated
 with this place, but it's the largest collection of USB to serial stuff 
 I've ever seen
 (and they document for the most part what chips are involved):

 http://usbgear.com/USB-Serial.html

 Our first 16 ports are on one of these:

 http://usbgear.com/computer_cable_details.cfm?sku=USB-16COM-RMcats=199catid=493%2C494%2C474%2C199%2C461%2C106%2C1009%2C601
 (the tx/rx blinky lights are handy in troubleshooting)

 Then the rest on this cheaper model:

 http://usbgear.com/computer_cable_details.cfm?sku=USBG-8COM-Mcats=199catid=494%2C199%2C474%2C2345%2C1009

 So for some reason there's a problem with the hub, and that's probably
 preventing it from getting as far as seeing the ftdi parts that are
 downstream of that.
 My dmesg snippet is from the latter box.  Note that the vendor and product 
 ID are the
 same as Karl's.  Perhaps there is a regression, as I am running 8.3 and 
 have had no
 issues there (previously it was on a 4.11 box).

 Charles

 That's the EXACT box.

 I've used them for a VERY long time on FreeBSD and they have always
 worked perfectly well, but never on 9.x until now -- and it doesn't work
 on 9.x.

 Had to run out for a while -- continuing testing.
 OK, with the kernel back the way it was, this is what I got:

 I plug in and get:

 Feb  4 21:17:46 FS kernel: uhub6: vendor 0x0409 product 0x0050, class
 9/0, rev 2.00/1.00, addr 4 on usbus4
 Feb  4 21:17:46 FS kernel: uhub_attach: port 1 power on failed,
 USB_ERR_STALLED
 Feb  4 21:17:46 FS kernel: uhub_attach: port 2 power on failed,

Re: So I whip out a FTDI-based multiport Serial USB Adapter.... [SB QUAR: Tue Feb 5 10:15:47 2013]

[Chris H]

 On 2/5/2013 10:15 AM, Chris H wrote:
 On 2/4/2013 9:33 PM, Karl Denninger wrote:
 On 2/4/2013 9:02 PM, Karl Denninger wrote:
 On 2/4/2013 4:32 PM, Charles Sprickman wrote:
 These multiport things have been around for a long time.  Someone at ISC 
 recommended
 them when we were looking to replace some unsupported RocketPort cards.  
 Not
 affiliated
 with this place, but it's the largest collection of USB to serial stuff 
 I've ever seen
 (and they document for the most part what chips are involved):

 http://usbgear.com/USB-Serial.html

 Our first 16 ports are on one of these:

 http://usbgear.com/computer_cable_details.cfm?sku=USB-16COM-RMcats=199catid=493%2C494%2C474%2C199%2C461%2C106%2C1009%2C601
 (the tx/rx blinky lights are handy in troubleshooting)

 Then the rest on this cheaper model:

 http://usbgear.com/computer_cable_details.cfm?sku=USBG-8COM-Mcats=199catid=494%2C199%2C474%2C2345%2C1009

 So for some reason there's a problem with the hub, and that's probably
 preventing it from getting as far as seeing the ftdi parts that are
 downstream of that.
 My dmesg snippet is from the latter box.  Note that the vendor and 
 product ID are the
 same as Karl's.  Perhaps there is a regression, as I am running 8.3 and 
 have had no
 issues there (previously it was on a 4.11 box).

 Charles

 That's the EXACT box.

 I've used them for a VERY long time on FreeBSD and they have always
 worked perfectly well, but never on 9.x until now -- and it doesn't work
 on 9.x.

 Had to run out for a while -- continuing testing.
 OK, with the kernel back the way it was, this is what I got:

 I plug in and get:

 Feb  4 21:17:46 FS kernel: uhub6: vendor 0x0409 product 0x0050, class
 9/0, rev 2.00/1.00, addr 4 on usbus4
 Feb  4 21:17:46 FS kernel: uhub_attach: port 1 power on failed,
 USB_ERR_STALLED
 Feb  4 21:17:46 FS kernel: uhub_attach: port 2 power on failed,
 USB_ERR_STALLED
 Feb  4 21:17:46 FS kernel: uhub_attach: port 3 power on failed,
 USB_ERR_STALLED
 Feb  4 21:17:46 FS kernel: uhub_attach: port 4 power on failed,
 USB_ERR_STALLED
 Feb  4 21:17:46 FS kernel: uhub_attach: port 5 power on failed,
 USB_ERR_STALLED
 Feb  4 21:17:47 FS kernel: uhub_attach: port 6 power on failed,
 USB_ERR_STALLED
 Feb  4 21:17:47 FS kernel: uhub_attach: port 7 power on failed,
 USB_ERR_STALLED
 Feb  4 21:17:47 FS kernel: uhub6: 7 ports with 7 removable, self powered

 FS/karl:/disk/karl usbconfig -u 4 -a 4 dump_device_desc
 ugen4.4: product 0x0050 vendor 0x0409 at usbus4, cfg=0 md=HOST
 spd=HIGH (480Mbps) pwr=SAVE

   bLength = 0x0012
   bDescriptorType = 0x0001
   bcdUSB = 0x0200
   bDeviceClass = 0x0009
   bDeviceSubClass = 0x
   bDeviceProtocol = 0x0001
   bMaxPacketSize0 = 0x0040
   idVendor = 0x0409
   idProduct = 0x0050
   bcdDevice = 0x0100
   iManufacturer = 0x  no string
   iProduct = 0x  no string
   iSerialNumber = 0x  no string
   bNumConfigurations = 0x0001

 I then issue and get:
 FS/karl:/disk/karl usbconfig -u 4 -a 4 power_on
 FS/karl:/disk/karl usbconfig -u 4 -a 4 dump_device_desc
 ugen4.4: product 0x0050 vendor 0x0409 at usbus4, cfg=0 md=HOST
 spd=HIGH (480Mbps) pwr=ON

   bLength = 0x0012
   bDescriptorType = 0x0001
   bcdUSB = 0x0200
   bDeviceClass = 0x0009
   bDeviceSubClass = 0x
   bDeviceProtocol = 0x0001
   bMaxPacketSize0 = 0x0040
   idVendor = 0x0409
   idProduct = 0x0050
   bcdDevice = 0x0100
   iManufacturer = 0x  no string
   iProduct = 0x  no string
   iSerialNumber = 0x  no string
   bNumConfigurations = 0x0001

 And if I turn it off and back on (power_off then power_on) the cycle
 repeats.  An attempt to reset is also futile, although the command is
 accepted.

 If I turn on hw.usb.uhub.debug I get a never-ending string of these:

 Feb  4 21:29:12 FS kernel: usb_needs_explore:
 Feb  4 21:29:12 FS kernel: usb_bus_powerd: bus=0xc646ac78
 Feb  4 21:29:12 FS kernel: usb_needs_explore:
 Feb  4 21:29:12 FS kernel: usb_bus_powerd: bus=0xc646ac78
 Feb  4 21:29:12 FS kernel: usb_needs_explore:
 Feb  4 21:29:12 FS kernel: usb_bus_powerd: bus=0xc646ac78
 Feb  4 21:29:12 FS kernel: usb_needs_explore:
 Feb  4 21:29:12 FS kernel: usb_bus_powerd: bus=0xc646ac78
 Feb  4 21:29:12 FS kernel: usb_needs_explore:
 Feb  4 21:29:12 FS kernel: usb_bus_powerd: bus=0xc646ac78
 Feb  4 21:29:13 FS kernel: usb_needs_explore:
 Feb  4 21:29:13 FS kernel: usb_bus_powerd: bus=0xc646ac78
 Feb  4 21:29:13 FS kernel: usb_needs_explore:
 Feb  4 21:29:13 FS kernel: usb_bus_powerd: bus=0xc646ac78
 Feb  4 21:29:13 FS kernel: usb_needs_explore:
 Feb  4 21:29:13 FS kernel: usb_bus_powerd: bus=0xc646ac78
 Feb  4 21:29:13 FS kernel: usb_needs_explore:
 Feb  4 21:29:13 FS kernel: usb_bus_powerd: bus=0xc646ac78

 Until the power is turned off on the device (with usbconfig -u 4 -a 4
 power_off), when it settles down to this once in a while:

 Feb  4 21:29:26 FS kernel: usb_needs_explore:
 Feb  4 21:29:26 FS kernel: usb_bus_powerd: bus=0xc6429cf0
 Feb  4 21:29:26 FS kernel: usb_bus_powerd: Recomputing power masks

Re: Does / Is anyone maintaining CVS for FreeBSD?

[Chris H]

Greetings Peter, and thank you _very_ much for the thoughtful, and
very informative reply -- _greatly_ appreciated.
 On Mon, Dec 31, 2012 at 2:39 PM, Chris H chris#@1command.com wrote:
 On 31 December 2012 15:40, Chris H chris#@1command.com wrote:
 Are there _any_ CVS servers/trunks/tree's left? If so, how _current_ are
 they?

 Ports and Source currently have CVS trees.
 Ports has an explicit EoL on February 28th (2 months from today)
 Source does not have an explicit EoL though it *is* considered deprecated.

 Thank you for providing this information, and my apologies, for not having
 better researched it myself. I'll make an effort to provide a permanent CVS
 repo for both src  ports.

 At the risk of a late reply stirring things up.

 doc and www were converted from cvs - svn in May 2012.  There was
 *never* a svn-cvs exporter for the doc/www trees - it was a clean
 break and switch over, and the cvs tree was closed.  However, a stale
 orphaned copy of the doc/www files were in the cvsup network.  If you
 were using those, you were using stale, out of date files.

 I've been rebuilding *.freebsd.org machines over the last 3-4 months
 and came across these stale files on a machine that was being
 decommissioned.  When I was building the replacement I didn't include
 them.

 The cvs exporter was running on a machine that was broken into.  The
 entire machine, code, exporters and cvs repository were considered
 tainted.  As the exported src cvs tree has been deprecated for years,
 we should have just turned it off, Instead we salvaged and reviewed
 what we could, threw together a really quick and dirty exporter
 replacement and made it run for a little longer.   It really is on its
 last legs.  Note that there is no practical way to audit a cvs tree
 after an incident like that, especially a deprecated tree at that.

 cvs for /usr/src was deprecated in October 2008.  The original plan
 for running the exporter for 2-3 months as a transition aide ran a
 little longer than planned.

 The branch support timeline is listed here: http://www.freebsd.org/security/

 As things stand right now, this is the exporter's run schedule:
 * RELENG_6:  Updates once a day, probably turning off on Feb 28th.
 * RELENG_7:  Updates hourly, probably turning off on Feb 28th at EOL
 * RELENG_7_4: Updates hourly, probably turning off on Feb 28th at EOL
 * RELENG_8:  Updates hourly
 * RELENG_8_3: Updates hourly
 * RELENG_9: Updates hourly
 * RELENG_9_0: Updates hourly
 * src-HEAD: Updates daily, probably turning off on Feb 28th.
 * ports-HEAD: Updates hourly, definitely turning off on Feb 28th.

 That's about what the limit of what the machine can handle.  When
 folks go on a commit spree, the poor thing runs its disks white-hot
 for a few hours to catch up.


 No new branches will ever make it into cvs.  eg: no RELENG_9_2.
 You'll have to get them from svn, just like getting updates to the
 older branches.

 Its also worth noting that all of the RELENG_9 series were released
 from the subversion tree - cvs was never involved.  If there's an 8.4,
 it'll have to be built from svn as well.

 We have some significant problems with both ezm3 and cvsup itself
 (which is written in Modula-3).  It basically is an inverse
 compatability binary..  The runtime code uses the oldest available
 versions of syscalls that it can, mostly the FreeBSD-4 versions.
 Emulation for some of the more exotic functionality - particularly
 signals - has become ... problematic .. lately.  It has memory
 corruption problems.  The cvsup/cvsupd servers break regularly when
 they corrupt their checkouts files and fetch the same data over and
 over and over again, crashing each time.

 And worse.. cvsup/cvsupd doesn't understand the version of cvs we have
 in the freebsd tree.  *Every* *single* *commit* causes a checksum
 error and re-fetch.  For the cvs/rcs ,v files, it degenerates into the
 old sup(1) mode - not even rsync.

 It is more efficient to transport the src cvs repository with rsync +
 rsyncd these days than cvsup/cvsupd.

 I'm sorry, but it is time to move on.

Understood.

--Chris

 --
 Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
 bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE
 ___
 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-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: Does / Is anyone maintaining CVS for FreeBSD?

[Chris H]

 On 1 January 2013 15:17, Alfred Perlstein bri...@mu.org wrote:
 On 1/1/13 6:55 AM, Eitan Adler wrote:

 On 1 January 2013 02:54, Derek Kulinski tak...@takeda.tk wrote:

 That said I would totally understand you being upset if FreeBSD would
 decide to switch to git, since despite its benefits that is a huge
 change, and would definitely be hard for people to adjust.

 Just In Case:

 FreeBSD has no plans to switch to get in either the short or long
 term.  We will however offer git repositories and first-class cousins
 via git.freebsd.org and github.


 Are you sure?  Most of the diffs developers have been handing me lately are
 of the form a/path b/path so I think they are mostly using git behind the
 scenes.

 Yes.  I use git behind the scenes as well.  However, so far as I am
 aware, there are no plans in either the short or long terms to
 *convert upstream* to git.

Thank God! I'd hate to think that after unwinding years accumulated
CVS process, to rewind it for SVN, only to have to do it again for GIT,
just seems a bit masochistic.

--Chris



 --
 Eitan Adler
 ___
 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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Does / Is anyone maintaining CVS for FreeBSD?

[Chris H]

Greetings,
 The following is hijacked from another thread, which prompts me to
post this question:

 On Mon, Dec 31, 2012 at 11:49:06AM -0600, Stephen Montgomery-Smith wrote:
 (Not sure if this is the right mailing list, but here goes.)


 -doc@ is a better choice.

 Last night I did a csup to retrieve the whole cvs repository.  I noticed
 that huge numbers of files in doc and www have been deleted.  Is this
 intentional, or is it the svn to cvs program not working properly?  And
 if it is the latter, are there plans to restore it?


 We are not exporting docs from SVN to CVS.  There are no plans to do so.

After more that 25yrs of enjoying *BSD, and all it has to offer. I find
myself ever so resistant to change -- what with all the maintenance scripts,
and procedures I've created/accumulated over the years. As I'm guessing I'm
not the only one feeling this way, I'm wondering if there is still a CVS
that's still current, that I might be able to mirror, and maintain, moving
forward? Perhaps this is all folly, but this subject has been bugging me
for some time, and reading this thread prompted me to attempt to address
it.

Thank you for all your time, and consideration.

--Chris


 Glen



___
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: Does / Is anyone maintaining CVS for FreeBSD?

[Chris H]

Greetings Chris, and thank you for your reply.
 On 31 Dec 2012 19:52, Chris H chris#@1command.com wrote:

 Greetings,
  The following is hijacked from another thread, which prompts me to
 post this question:

  On Mon, Dec 31, 2012 at 11:49:06AM -0600, Stephen Montgomery-Smith
 wrote:
  (Not sure if this is the right mailing list, but here goes.)
 
 
  -doc@ is a better choice.
 
  Last night I did a csup to retrieve the whole cvs repository.  I
 noticed
  that huge numbers of files in doc and www have been deleted.  Is this
  intentional, or is it the svn to cvs program not working properly?  And
  if it is the latter, are there plans to restore it?
 
 
  We are not exporting docs from SVN to CVS.  There are no plans to do so.

 After more that 25yrs of enjoying *BSD, and all it has to offer. I find
 myself ever so resistant to change -- what with all the maintenance
 scripts,
 and procedures I've created/accumulated over the years. As I'm guessing
 I'm
 not the only one feeling this way, I'm wondering if there is still a CVS
 that's still current, that I might be able to mirror, and maintain, moving
 forward? Perhaps this is all folly, but this subject has been bugging me
 for some time, and reading this thread prompted me to attempt to address
 it.

 Thank you for all your time, and consideration.

 I'm sorry, but the exporter scripts were always a stopgap.

That's what I was afraid I would hear. Recently, I was informed by SF.NET,
that my account would be upgraded, and all the projects I have, which all
use CVS, would be upgraded to SVN (which renders them useless). When I
asked why, they told me because CVS was so old. To which I stated:
Indeed, CVS is _quite_ old, and so is TCP/IP. Yet no one can seem live
without it.
Sigh...
IM(NS)HO; SVN is an inferior RCS created so Windows users wouldn't feel
left out.
Are there _any_ CVS servers/trunks/tree's left? If so, how _current_ are
they?

Thanks again for taking the time to reply, Chris.

All the best.

--Chris


 Help is available for updating your scripts to use Subversion, please feel
 free to ask.

 Chris


___
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: Does / Is anyone maintaining CVS for FreeBSD?

[Chris H]

Greetings Eitan, and thank you for your reply.

 On 31 December 2012 15:40, Chris H chris#@1command.com wrote:
 Sigh...
 IM(NS)HO; SVN is an inferior RCS created so Windows users wouldn't feel
 left out.

 SVN has a number of features which makes development much easier.

 What did you find easier to accomplish with CVS than with SVN?

I'm going to resist the temptation to respond to this, out of respect
to you, and the list -- lest it turn into a flame fest || bikeshed.
I understand that in the core development teams opinion, that the
project became too unwieldy to continue maintaining it under CVS. That's
their opinion, it's really their project, and I must respect _their_
opinion. That doesn't mean I like it -- or even agree. But, as I am the
recipient of the fruits of their labor, who am I to disagree. But,
none-the-less, opinions are like ass...ahem... backsides; everyone has
one. :)
There are arguments on both sides; some (perhaps you) feel SVN has/
provides more options, others (maybe myself) feel the same can be
accomplished with CVS, and that migration only causes more initial
(and unnecessary) overhead. I'll leave it at that. :)


 Are there _any_ CVS servers/trunks/tree's left? If so, how _current_ are
 they?

 Ports and Source currently have CVS trees.
 Ports has an explicit EoL on February 28th (2 months from today)
 Source does not have an explicit EoL though it *is* considered deprecated.

Thank you for providing this information, and my apologies, for not having
better researched it myself. I'll make an effort to provide a permanent CVS
repo for both src  ports.

Thanks again, for taking the time to respond.

--Chris



 --
 Eitan Adler


___
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: Does / Is anyone maintaining CVS for FreeBSD?

[Chris H]

Greetings Chris, and thank you for your reply.
 On 31 Dec 2012 20:40, Chris H chris#@1command.com wrote:

 Greetings Chris, and thank you for your reply.
  On 31 Dec 2012 19:52, Chris H chris#@1command.com wrote:
 
  Greetings,
   The following is hijacked from another thread, which prompts me to
  post this question:
 
   On Mon, Dec 31, 2012 at 11:49:06AM -0600, Stephen Montgomery-Smith
  wrote:
   (Not sure if this is the right mailing list, but here goes.)
  
  
   -doc@ is a better choice.
  
   Last night I did a csup to retrieve the whole cvs repository.  I
  noticed
   that huge numbers of files in doc and www have been deleted.  Is
 this
   intentional, or is it the svn to cvs program not working properly?
  And
   if it is the latter, are there plans to restore it?
  
  
   We are not exporting docs from SVN to CVS.  There are no plans to do
 so.
 
  After more that 25yrs of enjoying *BSD, and all it has to offer. I find
  myself ever so resistant to change -- what with all the maintenance
  scripts,
  and procedures I've created/accumulated over the years. As I'm guessing
  I'm
  not the only one feeling this way, I'm wondering if there is still a
 CVS
  that's still current, that I might be able to mirror, and maintain,
 moving
  forward? Perhaps this is all folly, but this subject has been bugging
 me
  for some time, and reading this thread prompted me to attempt to
 address
  it.
 
  Thank you for all your time, and consideration.
 
  I'm sorry, but the exporter scripts were always a stopgap.

 That's what I was afraid I would hear. Recently, I was informed by SF.NET,
 that my account would be upgraded, and all the projects I have, which all
 use CVS, would be upgraded to SVN (which renders them useless). When I
 asked why, they told me because CVS was so old. To which I stated:
 Indeed, CVS is _quite_ old, and so is TCP/IP. Yet no one can seem live
 without it.
 Sigh...
 IM(NS)HO; SVN is an inferior RCS created so Windows users wouldn't feel
 left out.
 Are there _any_ CVS servers/trunks/tree's left? If so, how _current_ are
 they?

 As far as I know, no FreeBSD CVS repos are current.

 Thanks again for taking the time to reply, Chris.

 You can run your own CVS server should you wish; it's not that hard; there
 are instructions at [1] if you want something more fully-featured.

 I promise you that there are many good reasons to switch to something
 better; I was an avid CVS user at one point, but I sure wouldn't go back
 now.

I'll try to be more objective -- I have my doubts, but maybe you're
correct. :)


 Chris

 [1] http://www.freebsd.org/doc/en/articles/cvs-freebsd/article.html

Thank you for the link. I'll look into it.


Thanks again.

--Chris

___
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: Does / Is anyone maintaining CVS for FreeBSD?

[Chris H]

Greetings Alfred, and thank you for the response.
 On 12/31/12 12:40 PM, Chris H wrote:
 | I'm sorry, but the exporter scripts were always a stopgap.
 That's what I was afraid I would hear. Recently, I was informed by SF.NET,
 that my account would be upgraded, and all the projects I have, which all
 use CVS, would be upgraded to SVN (which renders them useless). When I
 asked why, they told me because CVS was so old. To which I stated:
 Indeed, CVS is _quite_ old, and so is TCP/IP. Yet no one can seem live
 without it.
 Sigh...
 IM(NS)HO; SVN is an inferior RCS created so Windows users wouldn't feel
 left out.
 Are there _any_ CVS servers/trunks/tree's left? If so, how _current_ are
 they?

 Thanks again for taking the time to reply, Chris.

 All the best.

 You still really haven't come forward with a concrete reason besides my
 workflow and my scripts.

 Svn is a *near* drop in replacement for CVS.

 If instead of complaining and taking up bandwidth on the lists about old
 tech, you instead asked about how to move your archaic setup forward
 then someone would likely step forward and lend you a hand.

I /believe/ I covered this in response to an earlier reply. So I'll try
to respond, by quoting it here:
 What did you find easier to accomplish with CVS than with SVN?
I'm going to resist the temptation to respond to this, out of respect
to you, and the list -- lest it turn into a flame fest || bikeshed.
I understand that in the core development teams opinion, that the
project became too unwieldy to continue maintaining it under CVS. That's
their opinion, it's really their project, and I must respect _their_
opinion. That doesn't mean I like it -- or even agree. But, as I am the
recipient of the fruits of their labor, who am I to disagree. But,
none-the-less, opinions are like ass...ahem... backsides; everyone has
one. :)
There are arguments on both sides; some (perhaps you) feel SVN has/
provides more options, others (maybe myself) feel the same can be
accomplished with CVS, and that migration only causes more initial
(and unnecessary) overhead. I'll leave it at that. :)


 The project's goal is to support a large user base and the developers in
 a manner that works with our resources.  Supporting CVS (a 2nd gen VCS)
 while we have been on a 3rd gen (svn) and are finally looking into a 4th
 gen (git) is just unfair.

I won't contend, nor do I believe that you have not put adequate
research/investigation into all of this. And I can see that given it's
continued growth has prompted much -- if not all of these changes. I would
only argue at this point, that making changes mid-stream makes it difficult
for all concerned. I guess when it gets down to it, I just wish that all
these changes could have been evaluated to a point that would require one
one -- if any. Make no mistake, I am keenly aware that much has been done to
help minimize the impact -- and I _greatly_ appreciate it, and _all_ of the
work you all put into it. I guess I, like all humans, are resistant to
change (unless it's one they choose). But I have a tremendous amount of
tweaked ports  src I've been accumulating/maintaining over the years,
and _any_ change will come at great cost.
Sorry, maybe I'm just whining, but there it is. :/


 If you took a few minutes you'd fine the svn command set intuitive and a
 simple switch over from CVS.

I'll take your advice. I must admit, it's been awhile, since I've had the
need. I probably should look again.

Thank you for the advice, and taking the time to respond.

--Chris

P.S. Happy New Year! :)



 -Alfred
 ___
 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-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: Does / Is anyone maintaining CVS for FreeBSD?

[Chris H]

Greetings Kevin, and thank you for the reply.
 On Mon, Dec 31, 2012 at 12:40 PM, Chris H chris#@1command.com wrote:
 Greetings Chris, and thank you for your reply.
 On 31 Dec 2012 19:52, Chris H chris#@1command.com wrote:

 Greetings,
  The following is hijacked from another thread, which prompts me to
 post this question:

  On Mon, Dec 31, 2012 at 11:49:06AM -0600, Stephen Montgomery-Smith
 wrote:
  (Not sure if this is the right mailing list, but here goes.)
 
 
  -doc@ is a better choice.
 
  Last night I did a csup to retrieve the whole cvs repository.  I
 noticed
  that huge numbers of files in doc and www have been deleted.  Is this
  intentional, or is it the svn to cvs program not working properly?  And
  if it is the latter, are there plans to restore it?
 
 
  We are not exporting docs from SVN to CVS.  There are no plans to do so.

 After more that 25yrs of enjoying *BSD, and all it has to offer. I find
 myself ever so resistant to change -- what with all the maintenance
 scripts,
 and procedures I've created/accumulated over the years. As I'm guessing
 I'm
 not the only one feeling this way, I'm wondering if there is still a CVS
 that's still current, that I might be able to mirror, and maintain, moving
 forward? Perhaps this is all folly, but this subject has been bugging me
 for some time, and reading this thread prompted me to attempt to address
 it.

 Thank you for all your time, and consideration.

 I'm sorry, but the exporter scripts were always a stopgap.

 That's what I was afraid I would hear. Recently, I was informed by SF.NET,
 that my account would be upgraded, and all the projects I have, which all
 use CVS, would be upgraded to SVN (which renders them useless). When I
 asked why, they told me because CVS was so old. To which I stated:
 Indeed, CVS is _quite_ old, and so is TCP/IP. Yet no one can seem live
 without it.
 Sigh...
 IM(NS)HO; SVN is an inferior RCS created so Windows users wouldn't feel
 left out.
 Are there _any_ CVS servers/trunks/tree's left? If so, how _current_ are
 they?

 Have you actually looked at subversion?

I have, tho not that recently.

 It is designed to be as close
 as possible to the CVS command structure.  I can't imagine what it has
 to do with Windows. It was originally written by the same people
 responsible for CVS and I am reasonably certain it was written on a
 Unix/Linux system.

Linux, actually. There were many arguments that, while it was designed to
overcome the perceived shortcomings of CVS, that in the end it also
created new ones. I was on the lists. I still have the threads, but have
had to archive my INBOX so many times over the years, I wouldn't know
which one to unpack, nor would I want to bog down the list with this
anyway. :)


 I converted all of my scripts from csup to svn in a matter of minutes.
 Converting my source and ports trees to svn took a bit longer, but was
 almost all in the time it took to copy the files. An 'svn up
 /usr/ports' pretty much replaces 'csup ports-supfile', but runs much
 faster.

 All of that said, I still use CVS for on thing, RANCiD. (It is a
 system for managing router and switch configurations).It can use
 either CVS or SVN, but I keep the data is CVS as there is considerable
 advantage to being able to grep through the delta files to looks for
 some bit that has long been deleted. (We have about15 years worth of
 router configurations in our archive.) But this is a special case. I
 would never recommend anyone use CVS for general purpose code
 management, (Not sure I'd recommend svn, either, but others are far
 more of a change from CVS.


You're making a pretty good argument here -- I hate to admit.

 Give it a try:
 rm -r /usr/src/*  rm /usr/src/.*  svn co
 svn://closest_mirror/base/stable/9 /usr/src
 Then replace csup with 'svn up /usr/src'
 Then, to update, `

I'm skeptical, but I'll look again. It's been awhile, maybe it's
much better than it was last I used it.

Thank you for all the helpful tips, and taking the time to respond.

Happy New Year, to you, and yours!

--Chris

 R. Kevin Oberman, Network Engineer
 E-mail: kob6...@gmail.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: MFC: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) (fwd)

[Chris H]

 On 12/18/12 16:18, Robert Watson wrote:

 Dear all:

 Just an FYI that the new distributed audit daemon has been MFC'd to
 9-STABLE.

 Thanks.


 As noted in UPDATING, you will need to run mergemaster -p before
 using installkernel or installworld targets in order to add the new
 auditdistd system user.  This should be part of the regular update
 cycle anyway, but after the experience of adding auditdistd in
 10-CURRENT, we've discovered that many people are skipping that step
 in the update cycle, so I figured it best to point out here.

 (Technically, only installworld requires the user, but the user-check
 guards in the system Makefiles are enforced for both targets.)

 Maybe /usr/src/UPDATING should be updated?
 The end of /usr/src/UPDATING mentiones mergemaster -p after the
 installtion of the new kernel and rebooting to single user mode instead
 of before. This is on 9.1-RELEASE and also in CURRENT.

 At least the entry in /usr/src/UPDATING on CURRENT for this change

 20121201:
  With the addition of auditdistd(8), a new auditdistd user is now
  depended on during installworld.  mergemaster -p can be used
 to add
  the user prior to installworld, as documented in the handbook.

 should be prior to installkernel then also instead of prior to
 installworld

Greetings,
 FWIW, I just performed an build(world||kernel)  install(world||kernel) 
yesterday.
I used the following:

cd /usr/src

make buildworld
make buildkernel KERNCONF=mykern_name_here
make install KERNCONF=mykern_name_here

reboot to single user...

mount -u /
mount -a

cd /usr/src
mergemaster -p
blah,blah,blah...
make installworld
mergemaster
reboot

All of the auditdistd bits were merged into my system, and all is well.
Isn't that the way Updating lists the correct order?
Anyway, that's how I understood it, and just wanted to report that it
all worked as expected/anticipated.

HTH, and best wishes.

--Chris





 More details on the daemon below.

 Robert N M Watson
 Computer Laboratory
 University of Cambridge

 -- Forwarded message --
 Date: Sat, 1 Dec 2012 15:15:11 + (GMT)
 From: Robert Watson rwat...@freebsd.org
 To: curr...@freebsd.org
 Cc: secur...@freebsd.org
 Subject: Distributed audit daemon committed (was: svn commit: r243752
 - in head:
  etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin
 usr.sbin/auditdistd (fwd))


 Dear all:

 I've now committed the build glue required to install the recently
 merged Audit Distribution Daemon (auditdistd) contributed by the Pawel
 Dawidek, and sponsored by the FreeBSD Foundation.  This allows
 individual hosts generating audit trails to submit trails to a central
 audit server for review and safe keeping.  Part of the goal is to
 ensure that a host submitting trail data can't later modify the
 trails.  Pawel uses a variety of useful security- and
 resilience-related features such as TLS, Capsicum, etc, in
 auditdistd.  As the recent security incident in the FreeBSD.org
 cluster illustrated, having reliable and detailed audit trails makes a
 big difference in forensic work, and hopefully this will allow the
 FreeBSD Project (and our users) to do that better in the future.

 Robert N M Watson
 Computer Laboratory
 University of Cambridge

 -- Forwarded message --
 Date: Sat, 1 Dec 2012 15:11:46 + (UTC)
 From: Robert Watson rwat...@freebsd.org
 To: src-committ...@freebsd.org, svn-src-...@freebsd.org,
 svn-src-h...@freebsd.org
 Subject: svn commit: r243752 - in head: etc etc/defaults etc/mail
 etc/mtree
 etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd

 Author: rwatson
 Date: Sat Dec  1 15:11:46 2012
 New Revision: 243752
 URL: http://svnweb.freebsd.org/changeset/base/243752

 Log:
   Merge a number of changes required to hook up OpenBSM 1.2-alpha2's
   auditdistd (distributed audit daemon) to the build:

   - Manual cross references
   - Makefile for auditdistd
   - rc.d script, rc.conf entrie
   - New group and user for auditdistd; associated aliases, etc.

   The audit trail distribution daemon provides reliable,
   cryptographically protected (and sandboxed) delivery of audit tails
   from live clients to audit server hosts in order to both allow
   centralised analysis, and improve resilience in the event of client
   compromises: clients are not permitted to change trail contents
   after submission.

   Submitted by:pjd
   Sponsored by:The FreeBSD Foundation (auditdistd)

 Added:
   head/etc/rc.d/auditdistd   (contents, props changed)
   head/usr.sbin/auditdistd/
   head/usr.sbin/auditdistd/Makefile   (contents, props changed)
 Modified:
   head/etc/defaults/rc.conf
   head/etc/ftpusers
   head/etc/mail/aliases
   head/etc/master.passwd
   head/etc/mtree/BSD.var.dist
   head/etc/rc.d/Makefile
   head/share/man/man4/audit.4
   head/usr.sbin/Makefile

 Modified: head/etc/defaults/rc.conf
 ==

 --- 

Re: MFC: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd)) (fwd)

[Chris H]

 On 12/18/12 18:44, Chris H wrote:
 On 12/18/12 16:18, Robert Watson wrote:
 Dear all:

 Just an FYI that the new distributed audit daemon has been MFC'd to
 9
 20121201:
   With the addition of auditdistd(8), a new auditdistd user is now
   depended on during installworld.  mergemaster -p can be used
 to add
   the user prior to installworld, as documented in the handbook.

 should be prior to installkernel then also instead of prior to
 installworld
 Greetings,
   FWIW, I just performed an build(world||kernel)  install(world||kernel) 
 yesterday.
 I used the following:

 cd /usr/src

 make buildworld
 make buildkernel KERNCONF=mykern_name_here
 make install KERNCONF=mykern_name_here

 Hi
 I guess you did make installkernel instead of just make install
 KERNCONF=mykern_name_here ?

D'OH! :P

Sorry. That _should_ have read:

make installkernel KERNCONF=mykern_name_here
^^

Good catch! I can assure you, I _did_ do it correctly, when
actually performing the install. :)

FWIW Mine was a fresh install from the 9.0 CD1,
then a sync src, ports  make build(world||kernel); install(kernel||world).

Best wishes.

--Chris


 I did a day ago on a 9.1-RC3:

 freebsd-update
 make buildkernel
 make installkernel

 Then got prompted that the auditdistd user did not exist so I had to add
 it prior to installing the kernel.
 But this was when going from 9.1-RC3 to 9.1-RELEASE
 So I copied the bits from a CURRENT machine where everything went fine
 using the standard buildworld, buildkernel, installkernel, mergemaster
 -p, installworld, mergemaster procedure

 So that was not the usual way, but just using freebsd-update and
 installing a custom kernel.

 On CURRENT it went al well.

 Never mind and thanks.


 reboot to single user...

 mount -u /
 mount -a

 cd /usr/src
 mergemaster -p
 blah,blah,blah...
 make installworld
 mergemaster
 reboot

 All of the auditdistd bits were merged into my system, and all is well.
 Isn't that the way Updating lists the correct order?

 Yes it is. I did an unusual combination of binary update and then
 building and installing a custom kernel.

 Anyway, that's how I understood it, and just wanted to report that it
 all worked as expected/anticipated.

 HTH, and best wishes.

 --Chris



 ___
 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-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: buildkernel error ...

[Chris H]

 On 12/17/2012 1:35 AM, Chris H wrote:
 hi all,

 I run FreeBSD 9.0-STABLE #1: Sun Apr 15 21:08:51 UTC 2012 amd64

 yesterday I have cvsup-ed src and was trying to buildkernel
 bellow is error I receive:
 --- [ cut ]
 -
 ...
 cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99 -g -Wall
 -Wredundant-decls
 -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
 -Winline
 -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
 -Wmissing-include-dirs
 -fdiagnostics-show-option   -nostdinc  -I. -I/usr/src/sys 
 -I/usr/src/sys/contrib/altq
 -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
 -finline-limit=8000
 --param inline-unit-growth=100 --param large-function-growth=1000
 -fno-omit-frame-pointer
 -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
 -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror
 /usr/src/sys/xdr/xdr_reference.c
 cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99 -g -Wall
 -Wredundant-decls
 -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
 -Winline
 -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
 -Wmissing-include-dirs
 -fdiagnostics-show-option   -nostdinc  -I. -I/usr/src/sys 
 -I/usr/src/sys/contrib/altq
 -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
 -finline-limit=8000
 --param inline-unit-growth=100 --param large-function-growth=1000
 -fno-omit-frame-pointer
 -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
 -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror
 /usr/src/sys/xdr/xdr_sizeof.c
 cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99 -g -Wall
 -Wredundant-decls
 -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
 -Winline
 -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
 -Wmissing-include-dirs
 -fdiagnostics-show-option   -nostdinc  -I. -I/usr/src/sys 
 -I/usr/src/sys/contrib/altq
 -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
 -finline-limit=8000
 --param inline-unit-growth=100 --param large-function-growth=1000
 -fno-omit-frame-pointer
 -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
 -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror
 /usr/src/sys/amd64/acpica/acpi_machdep.c
 cc -c -x assembler-with-cpp -DLOCORE -O2 -frename-registers -pipe 
 -fno-strict-aliasing
 -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
 -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
 -Wno-pointer-sign
 -fformat-extensions  -Wmissing-include-dirs -fdiagnostics-show-option   
 -nostdinc  -I.
 -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL 
 -DHAVE_KERNEL_OPTION_HEADERS
 -include
 opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 
 --param
 large-function-growth=1000  -fno-omit-frame-pointer -mcmodel=kernel 
 -mno-red-zone
 -mno-mmx
 -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding 
 -fstack-protector
 -Werror /usr/src/sys/amd64/acpica/acpi_switch.S
 /usr/src/sys/amd64/acpica/acpi_switch.S: Assembler messages:
 /usr/src/sys/amd64/acpica/acpi_switch.S:146: Error: no such instruction: 
 `xsetbv'
 /usr/src/sys/amd64/acpica/acpi_switch.S:147: Error: no such instruction: 
 `xrstor (%rbx)'
 *** Error code 1

 Stop in /usr/obj/usr/src/sys/ZEUS_HOME.
 *** Error code 1

 Stop in /usr/src.
 *** Error code 1

 Stop in /usr/src.
 --- [ cut ]
 -


 nothing is changed in my kernel configuration file ...

 Greetings,
   I too attempted a buildworld, and a kernel yesterday (also synced 
 yesterday).
 It failed with a similar message to yours. I have _never_ experianced world,
 or kernel issues in the 25yrs I've been using BSD exclusively. Given that the
 only thing that has changed is the addition of clang, I'd recommend 
 performing a:
 make clean
 then try again with:
 make  -DWITHOUT_CLANG buildworld KERNCONF=your_kernel_name_here
 replacing your_kernel_name_here with the actual name of your KERNCONF file.

 I'm in the middle of a buildworld as I write this, that I believe will
 conclusively prove that clang was the reason my last attempt failed.

 HTH, and best wishes.

 --Chris

 P.S. This was also 9.1



 --
 Zeus V. Panchenko   jid:z...@im.ibs.dn.ua
 IT Dpt., I.B.S. LLC   GMT+2 (EET)
 ___
 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-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo

Re: buildkernel error ...

[Chris H]

 On 12/17/2012 1:35 AM, Chris H wrote:
 hi all,

 I run FreeBSD 9.0-STABLE #1: Sun Apr 15 21:08:51 UTC 2012 amd64

 yesterday I have cvsup-ed src and was trying to buildkernel
 bellow is error I receive:
 --- [ cut ]
 -
 ...
 cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99 -g -Wall
 -Wredundant-decls
 -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
 -Winline
 -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
 -Wmissing-include-dirs
 -fdiagnostics-show-option   -nostdinc  -I. -I/usr/src/sys 
 -I/usr/src/sys/contrib/altq
 -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
 -finline-limit=8000
 --param inline-unit-growth=100 --param large-function-growth=1000
 -fno-omit-frame-pointer
 -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
 -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror
 /usr/src/sys/xdr/xdr_reference.c
 cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99 -g -Wall
 -Wredundant-decls
 -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
 -Winline
 -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
 -Wmissing-include-dirs
 -fdiagnostics-show-option   -nostdinc  -I. -I/usr/src/sys 
 -I/usr/src/sys/contrib/altq
 -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
 -finline-limit=8000
 --param inline-unit-growth=100 --param large-function-growth=1000
 -fno-omit-frame-pointer
 -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
 -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror
 /usr/src/sys/xdr/xdr_sizeof.c
 cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99 -g -Wall
 -Wredundant-decls
 -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
 -Winline
 -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
 -Wmissing-include-dirs
 -fdiagnostics-show-option   -nostdinc  -I. -I/usr/src/sys 
 -I/usr/src/sys/contrib/altq
 -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
 -finline-limit=8000
 --param inline-unit-growth=100 --param large-function-growth=1000
 -fno-omit-frame-pointer
 -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
 -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror
 /usr/src/sys/amd64/acpica/acpi_machdep.c
 cc -c -x assembler-with-cpp -DLOCORE -O2 -frename-registers -pipe 
 -fno-strict-aliasing
 -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
 -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
 -Wno-pointer-sign
 -fformat-extensions  -Wmissing-include-dirs -fdiagnostics-show-option   
 -nostdinc  -I.
 -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL 
 -DHAVE_KERNEL_OPTION_HEADERS
 -include
 opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 
 --param
 large-function-growth=1000  -fno-omit-frame-pointer -mcmodel=kernel 
 -mno-red-zone
 -mno-mmx
 -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding 
 -fstack-protector
 -Werror /usr/src/sys/amd64/acpica/acpi_switch.S
 /usr/src/sys/amd64/acpica/acpi_switch.S: Assembler messages:
 /usr/src/sys/amd64/acpica/acpi_switch.S:146: Error: no such instruction: 
 `xsetbv'
 /usr/src/sys/amd64/acpica/acpi_switch.S:147: Error: no such instruction: 
 `xrstor (%rbx)'
 *** Error code 1

 Stop in /usr/obj/usr/src/sys/ZEUS_HOME.
 *** Error code 1

 Stop in /usr/src.
 *** Error code 1

 Stop in /usr/src.
 --- [ cut ]
 -


 nothing is changed in my kernel configuration file ...

 Greetings,
   I too attempted a buildworld, and a kernel yesterday (also synced 
 yesterday).
 It failed with a similar message to yours. I have _never_ experianced world,
 or kernel issues in the 25yrs I've been using BSD exclusively. Given that the
 only thing that has changed is the addition of clang, I'd recommend 
 performing a:
 make clean
 then try again with:
 make  -DWITHOUT_CLANG buildworld KERNCONF=your_kernel_name_here
 replacing your_kernel_name_here with the actual name of your KERNCONF file.

 I'm in the middle of a buildworld as I write this, that I believe will
 conclusively prove that clang was the reason my last attempt failed.

 HTH, and best wishes.

 --Chris

 P.S. This was also 9.1



 --
 Zeus V. Panchenko   jid:z...@im.ibs.dn.ua
 IT Dpt., I.B.S. LLC   GMT+2 (EET)
 ___
 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-stable@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo

Re: How do I circumvent the use of clang during build?

[Chris H]

Greetings Beeblebrox, and thank you for your reply.

 have a look at /etc/src.conf and
 $ man src.cof
 you can set many buildworld options there.

Good advise! Thanks.

--Chris




 --
 View this message in context:
 http://freebsd.1045724.n5.nabble.com/How-do-I-circumvent-the-use-of-clang-during-build-tp5769907p5770203.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



-- 

___
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: How do I circumvent the use of clang during build?

[Chris H]

Greetings, and thank you for your reply.

 Wouldn't this be a case where man src.conf on his system actually wouldn't
 tell the OP what he wanted, as clang was not available as option in 8? Of
 course the online version of that man page from RELENG_9* would.

Indeed, and _boy_ was I surprised, when I watched it start to build.
I found no mention of it in updating either.

Thanks again, for your reply.

--Chris


 Best regards
 Andreas


 On Mon, Dec 17, 2012 at 9:54 PM, Beeblebrox zap...@berentweb.com wrote:

 have a look at /etc/src.conf and
 $ man src.cof
 you can set many buildworld options there.



 --
 View this message in context:
 http://freebsd.1045724.n5.nabble.com/How-do-I-circumvent-the-use-of-clang-during-build-tp5769907p5770203.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

 ___
 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-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: buildkernel error ...

[Chris H]

 On 2012-12-17 (Monday) 17:02:06 Chris H wrote:
  On 12/17/2012 1:35 AM, Chris H wrote:
  hi all,
 
  I run FreeBSD 9.0-STABLE #1: Sun Apr 15 21:08:51 UTC 2012 amd64
 
  yesterday I have cvsup-ed src and was trying to buildkernel
  bellow is error I receive:
  --- [ cut ]
  
  - ...
  cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99 -g
  -Wall
  -Wredundant-decls
  -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes
  -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign
  -fformat-extensions  -Wmissing-include-dirs -fdiagnostics-show-option
  -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL
  -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
  -finline-limit=8000
  --param inline-unit-growth=100 --param large-function-growth=1000
  -fno-omit-frame-pointer
  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
  -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror
  /usr/src/sys/xdr/xdr_reference.c
  cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99 -g
  -Wall
  -Wredundant-decls
  -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes
  -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign
  -fformat-extensions  -Wmissing-include-dirs -fdiagnostics-show-option
  -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL
  -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
  -finline-limit=8000
  --param inline-unit-growth=100 --param large-function-growth=1000
  -fno-omit-frame-pointer
  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
  -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror
  /usr/src/sys/xdr/xdr_sizeof.c
  cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99 -g
  -Wall
  -Wredundant-decls
  -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes
  -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign
  -fformat-extensions  -Wmissing-include-dirs -fdiagnostics-show-option
  -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL
  -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common
  -finline-limit=8000
  --param inline-unit-growth=100 --param large-function-growth=1000
  -fno-omit-frame-pointer
  -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
  -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror
  /usr/src/sys/amd64/acpica/acpi_machdep.c
  cc -c -x assembler-with-cpp -DLOCORE -O2 -frename-registers -pipe
  -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls
  -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
  -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign
  -fformat-extensions  -Wmissing-include-dirs -fdiagnostics-show-option
  -nostdinc  -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL
  -DHAVE_KERNEL_OPTION_HEADERS -include
  opt_global.h -fno-common -finline-limit=8000 --param
  inline-unit-growth=100 --param large-function-growth=1000
  -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx
  -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding
  -fstack-protector -Werror /usr/src/sys/amd64/acpica/acpi_switch.S
  /usr/src/sys/amd64/acpica/acpi_switch.S: Assembler messages:
  /usr/src/sys/amd64/acpica/acpi_switch.S:146: Error: no such instruction:
  `xsetbv' /usr/src/sys/amd64/acpica/acpi_switch.S:147: Error: no such
  instruction: `xrstor (%rbx)' *** Error code 1
 
  Stop in /usr/obj/usr/src/sys/ZEUS_HOME.
  *** Error code 1
 
  Stop in /usr/src.
  *** Error code 1
 
  Stop in /usr/src.
  --- [ cut ]
  
  -
 
 
  nothing is changed in my kernel configuration file ...
 
  Greetings,
 
I too attempted a buildworld, and a kernel yesterday (also synced
yesterday).
  It failed with a similar message to yours. I have _never_ experianced
  world, or kernel issues in the 25yrs I've been using BSD exclusively.
  Given that the only thing that has changed is the addition of clang, I'd
  recommend performing a: make clean
  then try again with:
  make  -DWITHOUT_CLANG buildworld KERNCONF=your_kernel_name_here
  replacing your_kernel_name_here with the actual name of your KERNCONF
  file.
 
  I'm in the middle of a buildworld as I write this, that I believe will
  conclusively prove that clang was the reason my last attempt failed.
 
  HTH, and best wishes.
 
  --Chris
 
  P.S. This was also 9.1
 
  --
  Zeus V. Panchenkojid:z...@im.ibs.dn.ua
  IT Dpt., I.B.S. LLCGMT+2 (EET)
  ___
  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

Installworld failure on RELENG_9

[Chris H]

Greetings,
 I've used BSD exclusively since the early 80's, and this is my first
experience with a build(world|kernel) || install(world|kernel) fail.
That said, after installing from a 9.0 CD  syncing src  ports,
I began the process of building and installing a custom kernel, and
building  installing world.
kernel went as expected/anticipated. However, as buildworld (altho slow)
went without incident, installworld failed:

-- begin error output -
/usr/src/lib/csu/i386-elf/crti.S:26:25 error: machine/asm.h: No such file or 
directory
/usr/src/lib/csu/i386-elf/crti.S: Assembler messages:
/usr/src/lib/csu/i386-elf/crti.S:27: Error: invalid character '_' in mnemonic
*** Error code 1

Stop in /usr/src/lib/csu/i386-elf.
*** Error code 1

Stop in /usr/src/lib.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.
-- end error output -

Additional info:
FreeBSD 9.1-PRERELEASE #0 Sun Dec 16 21:27:50 PST 2012
root@ns0:/usr/obj/usr/src/sys/GENERIC i386

The only difference (aside from BSD version) was the addition of clang.
It took easily 3 times as long to complete world than past experience. :(

Thank you for all your time, and consideration.

--Chris

___
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: Installworld failure on RELENG_9

[Chris H]

Greetings Gary, and thank you for your reply.

 On Sun, Dec 16, 2012 at 03:07:46PM -0800, Chris H wrote:
 Greetings,
  I've used BSD exclusively since the early 80's, and this is my first
 experience with a build(world|kernel) || install(world|kernel) fail.
 That said, after installing from a 9.0 CD  syncing src  ports,
 I began the process of building and installing a custom kernel, and
 building  installing world.
 kernel went as expected/anticipated. However, as buildworld (altho slow)
 went without incident, installworld failed:


 You should run 'buildworld' first, because that creates the toolchain
 for the kernel build.

Yes. That was the order I used (world, kernel),. Sorry if that wasn't clearer.


 Anyway, what does your custom kernel config contain?  Please attach it.

 Glen


Consider it done (see attached).

FWIW: I synced src  ports yesterday (2012-12-15) from cvsup7.freebsd.org

--Chris
#
# NS0 -- NS0 kernel configuration file for FreeBSD/i386
#
# For more information on this file, please read the config(5) manual page,
# and/or the handbook section on Kernel Configuration Files:
#
#
http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
# $FreeBSD: src/sys/i386/conf/NS0,v 1.6.2.16 2012/12/16 20:20:10 chrish Exp $

cpu I686_CPU
ident   NS0

makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols

options SCHED_ULE   # ULE scheduler
options PREEMPTION  # Enable kernel thread preemption
options INET# InterNETworking
options INET6   # IPv6 communications protocols
options SCTP# Stream Control Transmission Protocol
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
options UFS_ACL # Support for access control lists
options UFS_DIRHASH # Improve performance on big directories
options UFS_GJOURNAL# Enable gjournal-based UFS journaling
options MD_ROOT # MD is a potential root device
options NFSCL   # New Network Filesystem Client
options NFSD# New Network Filesystem Server
options NFSLOCKD# Network Lock Manager
options NFS_ROOT# NFS usable as /, requires NFSCL
options MSDOSFS # MSDOS Filesystem
options CD9660  # ISO 9660 Filesystem
options PROCFS  # Process filesystem (requires PSEUDOFS)
options PSEUDOFS# Pseudo-filesystem framework
options GEOM_PART_GPT   # GUID Partition Tables.
options GEOM_RAID   # Soft RAID functionality.
options GEOM_LABEL  # Provides labelization
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
options COMPAT_FREEBSD5 # Compatible with FreeBSD5
options COMPAT_FREEBSD6 # Compatible with FreeBSD6
options COMPAT_FREEBSD7 # Compatible with FreeBSD7
options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI
options KTRACE  # ktrace(1) support
options STACK   # stack(9) support
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time 
extensions
options PRINTF_BUFR_SIZE=128# Prevent printf output being 
interspersed.
options KBD_INSTALL_CDEV# install a CDEV entry in /dev
options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4)
options AUDIT   # Security event auditing
options MAC # TrustedBSD MAC Framework
#optionsKDTRACE_HOOKS   # Kernel DTrace hooks
options INCLUDE_CONFIG_FILE # Include this file in kernel
options KDB # Kernel debugger related code
options KDB_TRACE   # Print a stack trace for a panic

# To make an SMP kernel, the next two lines are needed
options SMP # Symmetric MultiProcessor Kernel
device  apic# I/O APIC

# CPU frequency

How do I circumvent the use of clang during build?

[Chris H]

Greetings,
 I recently made a failed attempt to move from RELENG_8
to RELENG_9. I've been on BSD since the early 80's, and with
the exception of a couple of failed kernels (my fault), I've
never had one failure with the build(world|kernel) ||
install(world|kernel). The only notable difference I noticed,
was the addition of clang. While I can't (yet) conclusively
blame it on clang. I _can_ say, that the whole process took _3_
times longer, than without. So my question is; is it possible
to build(world|kernel)  install(world|kernel) without the
clang toolchain? If for no other reason but to discover whether
clang was responsible for the failure, and whether building w/o
clang is any faster.

Thank you for all your time, and consideration.

--Chris

___
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: How do I circumvent the use of clang during build?

[Chris H]

Greetings, and thank you for the response.

 On 16 December 2012 21:17, Tim Daneliuk tun...@tundraware.com wrote:
 As I understand it, gcc is still the default on 9

 For the build, but clang is still built.

 is it possible
to build(world|kernel)  install(world|kernel) without the
clang toolchain?

 make -DWITHOUT_CLANG

Good news! Thanks for taking the time to respond Eitan.

--Chris



 --
 Eitan Adler


___
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: buildkernel error ...

[Chris H]

 hi all,

 I run FreeBSD 9.0-STABLE #1: Sun Apr 15 21:08:51 UTC 2012 amd64

 yesterday I have cvsup-ed src and was trying to buildkernel
 bellow is error I receive:
 --- [ cut ]
 -
 ...
 cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99 -g -Wall 
 -Wredundant-decls
 -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
 -Winline
 -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
 -Wmissing-include-dirs
 -fdiagnostics-show-option   -nostdinc  -I. -I/usr/src/sys 
 -I/usr/src/sys/contrib/altq
 -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
 -finline-limit=8000
 --param inline-unit-growth=100 --param large-function-growth=1000  
 -fno-omit-frame-pointer
 -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
 -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror
 /usr/src/sys/xdr/xdr_reference.c
 cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99 -g -Wall 
 -Wredundant-decls
 -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
 -Winline
 -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
 -Wmissing-include-dirs
 -fdiagnostics-show-option   -nostdinc  -I. -I/usr/src/sys 
 -I/usr/src/sys/contrib/altq
 -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
 -finline-limit=8000
 --param inline-unit-growth=100 --param large-function-growth=1000  
 -fno-omit-frame-pointer
 -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
 -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror
 /usr/src/sys/xdr/xdr_sizeof.c
 cc -c -O2 -frename-registers -pipe -fno-strict-aliasing  -std=c99 -g -Wall 
 -Wredundant-decls
 -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith 
 -Winline
 -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions  
 -Wmissing-include-dirs
 -fdiagnostics-show-option   -nostdinc  -I. -I/usr/src/sys 
 -I/usr/src/sys/contrib/altq
 -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common 
 -finline-limit=8000
 --param inline-unit-growth=100 --param large-function-growth=1000  
 -fno-omit-frame-pointer
 -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
 -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror
 /usr/src/sys/amd64/acpica/acpi_machdep.c
 cc -c -x assembler-with-cpp -DLOCORE -O2 -frename-registers -pipe 
 -fno-strict-aliasing
 -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
 -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef 
 -Wno-pointer-sign
 -fformat-extensions  -Wmissing-include-dirs -fdiagnostics-show-option   
 -nostdinc  -I.
 -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL 
 -DHAVE_KERNEL_OPTION_HEADERS -include
 opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 
 --param
 large-function-growth=1000  -fno-omit-frame-pointer -mcmodel=kernel 
 -mno-red-zone -mno-mmx
 -mno-sse -msoft-float  -fno-asynchronous-unwind-tables -ffreestanding 
 -fstack-protector
 -Werror /usr/src/sys/amd64/acpica/acpi_switch.S
 /usr/src/sys/amd64/acpica/acpi_switch.S: Assembler messages:
 /usr/src/sys/amd64/acpica/acpi_switch.S:146: Error: no such instruction: 
 `xsetbv'
 /usr/src/sys/amd64/acpica/acpi_switch.S:147: Error: no such instruction: 
 `xrstor (%rbx)'
 *** Error code 1

 Stop in /usr/obj/usr/src/sys/ZEUS_HOME.
 *** Error code 1

 Stop in /usr/src.
 *** Error code 1

 Stop in /usr/src.
 --- [ cut ]
 -


 nothing is changed in my kernel configuration file ...

Greetings,
 I too attempted a buildworld, and a kernel yesterday (also synced yesterday).
It failed with a similar message to yours. I have _never_ experianced world,
or kernel issues in the 25yrs I've been using BSD exclusively. Given that the
only thing that has changed is the addition of clang, I'd recommend performing 
a:
make clean
then try again with:
make  -DWITHOUT_CLANG buildworld KERNCONF=your_kernel_name_here
replacing your_kernel_name_here with the actual name of your KERNCONF file.

I'm in the middle of a buildworld as I write this, that I believe will
conclusively prove that clang was the reason my last attempt failed.

HTH, and best wishes.

--Chris

P.S. This was also 9.1



 --
 Zeus V. Panchenko jid:z...@im.ibs.dn.ua
 IT Dpt., I.B.S. LLC GMT+2 (EET)
 ___
 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-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to 

What's the most effective way to restart net children?

[Chris H]

Greetings,
 I've always maintained at least a /24 since the early 80's.
I'm now evaluating a new ISP, and am not ready to commit. Until then I'll be
forced to use DHCP. My problem is that they are really mercenary about their
lease(s) -- ~24hrs! So, given that I am treating the assigned IP(s) as 
pseudo-static,
I would prefer not to bounce the box(es).
I currently bounce them alternating rc  hosts, etc. I can easily switch configs
on the fly by restarting network  related services, but am looking for a
_graceful_ way to re-start the network. I see /etc/netstart, but it looks a 
little
more /brutal/ than I was hoping for. Any and all suggestions _greatly_ 
appreciated.

Thank you for all your time, and consideration.

--Chris

___
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: What's the most effective way to restart net children?

[Chris H]

 On Mon, 2012-12-03 at 08:05 -0800, Chris H wrote:
 Greetings,
  I've always maintained at least a /24 since the early 80's.
 I'm now evaluating a new ISP, and am not ready to commit. Until then I'll be
 forced to use DHCP. My problem is that they are really mercenary about their
 lease(s) -- ~24hrs! So, given that I am treating the assigned IP(s) as 
 pseudo-static,
 I would prefer not to bounce the box(es).
 I currently bounce them alternating rc  hosts, etc. I can easily switch 
 configs
 on the fly by restarting network  related services, but am looking for a
Greetings IAn, and thank you for your reply...
 _graceful_ way to re-start the network. I see /etc/netstart, but it looks a 
 little
 more /brutal/ than I was hoping for. Any and all suggestions _greatly_ 
 appreciated.

 Thank you for all your time, and consideration.

 --Chris


 You can use service netif restart to restart / re-dhcp all the
 interfaces.  Doing it that way will do ALL interfaces, including
 loopback, which can break running programs that are using it.  You can
 name one or more interfaces to be restarted instead of letting it do all
 of them.

 Do you have any reason to think the short leases time will somehow lead
 to changing IPs?  My provider gives me 12 hour leases, and my IP hasn't
 changed in like 7 years.

 -- Ian
Yes, that was always the way I used to experience it (other ISP's).
The IP never changed after leases renewed. But now not only the IP, but the 
netmask
changes, anywhere from 255.2455.254.0 to 255.255.252.0, no even 255.255.255.255!
I'd blow them off because of this. But thus far, I really like everything else,
and as a result, will likely simply lease a /24 from them. But until (of if) I 
make
that decision, it's really a PITA.

Great advice. I'll look into your suggestion(s). I currently boot into an 
rc.conf(5)
with the ifconfig(8) line as DHCP, to obtain the new lease. Then bounce the 
box(es)
with the ifconfig(8) line(s) setup as they would be when used with static 
address(es).
Given your advice, it looks like I can cobble up a script to use service(8) to
shutdown all the services that depend in network, and then use service(8) to 
restart
the network interfaces to garner the new IP(s) and then restart the network, and
utilize it as static, bringing up the services that depend on it.

Thanks again for your reply.

--Chris





___
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