Re: Delay in 14.0-RELEASE cycle and blocking items

[Rainer Duffner]

> Am 03.05.2023 um 18:27 schrieb Glen Barber :
> 
> On Wed, May 03, 2023 at 07:53:09AM +, Alexey Dokuchaev wrote:
>> On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote:
>>> ...
>>> There is no feasible way we are going to make the branch point of
>>> stable/14 in time, with that scheduled for May 12, 2023 with the above
>>> points.  That said, this is not an all-inclusive list, but the more
>>> major items on our radar at the moment.
>> 
>> Does this delay mean we might get Clang 16 in the base?
>> 
> 
> Well, the delay really means we do not currently have OpenSSL 3 in base.
> 
> Glen
> 

I cannot help with this, of course.

But out of interest: what are the problems?

There was a post on the haproxy mailing-list a while back, linking to some 
github issue and from what I understood, there are huge performance-problems in 
there.


Rainer

Re: smartpqi: panic: malloc(M_WAITOK) with sleeping prohibited

[Rainer Duffner]

> Am 31.01.2022 um 21:13 schrieb Yuri :
> 
> Got this panic after booting GENERIC kernel:
> 



Probably best to open a PR.

It usually gets assigned to the microchip-people - I’m not sure if they are 
following the mailing-lists.

Re: storcli: howto crossflash Fujitsu PRAID400i to LSI3008 HBA?

[Rainer Duffner]

> Am 23.06.2021 um 13:04 schrieb O. Hartmann :
> 
> Does anyone have had success on flashing this type of SAS controller from IR
> firmware to IT firmware?



Hi,

I once tried to cross-flash a HP H220 (IIRC) to LSI 2008 (or whatever), because 
HP would not update the firmware (anymore) and obviously does not bother about 
FreeBSD (never did…).

It actually worked, but only with a very old version of LSI’s flash tools 
(newer versions refused to do it).

Of course, the HBA did not work better afterwards and the only „fix“ was to buy 
actual LSI hardware.

IIRC, for our Supermicro Servers, the firmware is/was really identical, except 
for a vendor-string (which a co-worker changed using a hex-editor).

But you can never be too sure about that and the best (and only IMO) way is to 
avoid OEM HBAs like the plague and buy them directly from the people who 
designed the hardware in the first place.

Re: Update to the 13.0-RELEASE schedule

[Rainer Duffner]

> Am 31.03.2021 um 17:58 schrieb Glen Barber :
> 
> A small set of updates that we consider blocking the 13.0 release have
> been brought to our attention.  As such, the 13.0-RELEASE schedule has
> been updated to include a fifth release candidate (RC5).
> 
> The updated schedule is available on the FreeBSD Project website:
> 
> https://www.freebsd.org/releases/13.0R/schedule/
> 
> As usual, we will continue to consider critical bug fixes only for the
> duration of this release cycle.
> 
> Thank you for your cooperation, and for your patience.
> 
> Glen
> On behalf of: re@
> 



The truth is that a lot people don’t really start testing until the later 
release candidates.

So, having more of these release candidates with just refinements is a good 
thing, IMHO.



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

Re: Plans for git (was: Please check the current beta git conversions)

[Rainer Duffner]

> Am 02.09.2020 um 18:22 schrieb Warner Losh :
> 
> 
> 
>> On Sep 2, 2020, at 10:14 AM, Ed Maste  wrote:
>> 
>> On Wed, 2 Sep 2020 at 02:31, Steve Kargl
>>  wrote:
>>> 
 A short intro on git for svn users:
 https://hackmd.io/ML5TSl8mQ5-27B5eqDf7YA?view
 
>>> 
>>> ROTFL.  From the "short intro", 2nd sentence.
>>> 
>>> New committers are assumed to already be familiar with the basic
>>> operation of Git.  If not, start by reading the Git Book.
>> 
>> This doc started as a direct translation of the Subversion primer,
>> which has as its first sentence:
>>> New committers are assumed to already be familiar with the basic operation 
>>> of Subversion. If not, start by reading the Subversion Book.
>> 
>> As with the Subversion primer the doc is intended to provide a quick
>> reference for day-to-day commands, but not act as a reference or
>> introduction to the entire theory of operation of the associated VCS.
> 
> The rest of the guide walks people through how to do the job, but without all 
> the theory for the basics.
> 
> Again it needs some work for the advanced topic it currently just omits…
> 



Sorry, but I had to think of this:


https://xkcd.com/1597/


The project was announced a while back in the quarterly status report (that’s 
the first time I read about it at least).

It’s obviously a huge undertaking, the people taking part in it should be 
commended, not ridiculed (IMO).

For people who don’t have much exposure to git, it can be very obnoxious. 

Though these days, a lot of people assume git=github and the GUI there 
certainly makes things easier.

If it wasn’t completely riddled with security-holes, I would recommend the 
project to run its own gitlab instance - but for a project this size, you’d be 
looking at a FTE just herding that bag of cats and constantly upgrading it…



 



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

Re: failing to install 11.1R on VMWare

[Rainer Duffner]

