Re: Horrible installer
On Tue, Jan 24, 2012 at 7:42 AM, Stas Verberkt lego...@legolasweb.nlwrote: On Mon, Jan 23, 2012 at 11:24:20PM +0100, claudiu vasadi wrote: From my point of view, I would like to see 2 major things in bsdinstall: 1) ZFS support 2) an option, to use GUI or text mode installer (similar to RHEL, CentOS, Solaris) 3) GELI disk encryption Ah ... that too. -- Best regards, Claudiu Vasadi ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: portmaster best practices
Volodymyr Kostyrko wrote: If portaudit shows that some installed packages have vulnerabilities, what do you usually do? Greatly depend on where am I. All my systems are staying up-to-date whereas when I'm visiting someones system I prefer to update only required pieces of software. Anyway if you tell portmaster to update port x it would try to update all ports it depends on. Does it often screw things up when updating dependencies (both ascending and descending ones)? Do you recommend to always update the ascending dependencies (portmaster -r) also? [dd] The better way of debugging such problems for me is pkg_libchk from sysutils/bsdadminscripts. I use sysutils/libchk when I have to, but it is a tedious manual job I would like to avoid. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: portmaster best practices
Roland Smith wrote: If portaudit shows that some installed packages have vulnerabilities, what do you usually do? It depends on the vulnerability and what the package does. I will de-install it if I think that the vulnerability is critical for me and there is no workaround. Look at freshports [http://www.freshports.org/commits.php] regularly to see if updates for vulnerable packages are available. This is pretty obvious and I run portsnap from cron. Generally I like to run 'portsnap fetch update' followed by 'portmaster -ai' (after reading /usr/ports/UPDATING) every week. This keeps the number of huge compilefests (like gettext updates :-() to a minimum. Has portmaster ever screwed things up for you? For efficiency, I tend to keep one machine up-to-date in that way, and use rsync to then distribute the changes in /usr/local to my other machines. This only works for machines that are on the same major FreeBSD version and architecture, of course. That's interesting. Do you also rsync /var/db/pkg ? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:suda...@sibptus.tomsk.ru ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: portmaster best practices
Victor Sudakov wrote: If portaudit shows that some installed packages have vulnerabilities, what do you usually do? Greatly depend on where am I. All my systems are staying up-to-date whereas when I'm visiting someones system I prefer to update only required pieces of software. Anyway if you tell portmaster to update port x it would try to update all ports it depends on. Does it often screw things up when updating dependencies (both ascending and descending ones)? Do you recommend to always update the ascending dependencies (portmaster -r) also? I never faced any problems updating ports with portmaster. Mostly because portmaster always backups old libraries to compat folder for me as stated in my configuration file: /usr/local/etc/portmaster.rc: NO_BACKUP=Bopt PM_VERBOSE=vopt SAVE_SHARED=wopt DONT_SCRUB_DISTFILES=Dopt NO_BACKUP means don't create a temporary package when deleting something. This is unsuitable for me as /usr/ports in my network is distributed via NFS ro. PM_VERBOSE increases detail level. SAVE_SHARED is a must, it tells portmaster to propagate deleted shared libraries to compat directory. This way updating any port to newer lib version will have no impact on ports requiring previous versions. DONT_SCRUB_DISTFILES also is redundant for me as /usr/ports is read only and I don't want to drop sources of python 2.5 when building python 2.7 as python2.5 is still needed for AppEngine for example. Personally I never use -r as anything that can be fixed with that one can be fixed with pkg_libchk and careful planning. The better way of debugging such problems for me is pkg_libchk from sysutils/bsdadminscripts. I use sysutils/libchk when I have to, but it is a tedious manual job I would like to avoid. They are almost the same except pkg_libchk doesn't depend on ruby and works in parallel better (for me). -- Sphinx of black quartz judge my vow. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Applying local patches after updating FreeBSD source
On Mon, Jan 23, 2012 at 2:13 PM, Maxim Khitrov m...@mxcrypt.com wrote: On Mon, Jan 23, 2012 at 1:25 PM, Matthew Seaman m.sea...@infracaninophile.co.uk wrote: On 23/01/2012 18:03, Maxim Khitrov wrote: Hi all, When I need to apply a custom patch to a port, I can set EXTRA_PATCHES make variable in /usr/local/etc/ports.conf (when using portconf), and the patch will be automatically applied whenever that port is built. Is there equivalent functionality for building FreeBSD world and kernel? When I run 'make update' in /usr/src, csup overwrites all local changes. There is a LOCAL_PATCHES variable, but it seems to apply only to 'make release'. If possible, I would like to avoid writing custom scripts for updating and building world, because at some point I will forget to use the script and build everything without the patches. How can I preserve the current behavior of running 'make update make buildworld buildkernel' while automatically applying custom patches in between? Check the system sources out of svn? This way, you can apply your patches and the result is automatically merged when you update the sources by 'svn up' -- unless there has been a conflicting commit to the same file, when you may be required to intervene manually. I don't have subversion installed on any of my servers and that's a dependency that I would prefer to do without. Are there any changes I could make to /etc/make.conf that would allow me to execute an arbitrary command after the 'update' task is finished? - Max For anyone else that might be interested in doing this, the solution is to create a shell script that is executed instead of csup when running 'make update'. The script to execute is specified in /etc/make.conf: SUP=/root/bin/csup-src I'm pretty sure that this is safe to do. Just in case, the script checks the current working directory to make sure that patches are only applied when updating /usr/src. You could also perform this check in make.conf. The script template is below. Feel free to adapt it for your own needs. #!/bin/sh /usr/bin/csup $@ || exit test `pwd` = '/usr/obj/usr/src' || exit 0 cd /usr/src echo '--' echo ' Applying local patches' echo '--' # your code here - Max ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
FW: Makeopts DEBUG=-g kernel option
Hi there I'm experiencing the following problem: All is well when I boot the standard FreeBSD 8.2 GENERIC kernel. The moment however when I comment out the line the line below, the kernel hangs upon boot after detecting the em0 device (the motherboard has 2 Intel 8257x dual Gigabit Ethernet cards). makeopts DEBUG=-g I'm using FreeBSD 8.2 on a WADE-8020 motherboard with an Intel QM57 chipset and Intel Core i5 CPU. The reason I'm trying to remove debugging options from the kernel is that I am trying to make the kernel footprint smaller. This leaves me with a few questions: 1) What are the risks/drawbacks/advantages of leaving debugging symbols in the kernel? 2) Why would debug symbols (of all things!) make the difference between a working and non-working kernel? 3) Does this point in the direction of some other (more serious problem perhaps?) with the hardware and/or other kernel drivers? Thanks so much for any assistance. Regards, Dirk Kotze Developer Nanoteq Important Notice: This e-mail and its contents are subject to the Nanoteq (Pty) Ltd e-mail legal notice available at: http://www.nanoteq.com/corp_profile/disclaimer.asp Important Notice: This e-mail and its contents are subject to the Nanoteq (Pty) Ltd e-mail legal notice available at: http://www.nanoteq.com/corp_profile/disclaimer.aspThe message does not contain any threats AVG for MS Exchange Server (10.0.1416 - 2109/4756)___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: lang/lua fails to build on 9.0-STABLE amd64 - bug or config issue?
On 24 January 2012 02:12, Christer Solskogen
christer.solsko...@gmail.com wrote:
On Tue, Jan 24, 2012 at 12:22 AM, Lee Thomas lthomas_li...@lthomas.net
wrote:
Hello fellow FreeBSD users,
I ran across an odd issue compiling lua from ports on amd64 with FreeBSD
9.0-STABLE, and I'm not sure whether it's a bug or incorrect configuration
on my part. The lang/lua port throws a linker error, claiming to need -fPIC,
which is odd because the port Makefile seems to have logic to add that in,
but somehow the logic seems not to have any effect, at least in my case.
Making the port Makefile put ${CFLAGS} directly into lua's Makefile (patch
at the end of this mail) fixes matters for me, but I don't understand the
port infrastructure well enough to understand whether this patch represents
a bugfix or a workaround of some local configuration issue. Has anyone run
into this issue before? If this is a config issue, any hints on what might
be going on or how to dope it out?
I think I had the same problem about a moth ago. The problem was my
CFLAGS in make.conf.
You probably have CFLAGS=something, try setting it to CFLAGS?=something.
We note above that:
CFLAGS= -O2 -fno-strict-aliasing -pipe
since that tends to be the default anyway (see
/usr/share/mk/sys.mk ), you're generally better off
leaving it out entirely.
--
--
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: NetGear WG511T and WPA support on FreeBSD 8.2
Bought the card in the meantime and got done testing it. Works just fine. The card is specifically listed on: man 4 ath_hal Saw this later as I only checked man 4 ath... Thanks for the update though. On Thu, Jan 19, 2012 at 3:02 PM, Hans Ottevanger h...@beastielabs.netwrote: On 01/13/12 22:17, _ wrote: Hi, Since I've run into problems getting an ndisgen generated driver for my Realtek RTL8185 54M to work on my FreeBSD 8.2 (i386) system - kldload on the driver generates a permanent kernel crash-, I am currently thinking about buying the NetGear WG511T PCMCIA bus driven card. I would like to ask if there are any users on this list that make use of this card and that can confirm whether or not this cards works fine alongside with WPA/WPA2 on 8.2 or 9.0 if I decide to upgrade? I am aware of the supported hardware list. The card in discussion is not listed as supported. However, this could still be the case, since I read in an older 7.0 related thread http://www.daemonforums.org/**showthread.php?t=1424http://www.daemonforums.org/showthread.php?t=1424that it did work, at least at one point in time. Thanks Hi, Maybe a bit late to react, but I have been traveling lately ... I have two WPA511T adapters (slightly different from the WG511T you refer to). I used them intensively for years in a pair of antique Toshiba laptops and they have actually always worked (since 6.x, I believe) without any issues and they still do with a recent 8.2-STABLE. I use wpa_supplicant, mostly with WPA2. It is recognized as follows: ath0: Atheros 5212 mem 0x8800-0x8800 irq 10 at device 0.0 on cardbus1 ath0: [ITHREAD] ath0: AR2413 mac 7.9 RF2413 phy 4.5 Of course there could still be PCMCIA issues on a different laptop, but since the WG511T also has an Atheros 5212 chipset and Atheros chipsets for 802.11g have excellent support in FreeBSD, I would expect it to work, even with a GENERIC kernel. Kind regards, Hans Ottevanger ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
FreeBSD 9 and 3G Modems
I am Google-ing for a recent definitive HOWTO use my 3G modem with FreeBSD/PC-BSD and what I get seem rather old. Someone can point me to a recent document detailing the steps. I have PC-BSD 9 on my laptop. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ I can't hear you -- I'm using the scrambler. Please consider the environment before printing this email. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD 9 and 3G Modems
On 1/24/2012 10:56 AM, Odhiambo Washington wrote: I am Google-ing for a recent definitive HOWTO use my 3G modem with FreeBSD/PC-BSD and what I get seem rather old. Someone can point me to a recent document detailing the steps. I have PC-BSD 9 on my laptop. Most of them just come up as cuaU* devices, but not all. The method to use them has not really changed, so chances are what you have found via google will still work. Take a look at the relevant man pages. man u3g What type of modem do you have ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Applying local patches after updating FreeBSD source
On Mon, 23 Jan 2012 14:13:49 -0500
Maxim Khitrov m...@mxcrypt.com wrote:
On Mon, Jan 23, 2012 at 1:25 PM, Matthew Seaman
m.sea...@infracaninophile.co.uk wrote:
On 23/01/2012 18:03, Maxim Khitrov wrote:
Hi all,
When I need to apply a custom patch to a port, I can set
EXTRA_PATCHES make variable in /usr/local/etc/ports.conf (when
using portconf), and the patch will be automatically applied
whenever that port is built. Is there equivalent functionality for
building FreeBSD world and kernel?
When I run 'make update' in /usr/src, csup overwrites all local
changes. There is a LOCAL_PATCHES variable, but it seems to apply
only to 'make release'.
If possible, I would like to avoid writing custom scripts for
updating and building world, because at some point I will forget
to use the script and build everything without the patches. How
can I preserve the current behavior of running 'make update
make buildworld buildkernel' while automatically applying custom
patches in between?
Check the system sources out of svn?
This way, you can apply your patches and the result is automatically
merged when you update the sources by 'svn up' -- unless there has
been a conflicting commit to the same file, when you may be
required to intervene manually.
I don't have subversion installed on any of my servers and that's a
dependency that I would prefer to do without.
Are there any changes I could make to /etc/make.conf that would allow
me to execute an arbitrary command after the 'update' task is
finished?
My own preferred methodology that I've been using for quite some time
now is to use csup to update a local copy of the doc, ports and src
areas of the official CVS repository, from which I can then
update /usr/{doc,ports,src} via local CVS. This basically has the
same perks as what Matthew described for subversion.
In my case, I mainly want the flexibility to tinker with ports and not
have all of my customizations and patches I'm working on for later
submission overwritten with every update. Doing cvs updates will merge
my local changes with whatever updates come in from the official repo.
Only very rarely will some conflict arise, but as long as you keep
an eye on your mail from your cron jobs, it's very easy to spot them
and fix them.
Having the local CVS repo is especially nice for creating very
clean, conforming patches for ports, ready to submit via send-pr, with
no worries about any little oddities in the pathnames used to diff the
files, since you're diffing against a clone of the actual FreeBSD CVS
repo.
Of course, everyone has their own tastes when it comes to this sort of
thing. I've just been doing it this way for so long now, I'm reluctant
to try anything else. Gettin' set in mah ways, I reckon. :-)
--
Conrad J. Sabatier
conr...@cox.net
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Question about block size
Hello Everyone, I seem to remember a thread which I can't find now which discussed the long time it takes to make freebsd-snapshots on large disks. I also seem to remember that one suggestion was to use larger block size. I have a pair of 2 TB hard drives assembled in a gmirror, which is to be added to an existing server. There will be 3 partitions about the same sizes on the 2 TB mirror. What block size should I use if I'd like to use freebsd-snapshots? -- Janos Dohanics ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: portmaster best practices
On Tue, Jan 24, 2012 at 03:49:05PM +0700, Victor Sudakov wrote: Generally I like to run 'portsnap fetch update' followed by 'portmaster -ai' (after reading /usr/ports/UPDATING) every week. This keeps the number of huge compilefests (like gettext updates :-() to a minimum. Has portmaster ever screwed things up for you? Not really. There have been occasions where some build fails and I have to re-start it. But that is hardly portmaster's fault. The biggest problem is that I have TeXLive installed instead of teTeX. So I have to patch the tex-related ports that I use after using portsnap but before using portmaster. For efficiency, I tend to keep one machine up-to-date in that way, and use rsync to then distribute the changes in /usr/local to my other machines. This only works for machines that are on the same major FreeBSD version and architecture, of course. That's interesting. Do you also rsync /var/db/pkg ? In the beginning I did, but I found that I didn't do much upgrading/installing on my other machines anyway, so I actually removed /var/db/[pkg|ports] on the other machines. And /usr/ports too. The other thing to sync are of course the configuration files because they tend to differ significantly from machine to machine. I keep git repositories for the config files of all my machines (and jails) on my main desktop (every machine its won repo), and use rsync to distribute them to the machine in question where they are installed locally using ssh. E.g, after the update from 8.2 to 9.0, once the main desktop was done, it was easy to do a 'git diff'on it's config files and see which changes needed to be applied to other machines as well. I do this manually since the files can be very different from machine to machine. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpM8xvVqQC1V.pgp Description: PGP signature
Re: zpool detach pool device
All DBAN does is write {whatever-source-you-choose} to the drive
basically with dd (it's actually a separate wrapper program but it
behaves identically to dd).
Just use dd and avoid the hassle of downloading and burning a cd that does
dd. dban is nice if you have to do a garage full of machines or are a
Windows victim but if you know your way around UNIX why bother with dban?
I recently had some drives fail and I did dd from /dev/urandom
4) If you ever plan on re-using this drive in a system, please do not
use the PRNG method or similar methods (write random jibberish all over
the drive). This is almost guaranteed to confuse a system (ANY system)
the next time you insert the disk; data is written to the MBR and
partition table regions which is gobbledegook, resulting in the
underlying BIOS, OS, or anything else trying to parse that data, and
thus begins behaving weirdly/oddly (what do you mean I can't partition
this disk? Yeah, there's an HP/UX partition on this thing,
right...). I speak from personal experience on this matter. As such,
I always advocate people zero their drives and not to pick the defaults.
Interesting. I have never had this happen but I always partition the drives
or label them before trying to do anything after a spring cleaning.
If this is your only objection to nonzero values it still is a good
compromise to dd the whole drive with /dev/urandom and then just blast the
MBR from /dev/zero its only 512 bytes.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
