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 Sat, 23 Jun 2018 02:56:35 +0900 (JST) "Yasuhiro KIMURA"  
said


From: "Chris H" 
Subject: Re: Console is broken after updating to 11.2-RELEASE
Date: Fri, 22 Jun 2018 06:13:39 -0700

> 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!


Thank you for information. I added above lines to /boot/loader.conf
and rebooted system. Then all boot messages are displayed and console
works fine!


WooHoo! :-)

I could make further observations based on *why* that worked. But several
are likely, and I don't have enough info on your hardware. But now that
you are no longer "blind". You should have little trouble sorting out the
cause.

--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: 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&utm_content=webmail> Без
> вирусов. www.avast.ru
>  n=sig-email&utm_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 Condition
> (da6:mpr0:0:25:0): SCSI sense: UNIT ATTENTION asc:29,0 (Power on, reset,
> or b

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 any mail to "freebsd-stable-unsubscr...@freebsd.o

Re: pkg upgrade problem with Perl 5.24

[Chris H]

On Fri, 13 Jan 2017 16:38:59 + Matthew Seaman  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  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  wrote

> On Wed, Mar 2, 2016 at 3:56 PM, Chris H  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  wrote

> On Wed, Mar 2, 2016 at 12:40 PM, Chris H  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+&cd=1&h
> l=de&ct=clnk&gl=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  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  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  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  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 Fri, 24 Jul 2015 01:00:03 + Glen Barber  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: 10.2-Beta i386..what's wrong..?

[Chris H]

On Thu, 23 Jul 2015 23:48:06 + Glen Barber  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: How to track stable on multiple servers?

[Chris H]

On Mon, 1 Jun 2015 16:19:46 +0300 Kimmo Paasiala  wrote

> On Mon, Jun 1, 2015 at 4:10 PM, Slawa Olhovchenkov  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  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 20:28:15 -0400 J David  wrote

> On Thu, Mar 26, 2015 at 8:25 PM, Chris H  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: Significant memory leak in 9.3p10?

[Chris H]

On Thu, 26 Mar 2015 14:03:45 -0700 Kevin Oberman  wrote

> On Thu, Mar 26, 2015 at 12:46 PM, J David  wrote:
> 
> > On Mon, Mar 16, 2015 at 7:52 PM, J David  wrote:
> > > On Mon, Mar 16, 2015 at 7:24 PM, Konstantin Belousov
> > >  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: 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 
wrote

> On Tue, Mar 10, 2015 at 2:01 PM, Chris H  wrote:
> 
> > > >
> > >
> > > https://svnweb.freebsd.org/base?view=revision&revision=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:34:30 +0100 Piotr Kubaj  wrote

> On 03/11/15 02:12, Chris H wrote:
> > On Tue, 10 Mar 2015 12:15:22 +0100 Piotr Kubaj  wrote
> > 
> >> On 03/08/15 22:15, Chris H wrote:
> >>> On Sun, 08 Mar 2015 19:14:47 +0100 Piotr Kubaj  wrote
> >>>
> >>>> On 03/07/15 01:55, Chris H wrote:
> >>>>> On Sat, 07 Mar 2015 00:08:38 +0100 Piotr Kubaj 
> >>>>> 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: 
> >>> and
> >>> hdac1: 
> >>> 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 li

Re: No sound on 10.1-RELEASE

[Chris H]

On Wed, 11 Mar 2015 23:09:31 +0100 Piotr Kubaj  wrote

> On 03/11/15 02:12, Chris H wrote:
> > On Tue, 10 Mar 2015 12:15:22 +0100 Piotr Kubaj  wrote
> > 
> >> On 03/08/15 22:15, Chris H wrote:
> >>> On Sun, 08 Mar 2015 19:14:47 +0100 Piotr Kubaj  wrote
> >>>
> >>>> On 03/07/15 01:55, Chris H wrote:
> >>>>> On Sat, 07 Mar 2015 00:08:38 +0100 Piotr Kubaj 
> >>>>> 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: 
> >>> and
> >>> hdac1: 
> >>> 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 l

Re: No sound on 10.1-RELEASE

[Chris H]

On Tue, 10 Mar 2015 12:15:22 +0100 Piotr Kubaj  wrote

> On 03/08/15 22:15, Chris H wrote:
> > On Sun, 08 Mar 2015 19:14:47 +0100 Piotr Kubaj  wrote
> > 
> >> On 03/07/15 01:55, Chris H wrote:
> >>> On Sat, 07 Mar 2015 00:08:38 +0100 Piotr Kubaj  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: 
> > and
> > hdac1: 
> > 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: Is there a linux_base available for RELENG_9?

[Chris H]

On Tue, 10 Mar 2015 11:29:12 + Pete French 
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"

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 
wrote

> On Tue, Mar 10, 2015 at 7:05 AM, Peter Olsson  > 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=revision&revision=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: 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"  wrote

> On Tue, 10 Mar 2015 13:05:40 +0100 Peter Olsson
>  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 13:05:40 +0100 Peter Olsson 
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: Is there a linux_base available for RELENG_9?

[Chris H]

On Mon, 9 Mar 2015 18:41:59 -0700 Freddie Cash  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"  wrote:
> 
> > On Tue, 10 Mar 2015 00:51:06 +0000 Gary Palmer  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 01:11:10 + Gary Palmer  wrote

> On Mon, Mar 09, 2015 at 06:09:04PM -0700, Chris H wrote:
> > On Tue, 10 Mar 2015 00:51:06 + Gary Palmer  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: Is there a linux_base available for RELENG_9?

[Chris H]

On Tue, 10 Mar 2015 00:51:06 + Gary Palmer  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 Mon, 09 Mar 2015 20:45:11 -0400 Adam McDougall  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"

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

[Chris H]

On Sun, 08 Mar 2015 19:14:47 +0100 Piotr Kubaj  wrote

> On 03/07/15 01:55, Chris H wrote:
> > On Sat, 07 Mar 2015 00:08:38 +0100 Piotr Kubaj  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:  (play)
> >> pcm1:  (play)
> >> pcm2:  (play)
> >> pcm3:  (play)
> >> pcm4:  (play/rec) default
> >> pcm5:  (play/rec)
> >> pcm6:  (play)
> >> pcm7:  (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: 
and
hdac1: 
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  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:  (play)
> pcm1:  (play)
> pcm2:  (play)
> pcm3:  (play)
> pcm4:  (play/rec) default
> pcm5:  (play/rec)
> pcm6:  (play)
> pcm7:  (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"

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"

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: 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"

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"

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 Patrick, and thank you for the reply.
> Le Thu, 1 Aug 2013 08:31:45 -0700 (PDT),
> "Chris H"  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 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"

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: 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: 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"

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

[Chris H]

>
> On 30.07.2013, at 19:49, Peter Maxwell  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: 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: 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 '^' 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  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 
> 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"

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"

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"

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

[Chris H]

> In message ,
>   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"

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: 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"

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]

> 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//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"

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//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"

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"

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.... [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-RM&cats=199&catid=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-M&cats=199&catid=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: >>> 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:  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  
>>>>   iProduct = 0x  
>>>>   iSerialNumber = 0x  
>>>>   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:  at usbus4, cfg=0 md=HOST
>>>> spd=HIGH (480Mbps) pwr=ON
>>>>
>>>>   bLength = 0x0012
>>>>   bDescriptorType = 0x0001
>>>>   bcdUSB = 0x0200
>>>>   bDeviceClass = 0x0009
>>>>   bDeviceSubClass = 0x0

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:  at usbus4
>> uhub6: > 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:  at usbus1
>> uhub4:  
>> on usbus1
>> uhub4: 7 ports with 7 removable, self powered
>>
>> Then the individual ports look like this:
>>
>> ugen1.4:  at usbus1
>> uftdi0:  on usbus1
>> ugen1.5:  at usbus1
>> uftdi1:  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-RM&cats=199&catid=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-M&cats=199&catid=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 regr

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  wrote:
>>> On 31 December 2012 15:40, Chris H  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  wrote:
>> On 1/1/13 6:55 AM, Eitan Adler wrote:
>>>
>>> On 1 January 2013 02:54, Derek Kulinski  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"

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  wrote:
>> Greetings Chris, and thank you for your reply.
>>> On 31 Dec 2012 19:52, "Chris H"  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: 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 Chris, and thank you for your reply.
> On 31 Dec 2012 20:40, "Chris H"  wrote:
>>
>> Greetings Chris, and thank you for your reply.
>> > On 31 Dec 2012 19:52, "Chris H"  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 Eitan, and thank you for your reply.

> On 31 December 2012 15:40, Chris H  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 19:52, "Chris H"  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"

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: 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=
>> make install KERNCONF=
>
> Hi
> I guess you did make installkernel instead of just make install
> KERNCONF= ?

D'OH! :P

Sorry. That _should_ have read:

make installkernel KERNCONF=
^^

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: 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=
make install KERNCONF=

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 
>> 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 
>> 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

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

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  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: 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: 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 
>

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 
>

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=
replacing  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/lis

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  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"

How do I circumvent the use of clang during build?

[Chris H]

Greetings,
 I recently made a  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: 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 ma

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: 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"