Can you export the empty VM and make it available for download somewhere?

If you zero the disks with dd before exporting, it should compress very nicely.


I only have Fusion to test, though.




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

Re: freebsd-update: to a specific patch level - help please?

[Rainer Duffner]

> Am 21.03.2018 um 22:12 schrieb Derek (freebsd lists) 
> <48225...@razorfever.net>:
> 
> Hi!
> 
> I was surprised when using freebsd-update, that there was no way to specify a 
> patch level.



AFAIK, the usual answer to these kinds of requests is: „Run your own 
freebsd-update server“.

Mirroring one of the existing ones is AFAIK neither guaranteed to work nor 
desired by the current „administration“.

I’ve contemplated doing both, but never had enough heart-ache to do it and 
never thought the pay-off would be greater than the potential problems.

It’s also a somewhat transient problem now because - AFAIK - FreeBSD will see 
packaged base and you can probably mirror those packages and snapshot the 
directory at any point in time.
And/Or it’s just easier to create these base-packages yourselves vs. running 
your own freebsd-update server.






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

Re: How to find CPU microcode version ?

[Rainer Duffner]

> Am 18.02.2018 um 11:41 schrieb Kurt Jaeger :
> 
> Hi!
> 
> How do I find the microcode version a Intel CPU is currently using ? 
> 



AFAIK:
All Linux-vendors have retracted their microcode-updates, for the time being.

If your BIOS-vendor didn’t provide you an updated BIOS, just forget about 
„fixing" the various Spectre-variants.



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

Re: extending the maximum filename length (pointer to patch)[request for input]

[Rainer Duffner]

> Am 12.09.2017 um 23:11 schrieb Ben RUBSON :
> 
> On 12/9/17 2:17 pm, Conrad Meyer wrote:
>> On Sat, Sep 9, 2017 at 9:09 AM, Julian Elischer  wrote:
>>> maybe we could get it into -current.
>>> It'd be silly to have to have people re-inventing hte wheel all the time.
>>> How about you put those changes into the reviews.freebsd.org and we can get
>>> some general consensus on them.
>>> We'll have to do similar for the Asian customers and anyone who uses UTF-8.
>>> So it
>>> would be silly to have to develop it all again (but subtly different of
>>> course).
>>> 
>>> The key issue is how many system calls and other APIs would be broken,
>>> and how many would be broken in a non backwards compatible way?
>>> 
>>> We would need it in a stable/10 and 11 branch but if the patch is isolated
>>> enough we could carry it forward until we get to 12.
>>> 
>>> One has to allow people to do whatever they are used to with Windows.
>>> And in this case the issue is serving files over samba to windows machines.
>> Hey Julian,
>> 
>> I've thrown the patch up at https://reviews.freebsd.org/D12330 .  I
>> haven't actually tested it on FreeBSD, but it does compile.  We also
>> have some patches against contrib/pjdfstest to fix those tests against
>> long file names, but I think we can hold off on those changes until
>> we've nailed down what the architectural change will be (if any).
> 
> Hi Conrad,
> 
> This patch makes me think about another related bug #184340 :
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184340 
> 
> It is about PATH_MAX which in some cases can be too small.
> 
> Not sure if it's the case / and how to do it,
> but perhaps it is time to raise some other limits /
> think about a global solution regarding these length limits ?
> 
> Many thanks !
> 
> Ben



And there’s also this bug:


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215067 


"g_dev_taste: make_dev_p() failed on importing pool with snapshots with long 
names“



But maybe that has nothing to do with it.






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

Re: [CFT] packaging the base system with pkg(8)

[Rainer Duffner]

> Am 18.04.2016 um 22:07 schrieb Lev Serebryakov :
> 
> On 18.04.2016 22:40, Glen Barber wrote:
> 
>> This granularity allows easy removal of things that may not be wanted
>> (such as *-debug*, *-profile*, etc.) on systems with little storage.  On
>> one of my testing systems, I removed the tests packages and all debug
>> and profiling, and the number of base system packages is 383.
> IMHO, granularity like "all base debug", "all base profile" is enough
> for this. Really, I hardly could imagine why I will need only 1 debug or
> profile package, say, for csh. On resource-constrained systems NanoBSD
> is much better anyway (for example, my typical NanoBSD installation is
> 37MB base system, 12MB /boot and 10 packages), and on developer system
> where you need profiled libraries it is Ok to install all of them and
> don't think about 100 packages for them.
> 
> Idea of "Roles" from old FreeBSD installers looks much better. Again,
> here are some "contrib" software which have one-to-one replacements in
> ports, like sendmail, ssh/sshd, ntpd, but split all other
> FreeBSD-specific code? Yes, debug. Yes, profile. Yes, static libraries.
> Yes, lib32 on 64 bit system.
> 
>  It seems that it is ideological ("holy war") discussion more than
> technical one...



From the discussion, I believe it’s primarily driven by the need/desire to have 
small packages to make updates easier on the mirror-servers.

I’m really not sure (yet), which is worse: the current system that pulls down 
some 14k small files for a system-upgrade - or a system where the base-system 
is split into almost 800 packages.

