Re: Desired behaviour of "ifconfig -alias"
Kevin Way wrote: > Oliver Fromme wrote: > > But you called it "confusing". That's just your personal > > perception. It doesn't mean it is confusing to everybody. > > > If asked what -alias does, would you really reply "it removes the > primary IP, > while leaving the alias?" Be honest here. No, I wouldn't answer that, because there is no such thing as a primary IP. All IPs on an interface are equal. The term alias exists only for historical reasons, and it's clearly becoming obsolete. If asked what "-alias" does, I would reply that it is an alias for "delete" or "remove", which removes an IP address from an interface. According to the docs, the IP address to be removed must be specified. The docs don't mention what happens if none is specified, so the behaviour is undefined and should not be relied on. It just happens that the behaviour is to remove an arbitrary IP address (which happens to be the first one). That behaviour should be documented in the manual page. > > Also note that it doesn't hurt anybody. > > If you run RELENG_6_2, and a jail fails to start, this command is called. > And instead of unaliasing the jail's alias, it (because of a bug in the > shipped > rc.d scripts), it removes the primary IP. That's clearly a bug in the scripts then. They shouldn't call a command that can cause undefined behaviour. I'm not against changing the behaviour for the -alias parameter, if it's done carefully and in -current first, as I wrote earlier. However, the behaviour for "delete" and "remove" should stay as-is (and be documented in the man page) because it makes sense. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart Any opinions expressed in this message are personal to the author and may not necessarily reflect the opinions of secnetix GmbH & Co KG in any way. FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "Documentation is like sex; when it's good, it's very, very good, and when it's bad, it's better than nothing." -- Dick Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
On Monday 12 February 2007 22:37, Joerg Pernfuss wrote:
> On Mon, 12 Feb 2007 19:18:54 -0300
>
> JoaoBR <[EMAIL PROTECTED]> wrote:
> > I believe the problem here is that
> >
> > ifconfig_nic="inet IP"
> > ifconfig_nic="ether MAC"
> >
> > does not work on one line and does not work on two either, the latter
> > overrides and or you get an IP address with original MAC or you get a
> > new MAC without IP.
>
> Yes, you have to put 'ifconfig nic ether MAC' in /etc/start_if.nic
> for this to work afair. Same approach you need to set WEP etc on a
> wireless nic if you have ifconfig_nic="DHCP" in your rc.conf.
>
> Joerg
if I am remembering well dhcp things you can put into dhclient.conf as
interface "nic" {
media "ssid SSID nwkey KEY";
}
or so to be set before sending the dhcp request.
but this is different but ok and is not related to the -alias thing.
--
João
A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of 'ifconfig -alias' [ath and ifconfig parameter order]
On Mon, February 12, 2007 8:01 pm, Sam Leffler wrote: > Freddie Cash wrote: >> On Monday 12 February 2007 11:06 am, John Hay wrote: >>> Also with the atheros driver I had problems in the past with some >>> parameters that did not like to be on a single commandline. >> >> At least with the ath(4) driver, it all comes down to the order the >> options are written on the commandline. Some options reset the >> device, wiping out previous options, so you have to make sure those >> are set first. Took me awhile to figure that out, but it is >> mentioned in the man page. > > So can someone actually provide an example? I'm not aware of any > interactions within the os. There might be some corner cases in > ifconfig due to the way it processes cmdn line parameters. I remember back in the 5.3 days when I first got my Toshiba laptop with an Atheros SuperG chipset onboard and was trying to get WEP connection working, I had to specify the channel as the first option on the ifconfig line. Putting it anywhere else, especially after the wepmode and wepkey options would cause the link to fail -- and none of the wep options would be set, just the channel. Using the exact same options, but in a different order, would work. Since switching to WPA, though, and configuring everything via wpa_supplicant.conf, I haven't had any issues with this. In fact, I don't use ifconfig at all anymore. A simple ifconfig_ath0="WPA DHCP" is all I ever need ... along with a nice long wpa_supplicant.conf with an entry for each of the wireless network I connect to. (The FreeBSD method of using WPA is soo much nicer than the Debian way.) I'll play around with my laptop this week and see if I can reproduce this on 6.2. Freddie Cash [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias" [ath and ifconfig parameter order]
Freddie Cash wrote: > On Monday 12 February 2007 11:06 am, John Hay wrote: >> Also with the atheros driver I had problems in the past with some >> parameters that did not like to be on a single commandline. > > At least with the ath(4) driver, it all comes down to the order the > options are written on the commandline. Some options reset the device, > wiping out previous options, so you have to make sure those are set > first. Took me awhile to figure that out, but it is mentioned in the man > page. So can someone actually provide an example? I'm not aware of any interactions within the os. There might be some corner cases in ifconfig due to the way it processes cmdn line parameters. Sam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
On Tue, Feb 13, 2007 at 02:37:53AM +0100, Joerg Pernfuss wrote: > On Mon, 12 Feb 2007 19:18:54 -0300 > JoaoBR <[EMAIL PROTECTED]> wrote: > > > I believe the problem here is that > > > > ifconfig_nic="inet IP" > > ifconfig_nic="ether MAC" > > > > does not work on one line and does not work on two either, the latter > > overrides and or you get an IP address with original MAC or you get a > > new MAC without IP. > > Yes, you have to put 'ifconfig nic ether MAC' in /etc/start_if.nic > for this to work afair. Same approach you need to set WEP etc on a > wireless nic if you have ifconfig_nic="DHCP" in your rc.conf. The second is no longer true. DHCP (like WPA) is a magic keywork that tells the system to run DHCP on the interface and is not passwd to ifconfig so the line can contain other things. -- Brooks pgp0uewPFgzQe.pgp Description: PGP signature
Re: Desired behaviour of "ifconfig -alias"
On Mon, 12 Feb 2007 19:18:54 -0300 JoaoBR <[EMAIL PROTECTED]> wrote: > I believe the problem here is that > > ifconfig_nic="inet IP" > ifconfig_nic="ether MAC" > > does not work on one line and does not work on two either, the latter > overrides and or you get an IP address with original MAC or you get a > new MAC without IP. Yes, you have to put 'ifconfig nic ether MAC' in /etc/start_if.nic for this to work afair. Same approach you need to set WEP etc on a wireless nic if you have ifconfig_nic="DHCP" in your rc.conf. Joerg -- | SPECIAL ADVERTISMENT |NEW KEY AS OF 02/01/2007 - GET IT | +--+--+ | /"\ ASCII ribbon | GnuPG Key ID | 6902 3fc0 64c3 a56e a8b4 | | \ / campaign against |0xab439348 | c8de d555 c2cd ab43 9348 | | XHTML in email |.the next sentence is true. | | / \ and news | .the previous sentence was a lie.| ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
Oliver Fromme wrote: > But you called it "confusing". That's just your personal > perception. It doesn't mean it is confusing to everybody. > If asked what -alias does, would you really reply "it removes the primary IP, while leaving the alias?" Be honest here. > Also note that it doesn't hurt anybody. If you run RELENG_6_2, and a jail fails to start, this command is called. And instead of unaliasing the jail's alias, it (because of a bug in the shipped rc.d scripts), it removes the primary IP. So that is a real life, non-third-party incident, where a machine was knocked off-line unexpectedly, because of this behavior. Sure, it didn't *hurt* me, but knocking a machine off-line is a pretty serious side effect, especially when it isn't documented. Errors in the other direction are more likely to result in a machine remaining reachable. Fortunately, it appears that a fairly strong consensus is appearing in support of an eventual refinement of this behavior. Best Regards, Kevin Way ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What is a good choice of sata-ii raid controller for freebsd?
On Mon, Feb 12, 2007 at 12:11:42PM +0300, Artem Kuchin wrote: > >On 2007-Feb-12 16:07:03 +1030, Daniel O'Connor <[EMAIL PROTECTED]> > >wrote: > >>I regularly ship systems overseas where the power fails frequently. The > >>inability to boot because one disk got hosed is Bad News (tm). > > >A decent UPS can help here. > > No, i can't. I have seen UPS (even APC) fail in some cases. Computers > got frozen. Also, i've seen many cases when power failes for more than 4 > hours > and nobody want to buy UPS which hold 4 hours of power for a dual xeon > with 5 hdds. > sysutils/nut is a good work-around for this. --Geoff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
Oliver Fromme wrote: In the case of adding something, what should be added if nothing is specified? Should the tool invent an arbitrary IP address and add it? Now that would be nonsensical. But when removing something without specifying which one, it makes some sense to simply remove the first existing address on that interface. It would even be OK with me to remove the last one, or an arbitrary one -- I use that shortcut mostely when I need to remove the only address from an interface (or all existing addresses), so it doesn't matter. Doing apparently random and arbitrary things is bad, regardless. To re-cast the argument, suppose you found out that your employer had a command in the company accounting system called "VacationConfig -transfer" that would transfer random days from your vacation pot to some arbitrary receiver. .. It is very clear that ifconfig does not behave in the manner that the man pages claim. Part of that appears to be simple bit-rot, part of it appears to be an issue as to what it should do. I suggest that everyone toss there ideas over to -current/hackers and forge a consensus to what ifconfig should do, and willing volunteers go off and mung the code & docs until it's that way in -current. Then MFC it back to -stable... John -- John T. Farmer Owner & CTO GoldSword Systems [EMAIL PROTECTED] 865-691-6498 Knoxville TN Consulting, Design, & Development of Networks & Software ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: install on usb hdd
On Mon, 12 Feb 2007 16:39:16 +0100 Jost Menke <[EMAIL PROTECTED]> wrote: > first of all, I think installation won't be possible with the > menu-driven installer (sysinstall), so you'll have to do this > manually (i.e. by using the install.sh scripts on the CD and creating > rc.conf fstab and the like by hand). FWIW, *if* the disk is seen by the bios, sysinstall works just fine. I have two 2.5 inch hard drives here (in usb enclosures) that I have installed that way. -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
Brooks Davis wrote:
> Oliver Fromme wrote:
> > True, not often, but sometimes. I had cases like that in
> > certain environments with bridged networks and arp proxies.
> >
> > I'm fine with your proposed syntax, as long as all the
> > existing ifconfig possibilities continue to be possible,
> > i.e. no regression.
>
> FWIW, it's HEAD and 6.1. We've actually got the aliases syntax labled
> as deprecated in the manpage.
Interesting, I wasn't aware of that. I'll update my
rc.conf where possible.
> We might want to add a feature to set the
> broadcast address.
Yes.
> > Yup, I agree, that's a PITA. That could be solved in the
> > shell code, though, by not enumerating until a number
> > doesn't exist, but instead looking at the set of all
> > shell variables that have been set, similar to this:
> >
> > set | grep "^ifconfig_${IFACE}_alias" | cut -f1 -d= | ...
>
> Unfortuanly grep in in /usr/bin so can't be used.
Well, ed is in /bin and can be used as a replacement for
grep; the syntax is just a little more awkward.
Or use the common IFS trick:
OLD_IFS="$IFS"
IFS="="
set | while read VAR VALUE; do
case "$VAR" in
ifconfig_${IFACE}_alias*)
...
;;
esac
done
IFS="$OLD_IFS"
> { while read _var; do
> _var=${_var%%=*}
> case $_var in
> ifconfig_${IFACE}_alias*)
> <...>
> ;;
> esac
> done } < `set`
Yup, that would work, too, except that you have to write
"set | while read _var; do ...". The "< `set`" will not
work.
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, USt-Id: DE204219783
Any opinions expressed in this message are personal to the author and may
not necessarily reflect the opinions of secnetix GmbH & Co KG in any way.
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
"When your hammer is C++, everything begins to look like a thumb."
-- Steve Haflich, in comp.lang.c++
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Dell 1955 Blade - Broadcom NIC not detected (BCM5708S)
Hi ! We tested the latest version (1.2.2.12) of the driver on Friday (Feb 9, 2007), but could not get the interfaces up. Has anybody managed to get the network interfaces up and running with this latest version of the driver? http://people.freebsd.org/~dwhite/patches/bce-serdes-20070111.tar.gz These should apply cleanly to RELENG_6. -- Med vennlig hilsen / Regards; Roar Pettersen Universitetet i Bergen - The University of Bergen Nygardsgt. 5 - N-5020 BERGEN - Norway Tlf: +47 55 58 40 55 fax: +47 55 58 40 70 [EMAIL PROTECTED] - IT-Avd, UiB - http://www.uib.no ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
On Monday 12 February 2007 16:27, Brooks Davis wrote: > Setting media options and the like via _aliasesX variables makes no > sense and you don't appear to be doing it so I'm confused by your > question. The ifconfig_iface_aliasX syntax exists to add IPv4 addresses > to an interface. New ipv4_addrs_iface variable is an attempt to replace > that and nothing more. I believe the problem here is that ifconfig_nic="inet IP" ifconfig_nic="ether MAC" does not work on one line and does not work on two either, the latter overrides and or you get an IP address with original MAC or you get a new MAC without IP. -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Dell 1955 Blade - Broadcom NIC not detected (BCM5708S)
We tested the latest version (1.2.2.12) of the driver on Friday (Feb 9, 2007), but could not get the interfaces up. Has anybody managed to get the network interfaces up and running with this latest version of the driver? Thanks, Pentti -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.441 / Virus Database: 268.17.33/678 - Release Date: 09/02/2007 4:06 PM ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
On Monday 12 February 2007 16:09, Oliver Fromme wrote: > > > > it is not misleading and it is a perfect term. With alias you add > > secondary addresses to an interface. Like secondary is probably the > > better word, > > No, not at all. As soon as you use the terms "primary IP > address" and "secondary IP addresses", you imply that they > are not equal. But they are equal. It's just a list of > IP addresses assigned to an interface which happens to have > a certain order. > nobody claims that there is an master-slave order or something, alias is the secondary in order of time, but not in value, I do not even understand why you talking so much about this, the point is more than clear > > Yes, that's why I wrote it should be changed to not contain > the word "alias" anymore, but simply an enumerated list. > > > > If no IP address is specified, then it's not completely > > > nonsensical to remove the first address. In fact I've > > > used that short-cut to quickly remove the only address > > > from an interface. I've used "ifconfig xyz0 delete" > > > quite a lot. > > yes it is! it does not matter which word, without an IP address it should NOT remove anything > > the man page tells us that -alias removes *the* specified address and > > not the first, also the man page does not say that there is any further > > action when *no* IP address specified > > That's true. Usually if something is not documented, the > behaviour is undefined. > undefined is absolutely not similar to remove something .. > > delete is according to the man page another word for -alias, that means, > > using grammatical logic that -alias is the main command, > > No. It means that "delete" and "remove" are aliases for > "-alias". In reality they're simply equal. ;-) > > > then according to the man > > page there is no other command as "-alias *IP*" to remove an IP address > > and -alias only should not remove anything > > It's not documented that way. As I wrote above. > > If something is not documented, that doesn't mean that it > shouldn't do anything at all. In that case a _lot_ of > things wouldn't work. :-) all commands which remove something "usally" say something when trying to use without value, rm, rmdir, rmuser ... I really do not remember any other then -alias which does so > > you see, now you apply logic because you want to and when not not ... ;) > > > > to let it more clear what I mean, you say: "you don't tell it anything > > to add" so why the heck "ifconfig nic -alias" should remove one if I do > > not tell so? > > In the case of adding something, what should be added if > nothing is specified? Should the tool invent an arbitrary > IP address and add it? Now that would be nonsensical. > > But when removing something without specifying which one, > it makes some sense to simply remove the first existing > address on that interface. It would even be OK with me > to remove the last one, or an arbitrary one -- I use that > shortcut mostely when I need to remove the only address > from an interface (or all existing addresses), so it > doesn't matter. > come on, now your are looking up a way out of this mess ... > In fact, it might also make sense to enhance the syntax > to allow the specification of a number, for example > "ifconfig xyz0 delete #2" would remove the second address my god what a horrible idea is that! do you remember "#" in UNIX the command "ifconfig nic -alias IP" is OK, perfect, even delete is, the problem and the only problem is that both remove without specifying a value a value and that *IS* wrong behaviour, otherwise *you* must agree that rm removes the first file it finds, rmuser the first user and and and, that is wrong, documented or not > However, such a feature will run into problems when the > set of ip addresses is not an ordered list anymore, which > might very well happen in the future. Then there will be > no "first" and "last" anymore, but instead the interface > will just have an unordered set of IP addresses. In fact > I wish that would already be the case, so people saying > "primary" and "secondary" would shut up already. :-) then they come up in random order on each "ifconfig nic" :) ??? -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
On Monday 12 February 2007 11:06 am, John Hay wrote: > On Mon, Feb 12, 2007 at 11:59:40AM -0600, Brooks Davis wrote: > > On Mon, Feb 12, 2007 at 06:39:35PM +0100, Oliver Fromme wrote: > > > Brooks Davis wrote: > > > > Oliver Fromme wrote: > > > > > Jeremy Chadwick wrote: > > > > > > Oliver Fromme wrote: > > > > > > FWIW, I still use alias/-alias. Mainly because that's what > > > > > > has existed historically, and the term "alias" is what is > > > > > > used in reference to rc.conf ifconfig_iface_aliasX entries. > > > > > > > > > > Maybe it would make sense to remove "alias" from the rc.conf > > > > > entries and simply number them. > > > > > > > > ipv4_addrs_ is a much better replacement IMO. It's > > > > easy to use and doesn't required the hackish pseudo array > > > > traversal used by ifconfig_iface_aliasX. > > > > > > That might work for simple cases, but how do you specify > > > other parameters beside the IPs if you need to? > > > > What do you need to set? It's sets IP and netmask. It doesn't > > handle broadcast, but I'd be pretty suprised if that's needed often. > > What else is needed? Axing ifconfig_iface_aliasX is not needed, but > > reducing the visiability of the interface in the documentation is > > probably in order particularly since it's quite fragile since you > > have to renumber whenever you remove an entry. > > Some stuff cannot be done on a single line, so I have abused the > _aliasX mechanism for that. With the bridge interface: > > ifconfig_bridge0="ether 00:00:24:c0:0e:40 addm sis0 stp sis0 addm sis1 > stp sis1 up" ifconfig_bridge0_alias0="inet 146.64.84.1/24" > > Also with the atheros driver I had problems in the past with some > parameters that did not like to be on a single commandline. At least with the ath(4) driver, it all comes down to the order the options are written on the commandline. Some options reset the device, wiping out previous options, so you have to make sure those are set first. Took me awhile to figure that out, but it is mentioned in the man page. Note, however, that your example could be done using the ipv4_addrs_bridge0 variable, as you are not setting anything other than the IP: ifconfig_bridge0="ether 00:00:24:c0:0e:40 addm sis0 stp sis0 addm sis1 stp sis1 up" ipv4_addrs_bridge0="146.64.84.1/24" -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gjournal patch
Václav Haisman wrote: Hi, yesterday, I tried to build kernel and world with the gjournal patch. It does not apply cleanly. This brings me to question, are there some outstanding issues that prevent it from being commited to RELENG_6? I tried to search ml archives but I did not find any. This is slightly OT, but I was looking at the AsiaBSDCon site yesterday and I saw this: http://asiabsdcon.org/timetable.html#P11 "This paper introduces Bluffs, a journaling file system that is mostly compatible with the Fast File System (FFS) on disk structure. The FFS has been successfully used for a long time. However increased disk capacities have made the classic crash recovery using a file system checker (fsck) a prohibitively time expensive operation. Soft Updates [4] and background fsck were introduced to combat the problem but added code complexity to FFS. Bluffs goal is to replace FFS by providing the same functionality as FFS with better error recovery and a fresh simple code structure. Allowing bidirectional migration of file systems between FFS and Bluffs format should make transitioning easier, provides file system checker tools to Bluffs and allows booting with the standard bootstrap loaders." This is the first I've heard of this. It seems to be coming from Yahoo!. Anyone else know anything about this project? Thanks, Charles -- Vaclav Haisman___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
On Mon, Feb 12, 2007 at 09:06:59PM +0200, John Hay wrote: > On Mon, Feb 12, 2007 at 11:59:40AM -0600, Brooks Davis wrote: > > On Mon, Feb 12, 2007 at 06:39:35PM +0100, Oliver Fromme wrote: > > > Brooks Davis wrote: > > > > Oliver Fromme wrote: > > > > > Jeremy Chadwick wrote: > > > > > > Oliver Fromme wrote: > > > > > > FWIW, I still use alias/-alias. Mainly because that's what has > > > > > > existed historically, and the term "alias" is what is used in > > > > > > reference to rc.conf ifconfig_iface_aliasX entries. > > > > > > > > > > Maybe it would make sense to remove "alias" from the rc.conf > > > > > entries and simply number them. > > > > > > > > ipv4_addrs_ is a much better replacement IMO. It's easy to > > > > use and doesn't required the hackish pseudo array traversal used by > > > > ifconfig_iface_aliasX. > > > > > > That might work for simple cases, but how do you specify > > > other parameters beside the IPs if you need to? > > > > What do you need to set? It's sets IP and netmask. It doesn't handle > > broadcast, but I'd be pretty suprised if that's needed often. What else > > is needed? Axing ifconfig_iface_aliasX is not needed, but reducing the > > visiability of the interface in the documentation is probably in order > > particularly since it's quite fragile since you have to renumber whenever > > you remove an entry. > > Some stuff cannot be done on a single line, so I have abused the _aliasX > mechanism for that. With the bridge interface: > > ifconfig_bridge0="ether 00:00:24:c0:0e:40 addm sis0 stp sis0 addm sis1 stp > sis1 up" > ifconfig_bridge0_alias0="inet 146.64.84.1/24" ipv4_addrs_bridge0="146.64.84.1/24" :) > Also with the atheros driver I had problems in the past with some parameters > that did not like to be on a single commandline. I do agree there's some need for a way to pass multiple sets of parameters to ifconfig since this has commonly been a problem. Something actually designed for that might be nice. :) -- Brooks pgpjPsFNS9Bsi.pgp Description: PGP signature
Re: Desired behaviour of "ifconfig -alias"
On Mon, Feb 12, 2007 at 01:27:36PM -0600, Brooks Davis wrote: > On Mon, Feb 12, 2007 at 11:07:39AM -0800, Jeremy Chadwick wrote: > > Does it support media and mediaopt arguments? These are very > > commonly used. I also rely on this, for what it's worth: > > > > openvpn_enable="yes" > > openvpn_configfile="/conf/ME/openvpn/openvpn.conf" > > openvpn_dir="/conf/ME/openvpn" > > openvpn_if="tap" > > cloned_interfaces="bridge0" > > ifconfig_bridge0="addm em1 up" > > Setting media options and the like via _aliasesX variables makes no > sense and you don't appear to be doing it so I'm confused by your > question. The ifconfig_iface_aliasX syntax exists to add IPv4 addresses > to an interface. New ipv4_addrs_iface variable is an attempt to replace > that and nothing more. Ah, now I understand. I was reading it as "ipv4_addrs_ would replace ifconfig_ altogether", which was obviously incorrect on my part. Thanks for clearing up my confusion... :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
On Mon, Feb 12, 2007 at 11:59:40AM -0600, Brooks Davis wrote: > On Mon, Feb 12, 2007 at 06:39:35PM +0100, Oliver Fromme wrote: > > Brooks Davis wrote: > > > Oliver Fromme wrote: > > > > Jeremy Chadwick wrote: > > > > > Oliver Fromme wrote: > > > > > FWIW, I still use alias/-alias. Mainly because that's what has > > > > > existed historically, and the term "alias" is what is used in > > > > > reference to rc.conf ifconfig_iface_aliasX entries. > > > > > > > > Maybe it would make sense to remove "alias" from the rc.conf > > > > entries and simply number them. > > > > > > ipv4_addrs_ is a much better replacement IMO. It's easy to > > > use and doesn't required the hackish pseudo array traversal used by > > > ifconfig_iface_aliasX. > > > > That might work for simple cases, but how do you specify > > other parameters beside the IPs if you need to? > > What do you need to set? It's sets IP and netmask. It doesn't handle > broadcast, but I'd be pretty suprised if that's needed often. What else > is needed? Axing ifconfig_iface_aliasX is not needed, but reducing the > visiability of the interface in the documentation is probably in order > particularly since it's quite fragile since you have to renumber whenever > you remove an entry. Some stuff cannot be done on a single line, so I have abused the _aliasX mechanism for that. With the bridge interface: ifconfig_bridge0="ether 00:00:24:c0:0e:40 addm sis0 stp sis0 addm sis1 stp sis1 up" ifconfig_bridge0_alias0="inet 146.64.84.1/24" Also with the atheros driver I had problems in the past with some parameters that did not like to be on a single commandline. FWIW I do not find the "ifconfig iface -alias" to be a problem... probably because I'm used to it. :-) What I do find silly is that you cannot do "ifconfig iface tunnel inet6 " anymore. It used to work and is still documented in ifconfig(8) to work. You have to swap inet6 and tunnel for it to work. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
On Mon, Feb 12, 2007 at 11:07:39AM -0800, Jeremy Chadwick wrote: > On Mon, Feb 12, 2007 at 11:59:40AM -0600, Brooks Davis wrote: > > What do you need to set? It's sets IP and netmask. It doesn't handle > > broadcast, but I'd be pretty suprised if that's needed often. What else > > is needed? Axing ifconfig_iface_aliasX is not needed, but reducing the > > visiability of the interface in the documentation is probably in order > > particularly since it's quite fragile since you have to renumber whenever > > you remove an entry. > > Does it support media and mediaopt arguments? These are very > commonly used. I also rely on this, for what it's worth: > > openvpn_enable="yes" > openvpn_configfile="/conf/ME/openvpn/openvpn.conf" > openvpn_dir="/conf/ME/openvpn" > openvpn_if="tap" > cloned_interfaces="bridge0" > ifconfig_bridge0="addm em1 up" Setting media options and the like via _aliasesX variables makes no sense and you don't appear to be doing it so I'm confused by your question. The ifconfig_iface_aliasX syntax exists to add IPv4 addresses to an interface. New ipv4_addrs_iface variable is an attempt to replace that and nothing more. -- Brooks pgpDJbRFRO3nm.pgp Description: PGP signature
Re: Desired behaviour of "ifconfig -alias"
On Mon, Feb 12, 2007 at 11:59:40AM -0600, Brooks Davis wrote: > What do you need to set? It's sets IP and netmask. It doesn't handle > broadcast, but I'd be pretty suprised if that's needed often. What else > is needed? Axing ifconfig_iface_aliasX is not needed, but reducing the > visiability of the interface in the documentation is probably in order > particularly since it's quite fragile since you have to renumber whenever > you remove an entry. Does it support media and mediaopt arguments? These are very commonly used. I also rely on this, for what it's worth: openvpn_enable="yes" openvpn_configfile="/conf/ME/openvpn/openvpn.conf" openvpn_dir="/conf/ME/openvpn" openvpn_if="tap" cloned_interfaces="bridge0" ifconfig_bridge0="addm em1 up" -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
On Mon, Feb 12, 2007 at 07:23:33PM +0100, Oliver Fromme wrote:
> Brooks Davis wrote:
> > Oliver Fromme wrote:
> > > Brooks Davis wrote:
> > > > ipv4_addrs_ is a much better replacement IMO. It's easy to
> > > > use and doesn't required the hackish pseudo array traversal used by
> > > > ifconfig_iface_aliasX.
> > >
> > > That might work for simple cases, but how do you specify
> > > other parameters beside the IPs if you need to?
> >
> > What do you need to set? It's sets IP and netmask. It doesn't handle
> > broadcast, but I'd be pretty suprised if that's needed often.
>
> True, not often, but sometimes. I had cases like that in
> certain environments with bridged networks and arp proxies.
>
> I'm fine with your proposed syntax, as long as all the
> existing ifconfig possibilities continue to be possible,
> i.e. no regression.
FWIW, it's HEAD and 6.1. We've actually got the aliases syntax labled
as deprecated in the manpage. We might want to add a feature to set the
broadcast address.
> > is needed? Axing ifconfig_iface_aliasX is not needed, but reducing the
> > visiability of the interface in the documentation is probably in order
> > particularly since it's quite fragile since you have to renumber whenever
> > you remove an entry.
>
> Yup, I agree, that's a PITA. That could be solved in the
> shell code, though, by not enumerating until a number
> doesn't exist, but instead looking at the set of all
> shell variables that have been set, similar to this:
>
> set | grep "^ifconfig_${IFACE}_alias" | cut -f1 -d= | ...
Unfortuanly grep in in /usr/bin so can't be used. You could do it
with sh variable mangling and case though. Something like:
{ while read _var; do
_var=${_var%%=*}
case $_var in
ifconfig_${IFACE}_alias*)
<...>
;;
esac
done } < `set`
-- Brooks
pgpb032iAXeAy.pgp
Description: PGP signature
Re: Desired behaviour of "ifconfig -alias"
Brooks Davis wrote:
> Oliver Fromme wrote:
> > Brooks Davis wrote:
> > > ipv4_addrs_ is a much better replacement IMO. It's easy to
> > > use and doesn't required the hackish pseudo array traversal used by
> > > ifconfig_iface_aliasX.
> >
> > That might work for simple cases, but how do you specify
> > other parameters beside the IPs if you need to?
>
> What do you need to set? It's sets IP and netmask. It doesn't handle
> broadcast, but I'd be pretty suprised if that's needed often.
True, not often, but sometimes. I had cases like that in
certain environments with bridged networks and arp proxies.
I'm fine with your proposed syntax, as long as all the
existing ifconfig possibilities continue to be possible,
i.e. no regression.
> is needed? Axing ifconfig_iface_aliasX is not needed, but reducing the
> visiability of the interface in the documentation is probably in order
> particularly since it's quite fragile since you have to renumber whenever
> you remove an entry.
Yup, I agree, that's a PITA. That could be solved in the
shell code, though, by not enumerating until a number
doesn't exist, but instead looking at the set of all
shell variables that have been set, similar to this:
set | grep "^ifconfig_${IFACE}_alias" | cut -f1 -d= | ...
Best regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606, USt-Id: DE204219783
Any opinions expressed in this message are personal to the author and may
not necessarily reflect the opinions of secnetix GmbH & Co KG in any way.
FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd
"C is quirky, flawed, and an enormous success."
-- Dennis M. Ritchie.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
JoaoBR <[EMAIL PROTECTED]> wrote: > Oliver Fromme wrote: > > JoaoBR <[EMAIL PROTECTED]> wrote: > > > > "ifconfig nic -alias" is obviously a wired and confusing behaviour > > > > It might be confusing to you. Personally I think that the > > current behaviour isn't that far off. > > the question is not you or me, Right. But you called it "confusing". That's just your personal perception. It doesn't mean it is confusing to everybody. In fact it might be useful to others. It _is_ useful to me, for example, and I would object for that syntax to go away. Also note that it doesn't hurt anybody. If you don't like that that syntax doesn't throw an error, then don't use that syntax. However, I agree that the manual page should be updated a bit to match reality. If nobody else does it, I can take a shot at it and submit a docs PR. > > First you need to be aware that there is no distinction > > between a primary IP and alias IPs (such a distinction > > existed historically, but it's gone). All of the IPs on > > an interface are equal, just like hardlinks on a file. > > I said this in shorter words in my post but it is not the point at all. It's not "the" point, but it's an important detail. > > The "-alias" parameter simply removes an address from an > > man page tells us that it removes THE specified address ... not AN address I didn't say what the manpage says, I said what the "-alias" parameter does. If the manpage says something different, I suggest that the manpage should be fixed. > > interface. The term "alias" should really be avoided > > because it is misleading. You can use "delete" or "remove" > > which do the same thing. I think "-alias" should really > > be regarded to exist for backwards compatibility only. > > Personally I always use "delete". > > it is not misleading and it is a perfect term. With alias you add secondary > addresses to an interface. Like secondary is probably the better word, No, not at all. As soon as you use the terms "primary IP address" and "secondary IP addresses", you imply that they are not equal. But they are equal. It's just a list of IP addresses assigned to an interface which happens to have a certain order. > I know that I can add the first IP also with alias but that is not the usual > way. The usual way is to use "add" and "delete". Well, at least for me. (I'm not advocating to remove the historical "alias" and "-alias" parameters, if that's what you're afraid of. Use them if you like them. That's not the point.) > Also do not forget that the usual way since ever is ifconfig_nic_alias0 to > add one. So this thing is confusing. Yes, that's why I wrote it should be changed to not contain the word "alias" anymore, but simply an enumerated list. > > If no IP address is specified, then it's not completely > > nonsensical to remove the first address. In fact I've > > used that short-cut to quickly remove the only address > > from an interface. I've used "ifconfig xyz0 delete" > > quite a lot. > > the man page tells us that -alias removes *the* specified address and not > the > first, also the man page does not say that there is any further action when > *no* IP address specified That's true. Usually if something is not documented, the behaviour is undefined. > delete is according to the man page another word for -alias, that means, > using > grammatical logic that -alias is the main command, No. It means that "delete" and "remove" are aliases for "-alias". In reality they're simply equal. ;-) > then according to the man > page there is no other command as "-alias *IP*" to remove an IP address > and -alias only should not remove anything It's not documented that way. As I wrote above. If something is not documented, that doesn't mean that it shouldn't do anything at all. In that case a _lot_ of things wouldn't work. :-) > > > then already beeing here there is more, ifconfig nic alias does not > > > return anything at all > > > > That's the same as "ifconfig nic add". If you don't tell > > it anything to add, then it won't add anything, of course. > > Remember that UNIX always tries to do exactly what you > > tell it to dao. ;-) > > > > you see, now you apply logic because you want to and when not not ... ;) > > to let it more clear what I mean, you say: "you don't tell it anything to > add" > so why the heck "ifconfig nic -alias" should remove one if I do not tell so? In the case of adding something, what should be added if nothing is specified? Should the tool invent an arbitrary IP address and add it? Now that would be nonsensical. But when removing something without specifying which one, it makes some sense to simply remove the first existing address on that interface. It would even be OK with me to remove the last one, or an arbitrary one -- I use that shortcut mostely when I need to remove the only address from an interface (or all e
Re: Desired behaviour of "ifconfig -alias"
On Mon, Feb 12, 2007 at 06:39:35PM +0100, Oliver Fromme wrote: > Brooks Davis wrote: > > Oliver Fromme wrote: > > > Jeremy Chadwick wrote: > > > > Oliver Fromme wrote: > > > > FWIW, I still use alias/-alias. Mainly because that's what has > > > > existed historically, and the term "alias" is what is used in > > > > reference to rc.conf ifconfig_iface_aliasX entries. > > > > > > Maybe it would make sense to remove "alias" from the rc.conf > > > entries and simply number them. > > > > ipv4_addrs_ is a much better replacement IMO. It's easy to > > use and doesn't required the hackish pseudo array traversal used by > > ifconfig_iface_aliasX. > > That might work for simple cases, but how do you specify > other parameters beside the IPs if you need to? What do you need to set? It's sets IP and netmask. It doesn't handle broadcast, but I'd be pretty suprised if that's needed often. What else is needed? Axing ifconfig_iface_aliasX is not needed, but reducing the visiability of the interface in the documentation is probably in order particularly since it's quite fragile since you have to renumber whenever you remove an entry. -- Brooks pgpqE8HaqK79J.pgp Description: PGP signature
Re: Desired behaviour of "ifconfig -alias"
Brooks Davis wrote: > Oliver Fromme wrote: > > Jeremy Chadwick wrote: > > > Oliver Fromme wrote: > > > FWIW, I still use alias/-alias. Mainly because that's what has > > > existed historically, and the term "alias" is what is used in > > > reference to rc.conf ifconfig_iface_aliasX entries. > > > > Maybe it would make sense to remove "alias" from the rc.conf > > entries and simply number them. > > ipv4_addrs_ is a much better replacement IMO. It's easy to > use and doesn't required the hackish pseudo array traversal used by > ifconfig_iface_aliasX. That might work for simple cases, but how do you specify other parameters beside the IPs if you need to? I agree that the array traversal is somewhat hackish, but at least it works and provides a way to set all ifconfig parameters that you need. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, USt-Id: DE204219783 Any opinions expressed in this message are personal to the author and may not necessarily reflect the opinions of secnetix GmbH & Co KG in any way. FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." -- Robert Firth ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: install on USB flash memory
Jeremy Chadwick написа: > On Mon, Feb 12, 2007 at 05:22:59PM +0200, Todorov @ Paladin wrote: > >> Hi list, >> I'm trying ot install FBSD on USB flash (2.0) SanDisk 512MB. The >> procedure went good - I see first stage of the loader (which slice to >> boot from) and then continuously scrolling assembler data registers. >> >> My target is simple - booting FBSD from USB flash. I've tried tutorial >> from : >> >> http://typo.submonkey.net/articles/2006/04/13/installing-freebsd-on-usb-stick-episode-2 >> >> Laptop is Centrino based and supports USB 2.0 and booting from USB "hdd". >> > > I think this has been discussed before. The problem is that FreeBSD's > bootloader doesn't support booting off of such devices, thus you > need to use GRUB or another bootloader. > > Thanks I will try this way.. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
On Monday 12 February 2007 12:26, Oliver Fromme wrote: > JoaoBR <[EMAIL PROTECTED]> wrote: > > "ifconfig nic -alias" is obviously a wired and confusing behaviour > > It might be confusing to you. Personally I think that the > current behaviour isn't that far off. > the question is not you or me, I guess that you are like me perfectly capable of working around messed things. But that does not make it being right or acceptable. > First you need to be aware that there is no distinction > between a primary IP and alias IPs (such a distinction > existed historically, but it's gone). All of the IPs on > an interface are equal, just like hardlinks on a file. I said this in shorter words in my post but it is not the point at all. > The "-alias" parameter simply removes an address from an man page tells us that it removes THE specified address ... not AN address > interface. The term "alias" should really be avoided > because it is misleading. You can use "delete" or "remove" > which do the same thing. I think "-alias" should really > be regarded to exist for backwards compatibility only. > Personally I always use "delete". > it is not misleading and it is a perfect term. With alias you add secondary addresses to an interface. Like secondary is probably the better word, as cisco does, but what we have is alias and that is ok. It could be any other word so long as it works as it should. (We do have "add" also I remember.) also don't forget the following, alias is a perfect and usual term, then when I can add an IP address with the alias cmd then -alias should remove it. I know that I can add the first IP also with alias but that is not the usual way. Also do not forget that the usual way since ever is ifconfig_nic_alias0 to add one. So this thing is confusing. > If no IP address is specified, then it's not completely > nonsensical to remove the first address. In fact I've > used that short-cut to quickly remove the only address > from an interface. I've used "ifconfig xyz0 delete" > quite a lot. the man page tells us that -alias removes *the* specified address and not the first, also the man page does not say that there is any further action when *no* IP address specified delete is according to the man page another word for -alias, that means, using grammatical logic that -alias is the main command, then according to the man page there is no other command as "-alias *IP*" to remove an IP address and -alias only should not remove anything > > > then already beeing here there is more, ifconfig nic alias does not > > return anything at all > > That's the same as "ifconfig nic add". If you don't tell > it anything to add, then it won't add anything, of course. > Remember that UNIX always tries to do exactly what you > tell it to dao. ;-) > you see, now you apply logic because you want to and when not not ... ;) to let it more clear what I mean, you say: "you don't tell it anything to add" so why the heck "ifconfig nic -alias" should remove one if I do not tell so? > > and ifconfig nic -alias on a nic w/o ip returns "can't assign > > requested address" ... > > That error corresponds to EADDRNOTAVAIL, which is the > correct errno to return, because there's no address left > on the interface. However, I agree that the message is > a bit confusing to the unfamiliar. at least one agreement here :) -- João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: What is a good choice of sata-ii raid controller for freebsd?
> Jaime, can you expand a bit about what sort-of motherboard you > installed the 1261ML in? I've yet to find any mainstream motherboards > which have a PCIe x8 slot. Most have x1, some have x4, and many > have x16. I've seen one Supermicro board which has a x8 slot but > is only wired for x4 (has 4 lanes). I'm using a Supermicro X7DVL-E board, which has 1 PCI-e x8 and 1 PCI-e x4 (in an x8 slot). > Based on what I've read, you can install a x8 card in a x16 slot as > long as the x16 slot is wired (physically) for 8 or more lanes. You probably could, but I'm not sure that would work correctly in a non-server board. I think any server board that has a x16 slot would be fine since more servers aren't really designed for using high-end graphics. > My concern is that these x16 slots on motherboards are being primarily > used for video cards, thus I ultimately have no idea what the > manufacturers are testing them with. Most manufacturer documentation > I've seen says "for use with graphics applications". I'll add that > I've only seen x1 and x16 cards until now -- the Areca cards are the > first card I've seen using x8. Looking at Supermicro's site, it seems that pretty much all of the 5000V and 5000P based motherboards have at least one x8 slot. The 5000X based boards have an x16 slot, but those are workstation boards which would likely use that slot for a graphics card. Look at Supermicro's site under Xeon 5300/5100/5000 motherboards. You should be able to find a board that would work just fine for you. Jaime Bozza Qlinks Media Group ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: install on USB flash memory
On Mon, Feb 12, 2007 at 05:22:59PM +0200, Todorov @ Paladin wrote: > Hi list, > I'm trying ot install FBSD on USB flash (2.0) SanDisk 512MB. The > procedure went good - I see first stage of the loader (which slice to > boot from) and then continuously scrolling assembler data registers. > > My target is simple - booting FBSD from USB flash. I've tried tutorial > from : > > http://typo.submonkey.net/articles/2006/04/13/installing-freebsd-on-usb-stick-episode-2 > > Laptop is Centrino based and supports USB 2.0 and booting from USB "hdd". I think this has been discussed before. The problem is that FreeBSD's bootloader doesn't support booting off of such devices, thus you need to use GRUB or another bootloader. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What is a good choice of sata-ii raid controller for freebsd?
On Thu, Feb 08, 2007 at 03:25:57PM -0600, Jaime Bozza wrote: > I want to second the recommendation for Areca controllers. We have two > systems - The first is using an 1160 (16-port PCI-x) with 16 400GB > drives, the 2nd is using the newer 1261ML card (16 port PCI Express, > mini SAS connectors) with 16 500GB drives. Comments below: Jaime, can you expand a bit about what sort-of motherboard you installed the 1261ML in? I've yet to find any mainstream motherboards which have a PCIe x8 slot. Most have x1, some have x4, and many have x16. I've seen one Supermicro board which has a x8 slot but is only wired for x4 (has 4 lanes). Based on what I've read, you can install a x8 card in a x16 slot as long as the x16 slot is wired (physically) for 8 or more lanes. My concern is that these x16 slots on motherboards are being primarily used for video cards, thus I ultimately have no idea what the manufacturers are testing them with. Most manufacturer documentation I've seen says "for use with graphics applications". I'll add that I've only seen x1 and x16 cards until now -- the Areca cards are the first card I've seen using x8. Thoughts/comments? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: java 1.5 diablo binaries from freebsd foundation
On Monday 12 February 2007 01:25 am, Jeffrey Williams wrote: > Has anyone tried loading the java 1.5 diablo binaries from the freebsd > foundation on 6.2 yet? Working fine on my 6.1-RELEASE laptop that was upgraded to 6.2-RELEASE (without upgrading the JRE package). -- Freddie Cash [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
On Mon, Feb 12, 2007 at 05:22:22PM +0100, Oliver Fromme wrote: > Jeremy Chadwick wrote: > > Oliver Fromme wrote: > > FWIW, I still use alias/-alias. Mainly because that's what has > > existed historically, and the term "alias" is what is used in > > reference to rc.conf ifconfig_iface_aliasX entries. > > Maybe it would make sense to remove "alias" from the rc.conf > entries and simply number them. ipv4_addrs_ is a much better replacement IMO. It's easy to use and doesn't required the hackish pseudo array traversal used by ifconfig_iface_aliasX. -- Brooks pgpjd84JGIqz7.pgp Description: PGP signature
Re: Desired behaviour of "ifconfig -alias"
Jeremy Chadwick wrote: > Oliver Fromme wrote: > [...] > > The "-alias" parameter simply removes an address from an > > interface. The term "alias" should really be avoided > > because it is misleading. You can use "delete" or "remove" > > which do the same thing. I think "-alias" should really > > be regarded to exist for backwards compatibility only. > > Personally I always use "delete". > > > > If no IP address is specified, then it's not completely > > nonsensical to remove the first address. In fact I've > > used that short-cut to quickly remove the only address > > from an interface. I've used "ifconfig xyz0 delete" > > quite a lot. > > Great. Okay, so now we have someone who does in fact rely on this > behaviour, except with "delete" not -alias. I just got used to it because it's a convenient shortcut, because you neither have to type nor to copy&paste the IP. > FWIW, I still use alias/-alias. Mainly because that's what has > existed historically, and the term "alias" is what is used in > reference to rc.conf ifconfig_iface_aliasX entries. Maybe it would make sense to remove "alias" from the rc.conf entries and simply number them. > Thus, it may be worthwhile to fix this only for the -alias option, > but leave "delete" and "remove" how they are. I would be happy with that. :) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, USt-Id: DE204219783 Any opinions expressed in this message are personal to the author and may not necessarily reflect the opinions of secnetix GmbH & Co KG in any way. FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?" -- Tom Cargil, C++ Journal ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: install on usb hdd (more info)
I made few steps again and got this errors: Fist put hdd into Chieftec enclosure IU250 and got: uhub2: device problem (IOERROR), disabling port 6 Then hdd is in canyon enclosure: Feb 12 16:58:23 faust kernel: uhub2: device problem (TIMEOUT), disabling port 6 Feb 12 16:58:31 faust kernel: umass0: Myson Century, Inc. USB Mass Storage Device, rev 2.00/b0.08, addr 2 Feb 12 16:58:32 faust kernel: (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 Feb 12 16:58:32 faust kernel: (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error Feb 12 16:58:32 faust kernel: (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition Feb 12 16:58:32 faust kernel: (probe0:umass-sim0:0:0:0): ILLEGAL REQUEST asc:20,0 Feb 12 16:58:32 faust kernel: (probe0:umass-sim0:0:0:0): Invalid command operation code Feb 12 16:58:32 faust kernel: (probe0:umass-sim0:0:0:0): Unretryable error Simple flash stick works like dragon. What to do further? Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
install on USB flash memory
Hi list, I'm trying ot install FBSD on USB flash (2.0) SanDisk 512MB. The procedure went good - I see first stage of the loader (which slice to boot from) and then continuously scrolling assembler data registers. My target is simple - booting FBSD from USB flash. I've tried tutorial from : http://typo.submonkey.net/articles/2006/04/13/installing-freebsd-on-usb-stick-episode-2 Laptop is Centrino based and supports USB 2.0 and booting from USB "hdd". Regards, Todorov. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: install on usb hdd
> How big is the drive? Perhaps it is too large for the BIOS? I hate myself posting so frequently, without anything smart to say. Drive is 40 Gb on 5400. I will go tomorrow to the servicer, maybe the drive is failing. If not, could be perfect flying saucer. Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: install on usb hdd
On 2/12/07, Zoran Kolic <[EMAIL PROTECTED]> wrote: Maybe stupid question, but should I, for any reason, partition usb hdd first and then try to see it in bios and try to install on it? I doubt that should be necessary. Have you checked to see if there are any updates for your BIOS? If so, try installing those and seeing if that will allow the BIOS to see the drive. Never crossed my mind, but... Looks obvious to me that this combination should work with no hitch. Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- -- I'm nerdy in the extreme and whiter than sour cream ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: install on usb hdd
Original-Nachricht Datum: Mon, 12 Feb 2007 16:14:20 +0100 Von: Zoran Kolic <[EMAIL PROTECTED]> An: Andy Greenwood <[EMAIL PROTECTED]> CC: freebsd-stable@freebsd.org Betreff: Re: install on usb hdd > Huh! My bios sees usb flash stick pretty easily. This is 2.5 inch hdd > of WD and simple enclosure with two usb connectors for data and power. > I've heard that not all enclosures could boot, but no further reading > on the net. Could be this new hdd gone dead before even installed. I > load umass module and cannot see headers saying "WD etc". > Does someone use 2.5 usb hdd to install at it at all? I'm stranded > in this moment without clue. What data should bios get to add hdd to > the boot list? > > Zoran Hi Zoran, first of all, I think installation won't be possible with the menu-driven installer (sysinstall), so you'll have to do this manually (i.e. by using the install.sh scripts on the CD and creating rc.conf fstab and the like by hand). So boot into "fixit" and check your dmesg. If the enclosure is supported by freebsd, the disk will probably show up as something like "/dev/da0". If it is not supported as a umass device, it will be named something like "/dev/ugen0". If you don't see anything, try to unplug and plug in the device and check your dmesg again. If nothing shows up at all (although the relevant kernel modules are loaded, check that first), it might really be broken. Booting from the drive after installation is a different problem however, this depends solely on the Bios of your machine. Regards, Jost Menke -- "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
On Mon, Feb 12, 2007 at 03:26:18PM +0100, Oliver Fromme wrote: > Changing the behaviour of tools always involves a certain > danegr of breaking existing script. That's especially true > for symstem administration commands such as ifconfig that > are running in automated scripts, and people depend on them > for booting their machines remotely. If anyone depends on "ifconfig iface -alias" I'll be surprised. (Ed. - I see you do rely on it, just with "delete" not "-alias"). > I'm not saying that people are intentionally using that > syntax ... Maybe they are, maybe not. But you also should > take into accounts that there might be scripts that use the > syntax inadvertantly and happen to work correctly because > of the current behaviour. If the problem with -alias without any inet/inet6 arguments is addressed, it's going to break things for administrators who have custom in-house scripts that rely on this behaviour. There's absolutely nothing we can do about that, other than put an entry in UPDATING about the change. This has been standard practise for quite some time now -- administrators are *expected* to look at UPDATING when rebuilding world. Changing this functionality also means one must go through all existing scripts throughout src-all as well as possibly ports-all to see if anything "might" rely on this behaviour: and then change those appropriately. > I'm also _not_ saying that the behaviour must not be changed > at all. But it should be done carefully, i.e. first to > -current, with proper "heads up" warnings. Don't change > it in RELENG_6 without warning and expect evrybody to be > happy. I absolutely agree with this, however, to play the devil's advocate, I'll point out that hardly anyone using FreeBSD in a production environment runs -CURRENT. Therefore, when changes are made to -STABLE, one can expect people to come out of the woodwork wielding sharp, pointy objects on mailing lists. > The "-alias" parameter simply removes an address from an > interface. The term "alias" should really be avoided > because it is misleading. You can use "delete" or "remove" > which do the same thing. I think "-alias" should really > be regarded to exist for backwards compatibility only. > Personally I always use "delete". > > If no IP address is specified, then it's not completely > nonsensical to remove the first address. In fact I've > used that short-cut to quickly remove the only address > from an interface. I've used "ifconfig xyz0 delete" > quite a lot. Great. Okay, so now we have someone who does in fact rely on this behaviour, except with "delete" not -alias. FWIW, I still use alias/-alias. Mainly because that's what has existed historically, and the term "alias" is what is used in reference to rc.conf ifconfig_iface_aliasX entries. Thus, it may be worthwhile to fix this only for the -alias option, but leave "delete" and "remove" how they are. > > and ifconfig nic -alias on a nic w/o ip returns "can't assign > > requested address" ... > > That error corresponds to EADDRNOTAVAIL, which is the > correct errno to return, because there's no address left > on the interface. However, I agree that the message is > a bit confusing to the unfamiliar. Agreed. In the case of -alias, this should probably result in a more user-friendly message. Then again, I've found similar confusing entries when it comes to other parts of the networking stack, such as ipfw deny entries resulting in "Permission denied" when trying to do socket-level operations. Took me a while to figure out that it was ipfw inducing that. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: install on usb hdd
Maybe stupid question, but should I, for any reason, partition usb hdd first and then try to see it in bios and try to install on it? Never crossed my mind, but... Looks obvious to me that this combination should work with no hitch. Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: install on usb hdd
On Mon, 12 Feb 2007 16:14:20 +0100 Zoran Kolic <[EMAIL PROTECTED]> wrote: > Hi Andy! > > > IIRC, you can only install to drives that the bios can see. You could > > try finding a computer whose bios can see the drive and installing > > from there. As long as you don't touch the internal drives on that > > machine, everything *should* be safe. YMMV > > Huh! My bios sees usb flash stick pretty easily. This is 2.5 inch hdd > of WD and simple enclosure with two usb connectors for data and power. > I've heard that not all enclosures could boot, but no further reading > on the net. Could be this new hdd gone dead before even installed. I > load umass module and cannot see headers saying "WD etc". > Does someone use 2.5 usb hdd to install at it at all? I'm stranded > in this moment without clue. What data should bios get to add hdd to > the boot list? How big is the drive? Perhaps it is too large for the BIOS? Dominic ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: install on usb hdd
Hi Andy! > IIRC, you can only install to drives that the bios can see. You could > try finding a computer whose bios can see the drive and installing > from there. As long as you don't touch the internal drives on that > machine, everything *should* be safe. YMMV Huh! My bios sees usb flash stick pretty easily. This is 2.5 inch hdd of WD and simple enclosure with two usb connectors for data and power. I've heard that not all enclosures could boot, but no further reading on the net. Could be this new hdd gone dead before even installed. I load umass module and cannot see headers saying "WD etc". Does someone use 2.5 usb hdd to install at it at all? I'm stranded in this moment without clue. What data should bios get to add hdd to the boot list? Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: java 1.5 diablo binaries from freebsd foundation
Jeffrey Williams wrote: > Has anyone tried loading the java 1.5 diablo binaries from the freebsd > foundation on 6.2 yet? > > Thanks > Jeff Just reinstalled my workstation at the office at the beginning of the year with 6.2 and installed the diablo-jdk-1.5.0.07.01 binary package. Been running fine for a month with no problems, browser java plugin works very nicely with Firefox 2.0. -Proto ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: install on usb hdd
On 2/10/07, Zoran Kolic <[EMAIL PROTECTED]> wrote: Howdy! I tried to install 6.2 amd64 on external usb hdd, but with no result. It is 2.5 WD and enclosure with two usb connectors for power. The box is not visible from bios at all, even when I use powered usb hub. Is it possible to install on external device like this? Product is from canyon. Should I buy another enclosure or look for internal 3.5 drive? Note: neither bios nor installation cd see the external drive. What could I do to have it working? IIRC, you can only install to drives that the bios can see. You could try finding a computer whose bios can see the drive and installing from there. As long as you don't touch the internal drives on that machine, everything *should* be safe. YMMV Zoran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- -- I'm nerdy in the extreme and whiter than sour cream ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Desired behaviour of "ifconfig -alias"
On Mon, Feb 12, 2007 at 03:26:18PM +0100, Oliver Fromme wrote: > JoaoBR <[EMAIL PROTECTED]> wrote: > > Brooks Davis wrote: > > > Jeremy Chadwick wrote: > > > > Kevin Way wrote: > > > > > I recently ran into a bug in the jail startup scripts that caused > this > > > > > command to be executed: > > > > > > > > > > ifconfig bce0 -alias > > > > > > > > > > It turns out that this command eliminated the primary IP for the > > > > > device. > > > > > > > > > > > > > It's way to late to make this change. This is known behavior and has > > > been for ages. If there's a bug it's in the documentation. > > > > wellwell, we also were apes for ages but does not mean that we stay > behaving > > like them and if some still does so it is also never to late to change > > that ;) > > Changing the behaviour of tools always involves a certain > danegr of breaking existing script. That's especially true > for symstem administration commands such as ifconfig that > are running in automated scripts, and people depend on them > for booting their machines remotely. > > I'm not saying that people are intentionally using that > syntax ... Maybe they are, maybe not. But you also should > take into accounts that there might be scripts that use the > syntax inadvertantly and happen to work correctly because > of the current behaviour. > > I'm also _not_ saying that the behaviour must not be changed > at all. But it should be done carefully, i.e. first to > -current, with proper "heads up" warnings. Don't change > it in RELENG_6 without warning and expect evrybody to be > happy. This is the point I attempted to make and failed at earlier. The general policy would be that we could change it to fail in current, but doing more than emitting a warning in STABLE would be risky. -- Brooks pgp68GwiAI36b.pgp Description: PGP signature
Re: Desired behaviour of "ifconfig -alias"
JoaoBR <[EMAIL PROTECTED]> wrote: > Brooks Davis wrote: > > Jeremy Chadwick wrote: > > > Kevin Way wrote: > > > > I recently ran into a bug in the jail startup scripts that caused this > > > > command to be executed: > > > > > > > > ifconfig bce0 -alias > > > > > > > > It turns out that this command eliminated the primary IP for the > > > > device. > > > > > > > > > It's way to late to make this change. This is known behavior and has > > been for ages. If there's a bug it's in the documentation. > > wellwell, we also were apes for ages but does not mean that we stay behaving > like them and if some still does so it is also never to late to change > that ;) Changing the behaviour of tools always involves a certain danegr of breaking existing script. That's especially true for symstem administration commands such as ifconfig that are running in automated scripts, and people depend on them for booting their machines remotely. I'm not saying that people are intentionally using that syntax ... Maybe they are, maybe not. But you also should take into accounts that there might be scripts that use the syntax inadvertantly and happen to work correctly because of the current behaviour. I'm also _not_ saying that the behaviour must not be changed at all. But it should be done carefully, i.e. first to -current, with proper "heads up" warnings. Don't change it in RELENG_6 without warning and expect evrybody to be happy. > "ifconfig nic -alias" is obviously a wired and confusing behaviour It might be confusing to you. Personally I think that the current behaviour isn't that far off. First you need to be aware that there is no distinction between a primary IP and alias IPs (such a distinction existed historically, but it's gone). All of the IPs on an interface are equal, just like hardlinks on a file. Maybe the manual page should be clearer about that. The "-alias" parameter simply removes an address from an interface. The term "alias" should really be avoided because it is misleading. You can use "delete" or "remove" which do the same thing. I think "-alias" should really be regarded to exist for backwards compatibility only. Personally I always use "delete". If no IP address is specified, then it's not completely nonsensical to remove the first address. In fact I've used that short-cut to quickly remove the only address from an interface. I've used "ifconfig xyz0 delete" quite a lot. > then already beeing here there is more, ifconfig nic alias does not return > anything at all That's the same as "ifconfig nic add". If you don't tell it anything to add, then it won't add anything, of course. Remember that UNIX always tries to do exactly what you tell it to dao. ;-) > and ifconfig nic -alias on a nic w/o ip returns "can't assign > requested address" ... That error corresponds to EADDRNOTAVAIL, which is the correct errno to return, because there's no address left on the interface. However, I agree that the message is a bit confusing to the unfamiliar. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, USt-Id: DE204219783 Any opinions expressed in this message are personal to the author and may not necessarily reflect the opinions of secnetix GmbH & Co KG in any way. FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I suggested holding a "Python Object Oriented Programming Seminar", but the acronym was unpopular. -- Joseph Strout ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
February 2007 Monthly Snapshots
Just a note to say the February 2007 Monthly Snapshots are completed and available at "ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/200702/";. With the FreeBSD-6.2 release cycle over we're now back to doing RELENG_6 snapshots as well as the HEAD snapshots. Sums: MD5 (6.2-STABLE-200702-alpha-bootonly.iso) = a60ebb0f0c018017ea59e00a36809736 MD5 (6.2-STABLE-200702-alpha-disc1.iso) = 9665903224462348ec149e3a510abb5b MD5 (6.2-STABLE-200702-alpha-docs.iso) = 3a3018da233ec34235d4e84209e4b2d8 MD5 (6.2-STABLE-200702-amd64-bootonly.iso) = 39a9d901a70659e60be2194ea4e9114f MD5 (6.2-STABLE-200702-amd64-disc1.iso) = 3dc514c21cee201be1fde2ab949096f9 MD5 (6.2-STABLE-200702-amd64-disc2.iso) = 15d383b5353016da2daef8a56dc684e7 MD5 (6.2-STABLE-200702-amd64-docs.iso) = 2d99bdab55d858fb587066e00fefb23c MD5 (6.2-STABLE-200702-i386-bootonly.iso) = 1f8a2dd6d5fe96d9e77335ab59a27eb2 MD5 (6.2-STABLE-200702-i386-disc1.iso) = be5ee3e46dc766eeac15dcc59ce5739d MD5 (6.2-STABLE-200702-i386-disc2.iso) = 14a10aea69e2d69c75273a02c03b325c MD5 (6.2-STABLE-200702-i386-docs.iso) = 1a9599db4bdbf4516dd4376c9882b054 MD5 (6.2-STABLE-200702-ia64-bootonly.iso) = 09b2df8098fae0c7750ff5b38f245493 MD5 (6.2-STABLE-200702-ia64-disc1.iso) = c4d1c3860e096c4c501e3bfe5f72231b MD5 (6.2-STABLE-200702-ia64-docs.iso) = 84e8ffdbcf3f8cf6b86b0b7f65414437 MD5 (6.2-STABLE-200702-ia64-livefs.iso) = 3a423f03453c50a75da5c9cd91f5179a MD5 (6.2-STABLE-200702-pc98-bootonly.iso) = 8e571bc64dcd65975123d10e15dd3375 MD5 (6.2-STABLE-200702-pc98-disc1.iso) = 8bd23dd0afe3284300d88952307b0ecf MD5 (6.2-STABLE-200702-powerpc-bootonly.iso) = 00c214147c5f71d28728d3e411e9a2bb MD5 (6.2-STABLE-200702-powerpc-disc1.iso) = cb430a8ceeece906eedf300633678013 MD5 (6.2-STABLE-200702-powerpc-docs.iso) = f93a6440c0ff9cb764066595d24e5bdf MD5 (6.2-STABLE-200702-sparc64-bootonly.iso) = b9648a370c8c6cbcb813689aea0797d8 MD5 (6.2-STABLE-200702-sparc64-disc1.iso) = 3de836883f68710aec923580fc6183e0 MD5 (6.2-STABLE-200702-sparc64-disc2.iso) = f4ea9cae2a07f732f11d5fbf03f47bda MD5 (6.2-STABLE-200702-sparc64-docs.iso) = d5f21def1331cbd169bfd55399696db9 MD5 (7.0-CURRENT-200702-amd64-bootonly.iso) = b201bb3efc6892900efacea76b7d710a MD5 (7.0-CURRENT-200702-amd64-disc1.iso) = 13d3c034077fd1dcb1af9e2040b97a0d MD5 (7.0-CURRENT-200702-amd64-disc2.iso) = d68e6872a50b2469b1d4edb010d8b73e MD5 (7.0-CURRENT-200702-amd64-docs.iso) = d2d9d335b6887021ae96deafc17dbb4b MD5 (7.0-CURRENT-200702-i386-bootonly.iso) = bd57eb4f5f536366c7bf1fde177f5c17 MD5 (7.0-CURRENT-200702-i386-disc1.iso) = 1c22965007036634cb180a3c2392cf2f MD5 (7.0-CURRENT-200702-i386-disc2.iso) = 5f00f6ce6ee2b9dd7751f04ac8d7d7fd MD5 (7.0-CURRENT-200702-i386-docs.iso) = ccf36bcf2e9a2fc52dd61d98786d1aaa MD5 (7.0-CURRENT-200702-ia64-bootonly.iso) = 23d73bb6c8e2c8787641278877cf9a3e MD5 (7.0-CURRENT-200702-ia64-disc1.iso) = 18cb85f9ef928b6260aa87c7cc0a6dca MD5 (7.0-CURRENT-200702-ia64-docs.iso) = 511e637525040cbd45b6a4281cce517d MD5 (7.0-CURRENT-200702-ia64-livefs.iso) = 98821dd0b2c58cacd64dee240e651b67 MD5 (7.0-CURRENT-200702-pc98-bootonly.iso) = 3c792b3b3e103801760a23d3e1431c27 MD5 (7.0-CURRENT-200702-pc98-disc1.iso) = b41475856d17043d540e9eaa891485a8 MD5 (7.0-CURRENT-200702-powerpc-bootonly.iso) = 6c4382e4ba94ba6bb5f4e5118f44965b MD5 (7.0-CURRENT-200702-powerpc-disc1.iso) = d9a80a191b4badee1692ab4e0045b5c9 MD5 (7.0-CURRENT-200702-powerpc-docs.iso) = f255946c67ad64e1ab08fe06303fc6e6 MD5 (7.0-CURRENT-200702-sparc64-bootonly.iso) = 33df8cf37941bbb120401870587d970d MD5 (7.0-CURRENT-200702-sparc64-disc1.iso) = 9174008c5a63851a6a7afb013598820a MD5 (7.0-CURRENT-200702-sparc64-disc2.iso) = fd9d2fa518d643432c560d6772a1d352 MD5 (7.0-CURRENT-200702-sparc64-docs.iso) = f0b0a3e79f15dcaa204dcfd1c8a047b0 SHA256 (6.2-STABLE-200702-alpha-bootonly.iso) = 1f376509b866bf1ba3862584ec7dc9a305705c025b10f69f7ad4c8eb0bcec3ea SHA256 (6.2-STABLE-200702-alpha-disc1.iso) = 335fca846bde966fa18e37d40c129aa588dabed8710dea64b76c33231c13714b SHA256 (6.2-STABLE-200702-alpha-docs.iso) = c721b44ccaf815a889759cb8878934cbc12753789f5ae05d43c59805126631b1 SHA256 (6.2-STABLE-200702-amd64-bootonly.iso) = c26160072e933382ec0c0c59fa1421d78a4b7bc8112477e3af64e352f189c23c SHA256 (6.2-STABLE-200702-amd64-disc1.iso) = 58d00646ef60b6b5b3ef015c30a0c424dfa7c2a0c03c7e27d4e1a578e0ced98d SHA256 (6.2-STABLE-200702-amd64-disc2.iso) = 46d7fca19bb79ba22951d1f17b476d1c22427c79eafe9f31c64a75fe5aac6865 SHA256 (6.2-STABLE-200702-amd64-docs.iso) = 75768467fdcfd98ec0bdf2252aba9c9301407e7623cfdd982abfd6a50876dfd9 SHA256 (6.2-STABLE-200702-i386-bootonly.iso) = 70876322cdd2f03ba193b28cb31347130cc9d99a91fd6c5bd17d40dc54506bdb SHA256 (6.2-STABLE-200702-i386-disc1.iso) = f5dd3a1eb4103f8966bedd42b977ab92ece2cdb56cbb4c8c60e9a4c455bdf8b5 SHA256 (6.2-STABLE-200702-i386-disc2.iso) = 303bfdb79cbead79dfc82bb53155a9a850ea253e25add16bf206fa5f3cdc25c8 SHA256 (6.2-STABLE-200702-i386-docs.iso) = 69d2f5a53d9b3e9c91e2771971edfbb55ec02ab842a3ca2ba02a5823feceed03 SHA256 (6.2-STABLE-200702-ia64-bootonly.iso) = 9a06075db2fdd
Re: java 1.5 diablo binaries from freebsd foundation
Jeffrey Williams wrote: Has anyone tried loading the java 1.5 diablo binaries from the freebsd foundation on 6.2 yet? Yes. I used diablo-jdk-freebsd6.i386.1.5.0.07.00 since November to do some Swing development with SwingWorker, and it worked just fine. BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PXEboot fails at kernel (text) loading
Rob wrote: Is it OK to have a double kernel read at the last two lines? Any idea what's wrong here or what I could do to further test what the actual problem is? Argh. I had this same problem as recently as October, but I can't remember exactly what caused this. When I went back and re-did things according to 'man diskless' (and what Doug White told me in the first place), it all worked. Regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
problems with sil3512 on freebsd 6.1
Hi, (please CC me, I'm not subscribed) I'm currently working on a freebsd box I've inherited from the former admin, and been tasked with installing new hard disks on sata. Currently, it has a scsi disk containing the system and an ide disk containing the data partitions (it's a file server). While I managed to access the sata disks, and set up a geom mirror on it, it's highly unstable, and crashes reliably when accessing the sata disks if there is load on network or the ide bus. it's relatively stable if only sata is accessed. The sata controller in use hosts a sil3512 chipset. disabling dma via hw.ata.ata_dma doesn't help. Any ideas if that chip is known to have such problems (despite being listed on ata(4))? Any things I could try to get it to work, eg. updating, other settings? Thanks in advance, Patrick Georgi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: java 1.5 diablo binaries from freebsd foundation
On Mon, Feb 12, 2007 at 10:55:06AM +0100, O. Hartmann wrote: > Jeffrey Williams wrote: > >Has anyone tried loading the java 1.5 diablo binaries from the freebsd > >foundation on 6.2 yet? > > > >Thanks > >Jeff > >___ > >freebsd-stable@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > > Well, if you mean the diablo-jdk15 port, the nyes, I tried it to compile > AZUREUS (amd64) and used this port for OpenOffice 2.1 (i386) - and it > works. On FreeBSD 7.0 it does not work due to dibalo-binaries they > expect libc.so.6 which is now libc.so.7 in FreeBSD 7 CURRENT. > Linking libc.so.7 to libc.so.6 worked around that for me. I've seen no problem with that approach so far. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgpc6VTofdcFA.pgp Description: PGP signature
Re: What is a good choice of sata-ii raid controller for freebsd?
On Monday 12 February 2007 19:07, Peter Jeremy wrote: > On 2007-Feb-12 16:07:03 +1030, Daniel O'Connor <[EMAIL PROTECTED]> wrote: > >I regularly ship systems overseas where the power fails frequently. The > >inability to boot because one disk got hosed is Bad News (tm). > > A decent UPS can help here. We ship good UPSs but our customers aren't made of gold so the battery runs out :) > >It depends on your exact situation, I was just pointing out that SW RAID > >doesn't cover all the bases HW RAID does. > > If the disk is dead then the BIOS will skip it and the system should > boot normally (I've tested this by pulling a disk since I didn't have > a suitable dead disk to hand). A hard error in the 2nd stage boot > loader, ficl or the kernel is definitely the worst case - I agree that > this is very difficult for software raid to recover from. It's not so much SW RAID per se, it's the BIOS that's the weak link. Also, SW RAID would prevent you (safely) writing from the loader, however this is rare/nonexistant so it isn't a big problem. Unfortunately disks dropping totally dead is reasonably rare (in my experience). What is much more like is a progressive failure where more and more of the disk is rendered unreadable. > Note that even with hardware raid, there are still lots of failure > points. The least reliable parts of a current computer are the CPU > and PSU fans, not the disks. Amazing when you think the CPU has no moving parts ;) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgptfiOqnEyNr.pgp Description: PGP signature
Re: pppd crashes, was: kde-freebsd] Question about KPPP on FreeBSD
On Sun, 11 Feb 2007, Bruce M. Simpson wrote: > There's information around PPP that's not been communicated or > documented well. The 'performance' way to do PPP on FreeBSD is to go off > and run MPD, because it has the right compromise between doing low-level > packet shunting in the kernel, whilst using Netgraph hooks to tap the > PPP control traffic handling off into userland. On your first point, I'd not looked into MPD before because I'd assumed it was _only_ about multilink PPP, thinking multi meant 'two or more', a misconception not immediately dispelled by the descriptions in ports and on sourceforge, until finding a bundle defined as 'one or more' links. > MPD is wicked cool, and is a well architected way to do things, but the > ultimate utility depends on how useful it is to everyone who might use it. Just now installed mpd4 for a browse over the manuals and example confs and scripts, and am completely gobsmacked by its clarity and scope. To call the scripting language 'chat' is indeed heavy-duty understatement, and the examples alone seem to cover most of what I'll need to know. I'd been mulling over ppp, ng and pppoed docs prior to doing PPPoE here (currently hiding behind an ADSL router) but now know where to start. Thanks! Ian (not at all helpful re the KPPP / pppd issue though, sorry Michael) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: java 1.5 diablo binaries from freebsd foundation
On 2/12/07, Jeffrey Williams <[EMAIL PROTECTED]> wrote: Has anyone tried loading the java 1.5 diablo binaries from the freebsd foundation on 6.2 yet? Yes, and it works OK. I also happen to run the java/jdk15 port and it runs just as smoothly. You can ask the port maintainer about the differences between the two. Given that I'm a total Java illiterate, I can't say I notice any difference. I have a friend though, who's an avid Java developer, that says he's very pleased with the stability and speed of both. Thanks Jeff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE:java 1.5 diablo binaries from freebsd foundation
nope but it was flawless on 5.5 with tomcat regards, wlodek ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gjournal patch
Václav Haisman wrote: > Hi, > yesterday, I tried to build kernel and world with the gjournal patch. It > does not apply cleanly. This brings me to question, are there some > outstanding issues that prevent it from being commited to RELENG_6? I > tried to search ml archives but I did not find any. > > -- > Vaclav Haisman > > > I run it on a 6.2-release server, no problems as yet but its only been a month. The original ptach broke back in november see [http://lists.freebsd.org/pipermail/freebsd-stable/2006-November/030803.html] However because of [http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/vnode.h.diff?r1=1.304.2.7&r2=1.304.2.8&f=h] This doesnt quite apply cleanly but very close to and its easy to manually do the minor diff manually basically add the line #define VV_DELETED 0x0400 /* should be removed */ After #define VV_MD 0x0800 /* vnode backs the md device */ No other issues I'm aware of but i'm not following -STABLE on that box any more. Vince ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: java 1.5 diablo binaries from freebsd foundation
Jeffrey Williams wrote: Has anyone tried loading the java 1.5 diablo binaries from the freebsd foundation on 6.2 yet? Thanks Jeff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]" Well, if you mean the diablo-jdk15 port, the nyes, I tried it to compile AZUREUS (amd64) and used this port for OpenOffice 2.1 (i386) - and it works. On FreeBSD 7.0 it does not work due to dibalo-binaries they expect libc.so.6 which is now libc.so.7 in FreeBSD 7 CURRENT. Regards, Oliver -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: What is a good choice of sata-ii raid controller for freebsd?
On 2007-Feb-12 16:07:03 +1030, Daniel O'Connor <[EMAIL PROTECTED]> wrote: I regularly ship systems overseas where the power fails frequently. The inability to boot because one disk got hosed is Bad News (tm). A decent UPS can help here. No, i can't. I have seen UPS (even APC) fail in some cases. Computers got frozen. Also, i've seen many cases when power failes for more than 4 hours and nobody want to buy UPS which hold 4 hours of power for a dual xeon with 5 hdds. It depends on your exact situation, I was just pointing out that SW RAID doesn't cover all the bases HW RAID does. If the disk is dead then the BIOS will skip it and the system should boot normally (I've tested this by pulling a disk since I didn't have a suitable dead disk to hand). A hard error in the 2nd stage boot loader, ficl or the kernel is definitely the worst case - I agree that this is very difficult for software raid to recover from. No, BIOS does not always do it. If HDD REALLY fails (chips fried or something is really messy) the BIOS often just become frozen and never boots. I have seen it too. I've seen many things, you know :)) Note that even with hardware raid, there are still lots of failure points. The least reliable parts of a current computer are the CPU and PSU fans, not the disks. That is why RAID controller MUST be w/o fans and there must be MANY fans inside server case and there MUST constant temperature monitoring with SMS, EMAIL, ICQ messages on alarams. -- Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
java 1.5 diablo binaries from freebsd foundation
Has anyone tried loading the java 1.5 diablo binaries from the freebsd foundation on 6.2 yet? Thanks Jeff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gjournal patch
Hi, yesterday, I tried to build kernel and world with the gjournal patch. It does not apply cleanly. This brings me to question, are there some outstanding issues that prevent it from being commited to RELENG_6? I tried to search ml archives but I did not find any. -- Vaclav Haisman signature.asc Description: OpenPGP digital signature
Re: What is a good choice of sata-ii raid controller for freebsd?
On 2007-Feb-12 16:07:03 +1030, Daniel O'Connor <[EMAIL PROTECTED]> wrote: >I regularly ship systems overseas where the power fails frequently. The >inability to boot because one disk got hosed is Bad News (tm). A decent UPS can help here. >It depends on your exact situation, I was just pointing out that SW RAID >doesn't cover all the bases HW RAID does. If the disk is dead then the BIOS will skip it and the system should boot normally (I've tested this by pulling a disk since I didn't have a suitable dead disk to hand). A hard error in the 2nd stage boot loader, ficl or the kernel is definitely the worst case - I agree that this is very difficult for software raid to recover from. Note that even with hardware raid, there are still lots of failure points. The least reliable parts of a current computer are the CPU and PSU fans, not the disks. -- Peter Jeremy pgpMu4rg4CR3U.pgp Description: PGP signature
Re: PXEboot fails at kernel (text) loading
On Sun, 11 Feb 2007 17:22:22 -0800 (PST) Rob wrote: > I have a FreeBSD 6.1 PC as the server to a PXE boot > of another Compaq Deskpro EN PC. > The Compaq PC has the option of a "Network Service > Boot" with the F12-key during BIOS boot up. On the > server, tftpd, bootpd and dhcpd are all working well. > For the diskless kernel config I have used the > GENERIC one, but added: >options BOOTP >options BOOTP_NFSROOT >options BOOTP_COMPAT According to man diskless those options are not needed for PXE. > Any idea what's wrong here or what I could do to > further test what the actual problem is? You may consider re-reading man diskless -- all needed info is located there. WBR -- Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