freebsd-update is „only" unreliable if
 - you go through a proxy with authentication
 - that proxy doesn’t do http-pipelining (or does it bad/is broken is this 
respect) (certain version of Sophos UTM for example…)

AFAIK.

As for the packages: I wouldn’t mind „fatter“ packages. I’d mirror them locally 
anyway (I hope this is possible - AFAIK, the freebsd-update files are not 
supposed to be mirrored), and I don’t have a thousand servers to pull them down 
all at once anyway (working on that ;-)).

I’m pretty sure the impact on the current FreeBSD delivery infrastructure would 
be quite substantial, if updates came in 60MB chunks - esp. if there was some 
sort of auto-update mechanism in place.
Fast-forward to the future where a lot (millions?) more embedded devices are 
based on FreeBSD and pull updates from the FreeBSD infrastructure.
Or if the container hype-train reached FreeBSD and people started to 
containerize everything, resulting in even more base-package update downloads.

So, I can see both sides. Neither I’m really satisfied with.

I hope a way is found to manage these number of packages without losing sanity 
and that a normal pkg info doesn’t list them.
And that pkg upgrade doesn’t upgrade base-packages.


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

Re: OCZ ssdpx-1rvd0120 REVODRIVE support

[Rainer Duffner]

> Am 17.04.2016 um 11:05 schrieb Pavel Timofeev :
> 
> HI! I've recently got a SSD device. Yes, not a disk, but a device.
> It's called, i. e. one of the first REVODRIVEs.
> It's a PCI-express card with two embedded ssd disks about ~ 55GB size.
> And it's a raid card. Fake software raid. You can set it up as a
> RAID0, RAID1, etc and a CONCATENATION. No way to leave it unconfigured
> or set it as JBOD or something else.
> You just won't be able to boot from this device in that case.
> 



It says „Linux support planned“…

on the product page.

Tried loading the  nvme(4) driver at the countdown?

https://www.freebsd.org/cgi/man.cgi?query=nvme&sektion=4


I’d suspect the Intel SSD 750 series would be a better choice…



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

Re: Voxer using FreeBSD, BSDNow.tv interview

[Rainer Duffner]

>> 
> Yes that is the job of the maintainer, so bugging the chef maintainer is the
> right thing to do.
> 
> Maintaining a port meaning making sure it workds properly the FreeBSD way.


The omnibus installer is not a port.
AFAIK.
It’s the installer provided by Chef (the company, formerly known as „Opscode“).

It’s basically a shell-script with an archive attached that dumps stuff into 
/opt/chef and creates a couple of symlinks.



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

Re: Voxer using FreeBSD, BSDNow.tv interview

[Rainer Duffner]

> Am 20.10.2014 um 10:19 schrieb David Chisnall :
> 
> 
> I presume that most of the relevant differences are for users / developers 
> and not sysadmins?  It's worth noting that GNU coreutils, tar, bash, and a 
> load of other things are in the ports repository.  I wonder if it's worth 
> having a gnu-userland metaport, perhaps with something like the Solaris 
> approach of sticking them all in a different tree so that you can just add 
> that to the start of your PATH and have all of the GNU tools work by default. 
>  
> 


They use chef.
The chef omnibus installer assumes there is a /bin/bash. Even the FreeBSD 
version of it. Well, it least it did the last time I looked. Maybe this got 
fixed in the meantime.
Which means that to „bootstrap“ a node, you’ve first got to install pkg on it, 
install bash, symlink it to /bin/bash and then bootstrap the node.
Which kind of runs against the concept of doing everything via chef.






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

Re: gptzfsboot problem on HP P410i Smart Array

[Rainer Duffner]

Am Thu, 10 Apr 2014 06:59:25 +0200
schrieb Andreas Nilsson :


> > You never specified exactly how it fails. But I'll take a guess:
> 
> *Attempting Boot From Hard Drive (C:)*
> 
> *gptzfsboot: error 1 lba 32*
> 
> *gptzfsboot: error 1 lba 1*
> 
> *g**ptzfsboot: No ZFS pools located, can't boot*


True.

But as that was the failure-symptom of the original thread, I kind of
neglected to mention it
 
> A workaround is
> http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026624.html



Yes, but that requires rebuilding FreeBSD.

Why has this never been patched "properly"?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: gptzfsboot problem on HP P410i Smart Array

[Rainer Duffner]

Am 10.04.2014 um 00:02 schrieb Matthew Seaman :

> On 09/04/2014 22:52, Rainer Duffner wrote:
>> And no, as the server is in a remote datacenter, an USB-stick is not an 
>> option.
>> 
>> It’s slow enough booting via a virtual USB-image over iLO...
> 
> Uh... it only has to read the kernel+modules from the USB stick one time
> while booting.  Otherwise, there really shouldn't be any IO inside /boot
> unless you login and do stuff in that directory manually.  Your root
> filesystem would be on the normal hard drives.
> 
> Anyhow the question is moot, since you don't have the same problem I did.
> 
>> No, it’s actually just a single RAID6-0 disk created by the P410i…
> 
> If you're going to use the RAID controller to generate a virtual drive,
> do you really need to use ZFS on top of that?   Couldn't you partition
> your virtual drive and put / onto a small UFS partition and then make a
> zpool on the rest?


I don’t want to sacrifice two disks for a RAID1 boot-disk.
Normally, I would actually do that, but in this case, the server is a 
MySQL-slave to a master that has 12 disks -  and should the master die, this 
system has to take over its work.


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

Re: gptzfsboot problem on HP P410i Smart Array

[Rainer Duffner]

Am 09.04.2014 um 23:48 schrieb Matthew Seaman :

> On 09/04/2014 22:17, Rainer Duffner wrote:
>> Hi,
>> 
>> I found this old thread….
>> 
>> I can’t boot FreeBSD 10 installed with zfsroot on a DL380G7 (P410i 
>> controller).
>> I tried the installer and I tried installing with mfsbsd10se.
>> System has 48GB RAM.
>> 
>> Is there a PR for this?
>> 
>> 
>> Now, I’ve got to waste 2’600 GB disks (and 300-odd I/Os) for a boot-disk…..
> 
> You've got more than 8 drives in your spool?  



No, it’s actually just a single RAID6-0 disk created by the P410i…

And no, as the server is in a remote datacenter, an USB-stick is not an option.

It’s slow enough booting via a virtual USB-image over iLO...

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

Re: gptzfsboot problem on HP P410i Smart Array

[Rainer Duffner]

Hi,

I found this old thread….

I can’t boot FreeBSD 10 installed with zfsroot on a DL380G7 (P410i controller).
I tried the installer and I tried installing with mfsbsd10se.
System has 48GB RAM.

Is there a PR for this?


Now, I’ve got to waste 2’600 GB disks (and 300-odd I/Os) for a boot-disk…..


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

Re: Scripts for booting FreeBSD images from the install ISO for use in Jenkins?

[Rainer Duffner]

Am Mon, 17 Mar 2014 19:30:01 -0700
schrieb Craig Rodrigues :

> Hi,
> 
> For the BSD DevSummit in May, one of the items
> on our agenda:
> 
> https://wiki.freebsd.org/201405DevSummit/Jenkins
> 
> is to talk about writing scripts which can take a FreeBSD ISO image,
> and then boot it and run it on a remote system or in a VM
> to install the OS.  After the OS is up, we would like to run tests.
> All of this would be triggered from Jenkins.
> 
> Does anyone have scripts which can do this?
> Can they be contributed to the Jenkins effort on FreeBSD?
> 
> If you have scripts in Python, Ruby, Bourne shell, etc. are all fine,
> or even recipes in automation frameworks like Puppet, Ansible, Chef,
> SaltStack, etc.,
> please let us know! :)



I would have loved to attend this talk:


http://2014.asiabsdcon.org/timetable.html.en#P7A


Hopefully, more documentation and/or the slides/the video for this talk
will become available.


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

Re: freebsd-update

[Rainer Duffner]

Am 25.01.2014 um 16:11 schrieb Mark Felder :

> 
> 
> On Sat, Jan 25, 2014, at 5:32, Lars Engels wrote:
>> 
>> 
>> Also using freebsd-update behind a proxy is really slow. Even with a
>> very fast internet connection (normally download rates ca. 3 MBytes / s)
>> downloading all the tiny binary diff files took more than 8 hours.
>> Maybe freebsd-update's backend could create a tarball of all those diffs
>> and provide this? 
> 
> Even streaming the tar instead of waiting for the freebsd-update server
> to produce the tarball would be an improvement. I have no experience
> doing that over a WAN but I don't see why it would be unreliable.


Apropos proxy:
freebsd-update does not work behind a proxy that requires authentication.
At least not with our proxy (which is a Sophos/Astaro „threat management 
appliance").
That’s OK for me, because I can talk the proxy-guys here into making an 
exception for my FreeBSD-servers - but It’s really a nuisance because 
everything else (that uses libfetch) can use proxy-authentication.




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

Re: rcs

[Rainer Duffner]

Am 08.10.2013 um 22:29 schrieb Cy Schubert :

> 
> A Red Hat-like kickstart or Solaris jumpstart possibly? 
> 



http://blog.hostileadmin.com/2013/04/11/installing-freebsd-via-cobbler/


I wish it was using bsdinstall, though.



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

Re: [HEADSUP] No more pkg_install on HEAD by default

[Rainer Duffner]

Am 15.07.2013 um 03:15 schrieb Adrian Chadd :

> Guys,
> 
> Devin runs a _lot_ of FreeBSD stuff at his work.


Doubtlessly.
It wouldn't make sense on a small scale.


I assume, his system pre-dates most of the stuff nowadays filed under the 
"dev-ops" moniker (chef, puppet…).
Probably also has (had) less overhead ;-)



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

Re: [HEADSUP] No more pkg_install on HEAD by default

[Rainer Duffner]

Am 15.07.2013 um 00:43 schrieb Craig Rodrigues :

> On Sat, Jul 13, 2013 at 10:54 PM, Teske, Devin 
> wrote:
> 
>> 
>> 
>> I assume that poudiere builds packages from ports.
>> 
> 
> Yes.
> 
> 
>> 
>> That's not how we build package repositories here (and would expect that
>> there are many more like us).
>> 
> 
> How do you build packages if you are not using FreeBSD ports?  



If I understand him correctly, he uses packages built elsewhere and re-packages 
them into his own format?
http://druidbsd.sourceforge.net/download.shtml#pkgbase

I don't really see any value in this. At some point, his scripts etc. have to 
be packaged anyway?
It should not be a problem running one server/VM for each system.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Upgrading FreeBSD to use the NEW pf syntax. (Copied from freebsd-pf)

[Rainer Duffner]

Am Tue, 20 Nov 2012 13:24:49 +0100
schrieb Olivier Smedts :


> Another question : how did OpenBSD managed this change ?


AFAIK, their users are used to stuff just disappearing or changing.
Remember that pf started as a replacement to ipf and the rulesets had
to be rewritten anyway.

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

Re: Looking for bge(4) , bce(4) and igb(4) cards

[Rainer Duffner]

Am Wed, 14 Nov 2012 11:31:08 +0100
schrieb Andre Oppermann :

> Hello
> 
> I currently working on a number of drivers for popular network
> cards and extend them with automatic hybrid interrupt/polling
> ithread processing with life-lock prevention (so that the driver
> can't consume all CPU when under heavy load or attack).
> 
> To properly test this I need the proper hardware as PCIe network
> cards:
> 
> bge(4) Broadcom BCM57xx/BCM590x
> bce(4) Broadcom NetXtreme II (BCM5706/5708/5709/5716)
> igb(4) Intel PRO/1000 i82575, i82576, i82580, i210, i350


Hallo Andre,

wie lange würdest Du die Karten brauchen?

igb(4) könnte ich vielleicht leihweise organisieren.
Wir werden davon eh' einen Haufen bestellen müssen, weil die NetFlex
Karten in HPs Gen8-Servern nicht unter FreeBSD laufen - und das wird
sich eher nicht ändern die nächste Zeit, so wie es aussieht



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

Re: Buying recommendation for silent router/fileserver

[Rainer Duffner]

Am Fri, 12 Oct 2012 11:03:10 +0200
schrieb Ulrich Spörlein :

> Interesting one, with only one GigE port though, both PCIe slots would
> need to be populated to get a second Ethernet and a Wifi port ...


As said, it would be better to use a 2nd system (ALIX only uses 5-10W or
so) for WIFI (and even then, the pfSense folk recommends using a
dedicated AP on OPT1 to handle the WIFI-stuff) - unless you want it to
act as a client only.
Then an USB-stick should do, right? Or one of the WLAN-bridges for
40€
Does FreeNAS do VLANs?
Then, you'd only need a VLAN-capable switch and one NIC would be
enough. I don't think the machine could saturate 2 GBIT-ports anyway...
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Buying recommendation for silent router/fileserver

[Rainer Duffner]

Am 11.10.2012 um 18:52 schrieb Adam McDougall :
> 
> Be wary of the Soekris net6501, 

[…]

The Soekris, AFAIK, is an embedded platform.
It doesn't surprise me the least that it's not good at I/O.
That's the reason why I suggested the HP.
At least, it does decent I/O, if you want to believe reports.

I would really also recommend to separate the router and 
fileserver-functionality.
AFAIK, the N40L supports Wake-on-LAN (and pfSense does, too), so you should be 
able to wake it up even without getting up from the couch ;-)

I never really got warm with the Soekris-stuff - but then, I'm in Switzerland 
and PC-Engines was always very quick with shipping ;-)


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

Re: Buying recommendation for silent router/fileserver

[Rainer Duffner]

Am Thu, 11 Oct 2012 16:54:53 +0200
schrieb Ulrich Spörlein :

> Hey guys,
> 
> I need to replace an aging Pentium IV system that has been serving as
> my router, access point, file- and mediaserver for quite some time
> now. The replacement should have:
> 
> - amd64 CPU (for ZFS, obviously)
> - 2x GigE (igress, egress interfaces)
> - some form of wlan interface (I currently use an Atheros based PCI
> card)
> - eSATA for attaching a backup disk where I stream ZFS snapshots to
> - serial port is always nice, for when I mess up an upgrade
> - fan-less if possible
> 
> So far, this here seems to fit the bill perfectly
> http://www.fit-pc.com/web/fit-pc/intensepc/
> but pricing seems to defy any reality.
> 
> It does not state directly which chipsets are used for Wifi and
> Ethernet, the block diagram claims Ethernet chips to be Intel 82579
> and RTL8111D, but I don't trust that fully.
> 
> For Wifi I can always fall back to sticking in a supported USB stick,
> although that's kinda hacky.
> 
> So how well is networking going to be supported by FreeBSD? Should I
> just bite the bullet and find out?



What about the 

HP ProLiant N40L
?

It's not fanless, of course - but it's IMO more suited for a
server-type system than anything else in that price-range.

I don't have one (I have no need for anything beyond what an
AlIX-system can do) - but if I would need a home-server, I'd buy a N40L
(it can boot from USB and you can thus boot FreeNAS from it)



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

Re: Where to ask questions about poudriere?

[Rainer Duffner]

Am Thu, 6 Sep 2012 14:59:03 +0300
schrieb Alexander Yerenkow :

> I don't see where you specify your zfs tank, is it missed in mail, or
> in conf?

It slipped into the previous line:

ZPOOL=datapool
FTPHOST=ftp.ch.freebsd.org
FREEBSD_HOST=http://ftp.ch.freebsd.org/
RESOLV_CONF=/etc/resolv.conf
BASEFS=/usr/local/poudriere
USE_PORTLINT=no
USE_TMPFS=yes
DISTFILES_CACHE=/usr/ports/distfiles
CSUP_HOST=localhost
CHECK_CHANGED_OPTIONS=yes
PKG_REPO_SIGNING_KEY=/etc/ssl/keys/repo.bla.ch.key
CCACHE_DIR=/data/cache/ccache


I've somehow missed that poudriere is a shell-script.

somewhere down there, it sets
PORTSDIR=/ports

is that correct?
I think it should be /usr/ports...


+ echo '>> Starting jail 90amd64'
>> Starting jail 90amd64
+ jrun 0
+ [ 1 -ne 1 ]
+ local network=0
+ local ipargs
+ [ 0 -eq 0 ]
+ ipargs='ip4.addr=127.0.0.1 ip6.addr=::1'
+ jail -c persist name=90amd64 ip4.addr=127.0.0.1 ip6.addr=::1
  path=/usr/local/poudriere/jails/90amd64 host.hostname=90amd64
  allow.sysvipc allow.mount allow.socket_af allow.raw_sockets
  allow.chflags
+ [ 1 -eq 1 ]
+ export STATUS=1
+ prepare_jail
+ export PACKAGE_BUILDING=yes
+ export USER=root
+ port_get_base default
+ [ 1 -ne 1 ]
+ zfs list -rt filesystem -H -o
  poudriere:type,poudriere:name,mountpoint datapool/poudriere
+ awk -v n=default '$1 == "ports" && $2 == n { print $3 }'
+ PORTSDIR=/ports
+ POUDRIERED=/usr/local/share/poudriere/../../etc/poudriere.d
+ [ -z /usr/local/poudriere/jails/90amd64 ]
+ [ -z /ports ]
+ [ -z /usr/local/poudriere/data/packages/90amd64-default ]
+ [ -n '' -a -n yes ]
+ msg 'Mounting ports filesystems for 90amd64'
+ echo '>> Mounting ports filesystems for 90amd64'
>> Mounting ports filesystems for 90amd64
+ do_portbuild_mounts 1
+ [ 1 -ne 1 ]
+ local should_mkdir=1
+ [ 1 -eq 1 ]
+ mkdir -p /ports/packages
+ mkdir -p /usr/local/poudriere/data/packages/90amd64-default/All
+ [ -n /usr/ports/distfiles -a -d /usr/ports/distfiles ]
+ mkdir -p /usr/local/poudriere/jails/90amd64/usr/ports/distfiles
+ [ -n /data/cache/ccache -a -d /data/cache/ccache ]
+ mkdir -p /usr/local/poudriere/jails/90amd64/data/cache/ccache
+ msg 'Mounting ccache from /data/cache/ccache'
+ echo '>> Mounting ccache from /data/cache/ccache'
>> Mounting ccache from /data/cache/ccache
+ export CCACHE_DIR
+ mount -t nullfs /ports /usr/local/poudriere/jails/90amd64/usr/ports
+ mount -t
  nullfs /usr/local/poudriere/data/packages/90amd64-default 
/usr/local/poudriere/jails/90amd64/usr/ports/packages
+ [ -n /usr/ports/distfiles -a -d /usr/ports/distfiles ]
+ mount -t
  nullfs /usr/ports/distfiles 
/usr/local/poudriere/jails/90amd64/usr/ports/distfiles
  mount: /usr/local/poudriere/jails/90amd64/usr/ports/distfiles: No
  such file or directory
+ err 1 'Failed to mount the distfile directory'



 
> 2012/9/6 Rainer Duffner 
> 
> > Hi,
> >
> > I'm trying to get poudriere working with the following settings:
> >
> > f2d169d8-20d2-41d4-8e43-8a9fc5a2b509#
> > cat /usr/local/etc/poudriere.conf |grep -v ^# |grep -v ^$
> > ZPOOL=datapool FTPHOST=ftp.ch.freebsd.org
> > FREEBSD_HOST=http://ftp.ch.freebsd.org/
> > RESOLV_CONF=/etc/resolv.conf
> > BASEFS=/usr/local/poudriere
> > USE_PORTLINT=no
> > USE_TMPFS=yes
> > DISTFILES_CACHE=/usr/ports/distfiles
> > CSUP_HOST=localhost
> > CHECK_CHANGED_OPTIONS=yes
> > PKG_REPO_SIGNING_KEY=/etc/ssl/keys/repo.bla.ch.key
> > CCACHE_DIR=/data/cache/ccache
> >
> >
> > f2d169d8-20d2-41d4-8e43-8a9fc5a2b509#
> > cat /usr/local/etc/poudriere.d/make.conf WITH_CCACHE_BUILD=yes
> > USE_LOCAL_MK=yes
> >
> > f2d169d8-20d2-41d4-8e43-8a9fc5a2b509# poudriere bulk -f
> > ~/portlist-current-php53-mysql55 -j 90amd64 >> Mounting system
> > devices for 90amd64 /etc/resolv.conf
> > -> /usr/local/poudriere/jails/90amd64/etc/resolv.conf >>
> > Starting jail 90amd64 >> Mounting ports filesystems for 90amd64
> > >> Mounting ccache from /data/cache/ccache
> > mount: /usr/local/poudriere/jails/90amd64/usr/ports/distfiles: No
> > such file or directory >> Umounting file systems
> > Failed to mount the distfile directory
> > You have new mail.
> >
> >
> > f2d169d8-20d2-41d4-8e43-8a9fc5a2b509# zfs list
> > NAME   USED  AVAIL  REFER  MOUNTPOINT
> > datapool  1.51G  47.5G32K  /datapool
> > datapool/poudriere1.51G  47.5G
> > 33K  /datapool/poudriere datapool/poudriere/data 36K
> > 47.5G36K  /usr/local/poudriere/data
> > datapool/poudriere/jails  1017M  47.5G
> > 31K  /datapool/poudriere/jails 

Where to ask questions about poudriere?

[Rainer Duffner]

Hi,

I'm trying to get poudriere working with the following settings:

f2d169d8-20d2-41d4-8e43-8a9fc5a2b509# cat /usr/local/etc/poudriere.conf
|grep -v ^# |grep -v ^$ ZPOOL=datapool
FTPHOST=ftp.ch.freebsd.org
FREEBSD_HOST=http://ftp.ch.freebsd.org/
RESOLV_CONF=/etc/resolv.conf
BASEFS=/usr/local/poudriere
USE_PORTLINT=no
USE_TMPFS=yes
DISTFILES_CACHE=/usr/ports/distfiles
CSUP_HOST=localhost
CHECK_CHANGED_OPTIONS=yes
PKG_REPO_SIGNING_KEY=/etc/ssl/keys/repo.bla.ch.key
CCACHE_DIR=/data/cache/ccache


f2d169d8-20d2-41d4-8e43-8a9fc5a2b509#
cat /usr/local/etc/poudriere.d/make.conf WITH_CCACHE_BUILD=yes
USE_LOCAL_MK=yes

f2d169d8-20d2-41d4-8e43-8a9fc5a2b509# poudriere bulk -f
~/portlist-current-php53-mysql55 -j 90amd64 >> Mounting system
devices for 90amd64 /etc/resolv.conf
-> /usr/local/poudriere/jails/90amd64/etc/resolv.conf >> Starting
jail 90amd64 >> Mounting ports filesystems for 90amd64
>> Mounting ccache from /data/cache/ccache
mount: /usr/local/poudriere/jails/90amd64/usr/ports/distfiles: No such
file or directory >> Umounting file systems
Failed to mount the distfile directory
You have new mail.


f2d169d8-20d2-41d4-8e43-8a9fc5a2b509# zfs list
NAME   USED  AVAIL  REFER  MOUNTPOINT
datapool  1.51G  47.5G32K  /datapool
datapool/poudriere1.51G  47.5G
33K  /datapool/poudriere datapool/poudriere/data 36K
47.5G36K  /usr/local/poudriere/data
datapool/poudriere/jails  1017M  47.5G
31K  /datapool/poudriere/jails datapool/poudriere/jails/90amd64  1017M
47.5G  1017M  /usr/local/poudriere/jails/90amd64
datapool/poudriere/ports   534M  47.5G
31K  /datapool/poudriere/ports datapool/poudriere/ports/current   534M
47.5G 534M  /usr/local/poudriere/ports/current


What is the problem?



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

Re: FreeBSD 10 prognostication...

[Rainer Duffner]

Am Mon, 21 May 2012 13:47:39 -0500
schrieb Jamie :

> On Mon, May 21, 2012 at 10:57:33AM +0200, Dag-Erling Sm??rgrav wrote:
> > No, they're not.  VMWare, RHEV (KVM-based) etc. provide features
> > such as seamless migration of virtual machines from one physical
> > machine to another, automatic restart on a different physical
> > server if one fails etc. that simply aren't possible with jails;
> > and there are certain things you still can't run reliably / safely
> > in jails - anything that relies on SysV IPC, for instance, such as
> > PostgreSQL.
> 
> True about the SysV, and I mostly agree about automatic failover.
> 
> But I think the FreeBSD jail system is still the better model for how
> I see these things being used (certainly the better *potential*). But
> yea, not "quite" cloud.
> 
> When coupled with something like rsync, they *almost* do the job. And
> for a lot of the current "VPS" applications, they do the job. 


Yeah, but the VPS-systems (OpenVZ, Virtuozzo) do the job, too.
And for those who want the VPS-model without actually running Linux,
there's Joyent's Cloud (public/private) - that can run KVM, too.
AFAIK, KVM being slow means you don't have enough I/O.


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

Re: Using TMPFS for /tmp and /var/run?

[Rainer Duffner]

Am Sun, 1 Apr 2012 09:40:25 -0400
schrieb Gary Palmer :

> Other than catching software that mistakenly assumes /tmp
> and/or /var/run is persistent, what are the CLEAR advantages for
> changing the default?


It's my understanding it improves performance in cases where lots of
files are created and deleted in /tmp (and/or /var/tmp - sometimes
software hard-codes these locations...).

Out of my head, things like spamassassin and amavis/clamav come to mind.
Maybe the pkg-message of these packages should be adjusted so that this
is mentioned?

OTOH, on new installs, a TMPFS could be used automatically if memory >=
4GB.




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

Re: CVS removal from the base

[Rainer Duffner]

Am 05.12.2011 um 00:36 schrieb Randy Bush:

>> This seems too reasonable a suggestion, but, as always, the devil
>> is in the details. There will be long. painful discussions (and
>> arguments) about what to remove from the base to the new structure
>> and what things currently NOT in the base should be promoted.
> 
> as one with a long list of WITHOUT_foo=YES in /etc/src.conf, this is
> tempting.  but, as you hint, is this not just doubling the number of
> borders over which we can argue?
> 
> but let's get concrete here.
> 
> i suspect that my install pattern is similar to others

[]

> and then do whatever is special for this particular system.
> 
> anything which would lessen/simplify the above would be much
> appreciated.  anything not totally obiously wonderful which would
> increase/complicate the above would not be appreciated.



Most of that stuff should be solved by a configuration-management system - or 
(partly) by an automated installation.

BTW: Does anybody have a link to some documentation how that (PXE-install etc.) 
is supposed to be done in 9.0?

Personally, I don't think cvs should be removed any time soon:

 - it's AFAIK stable, doesn't change a lot
 - doesn't introduce vulnerabilities every other month
 - will be needed for some time for historic reasons

BIND OTOH is something different. But even on the couple of servers we actually 
use BIND, we like to have a version that is supported over the lifetime of the 
FreeBSD system it's installed on.

As has been said, FreeBSD (as of 8.2 - haven't had the chance to look into 9.0 
a lot) is a nice system with a lot of functionality without installing lot's of 
packages.

Just FYI: we use rubygem-chef for configuration-management, but we don't think 
it would be a good idea to have ruby in the base-system, even though we need it 
on every system anyway...



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

Re: FreeBSD 9.0

[Rainer Duffner]

Am Thu, 15 Sep 2011 11:42:06 -0300
schrieb Alisson :

> Somebody know when FreeBSD 9.0 Releng will be available?


Judging from the schedule, it's at least a month late. If not two.
Unsurprisingly, to me at least. 

Personally, I don't care. I don't plan with "future" releases
anyway, only with the ones available.

I assume, one can work reasonably well even with the BETA2 currently
out.



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

Re: kernel fails to build on current (mga_g400_emit_tex0)

[Rainer Duffner]

Kris Kennaway wrote:
On Fri, Aug 22, 2003 at 11:57:23PM +0200, Rainer Duffner wrote:

Hi,

this is the output of
make buildkernel


Usually you need to post your kernel config file when reporting
errors, so that others can try to reproduce the problem. 
Yes, but the kernel config worked before I cvsuped. So I thought it must 
be something else.

However in
this case the problem has been widely reported, and the solution is to
define WERROR= (i.e. to the null string) to make compiler warnings
non-fatal.
OK - I think I even hit one of your postings regarding this issue, but I 
admit I couldn't make sense of it.
(I was reading it like one had to have WERROR enabled, which I had...)

It works now again, thanks a lot.



cheers,
Rainer
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

kernel fails to build on current (mga_g400_emit_tex0)

[Rainer Duffner]

Hi,

this is the output of
make buildkernel
cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
-Wcast-qual  -fformat-extensions -std=c99 -g -nostdinc -I-  -I. 
-I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica 
-I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath 
-I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h 
-fno-common -finline-limit=15000 -fno-strict-aliasing 
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding 
-Werror  /usr/src/sys/dev/drm/mga_state.c
/usr/src/sys/dev/drm/mga_state.c: In function `mga_g400_emit_state':
/usr/src/sys/dev/drm/mga_state.c:278: warning: inlining failed in call 
to `mga_g400_emit_pipe'
/usr/src/sys/dev/drm/mga_state.c:387: warning: called from here
/usr/src/sys/dev/drm/mga_state.c:163: warning: inlining failed in call 
to `mga_g400_emit_tex0'
/usr/src/sys/dev/drm/mga_state.c:397: warning: called from here
*** Error code 1

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


I've never seen anybody post a solution, just one or two people with the 
same problem.



cheers,
Rainer
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"