Re: Dell PowerEdge Virtual Media

2010-06-09 Thread Steven Hartland

For the record this appears to have been fixed in 8.1-BETA so we can
now successfully use the fixit CD mounted from an iso under the IPMI
tool on our supermicro machines. It even fixes the issue where
previously you had to select device rescan for it to see the usb
cdrom after boot :)


- Original Message - 
From: "Steven Hartland" 

The ipmi implementation is limited to CD-sized media on the Supermicro
ipKVM implementations.  Try the CD boot media ISO.


If thats the case why can it happily boot from it? The issue only seemed
to occur here when you tried to access it via the fixit menu even though
the console log showed it as being detected just fine.

I've just retested on the machine now its up and running and see similar
results with both dvd's and cdroms.

Connect dvd iso:
Dec  9 02:21:27 ipmitest root: Unknown USB device: vendor 0x14dd product 0x0002 
bus uhub3
Dec  9 02:21:27 ipmitest kernel: ugen3.2:  at usbus3
Dec  9 02:21:27 ipmitest kernel: umass0:  on usbus3
Dec  9 02:21:27 ipmitest kernel: umass0:  SCSI over Bulk-Only; quirks = 0x
Dec  9 02:21:28 ipmitest kernel: umass0:1:0:-1: Attached to scbus1
Dec  9 02:21:28 ipmitest kernel: ums0:  on usbus3
Dec  9 02:21:28 ipmitest kernel: ums0: 3 buttons and [Z] coordinates ID=0
Dec  9 02:21:28 ipmitest kernel: ukbd0:  on usbus3
Dec  9 02:21:28 ipmitest kernel: kbd2 at ukbd0
Dec  9 02:21:28 ipmitest kernel: (probe0:umass-sim0:0:0:0): TEST UNIT READY. 
CDB: 0 0 0 0 0 0
Dec  9 02:21:28 ipmitest kernel: (probe0:umass-sim0:0:0:0): CAM Status: SCSI 
Status Error
Dec  9 02:21:28 ipmitest kernel: (probe0:umass-sim0:0:0:0): SCSI Status: Check 
Condition
Dec  9 02:21:28 ipmitest kernel: (probe0:umass-sim0:0:0:0): UNIT ATTENTION 
asc:29,0
Dec  9 02:21:28 ipmitest kernel: (probe0:umass-sim0:0:0:0): Power on, reset, or 
bus device reset occurred
Dec  9 02:21:28 ipmitest kernel: (probe0:umass-sim0:0:0:0): Retrying Command 
(per Sense Data)
Dec  9 02:21:28 ipmitest kernel: cd0 at umass-sim0 bus 0 target 0 lun 0
Dec  9 02:21:28 ipmitest kernel: cd0:  Removable 
CD-ROM SCSI-3 device
Dec  9 02:21:28 ipmitest kernel: cd0: 40.000MB/s transfers
Dec  9 02:21:28 ipmitest kernel: cd0: cd present [1058105 x 2048 byte records]

Attempt to mount:
Dec  9 02:23:58 ipmitest kernel: (cd0:umass-sim0:0:0:0): READ TOC/PMA/ATIP. 
CDB: 43 0 0 0 0 0 0 0 4 0
Dec  9 02:23:58 ipmitest kernel: (cd0:umass-sim0:0:0:0): CAM Status: SCSI 
Status Error
Dec  9 02:23:58 ipmitest kernel: (cd0:umass-sim0:0:0:0): SCSI Status: Check 
Condition
Dec  9 02:23:58 ipmitest kernel: (cd0:umass-sim0:0:0:0): UNIT ATTENTION asc:29,0
Dec  9 02:23:58 ipmitest kernel: (cd0:umass-sim0:0:0:0): Power on, reset, or 
bus device reset occurred
Dec  9 02:23:58 ipmitest kernel: (cd0:umass-sim0:0:0:0): Retries Exhausted
Dec  9 02:23:59 ipmitest kernel: g_vfs_done():cd0[READ(offset=32768, 
length=2048)]error = 5

disconnect iso:
Dec  9 02:26:50 ipmitest kernel: ugen3.2:  at usbus3 
(disconnected)
Dec  9 02:26:50 ipmitest kernel: umass0: at uhub3, port 6, addr 2 (disconnected)
Dec  9 02:26:50 ipmitest kernel: (cd0:umass-sim0:0:0:0): lost device
Dec  9 02:26:50 ipmitest kernel: (cd0:umass-sim0:0:0:0): removing device entry
Dec  9 02:26:50 ipmitest kernel: ums0: at uhub3, port 6, addr 2 (disconnected)
Dec  9 02:26:50 ipmitest kernel: ukbd0: at uhub3, port 6, addr 2 (disconnected)
Dec  9 02:26:51 ipmitest kernel: ugen3.2:  at usbus3
Dec  9 02:26:51 ipmitest kernel: ums0:  on usbus3
Dec  9 02:26:51 ipmitest kernel: ums0: 3 buttons and [Z] coordinates ID=0
Dec  9 02:26:51 ipmitest kernel: ukbd0:  on usbus3
Dec  9 02:26:51 ipmitest kernel: kbd2 at ukbd0
Dec  9 02:28:10 ipmitest kernel: ugen3.2:  at usbus3 
(disconnected)
Dec  9 02:28:10 ipmitest kernel: ums0: at uhub3, port 6, addr 2 (disconnected)
Dec  9 02:28:10 ipmitest kernel: ukbd0: at uhub3, port 6, addr 2 (disconnected)

connect cdrom iso:
Dec  9 02:28:11 ipmitest root: Unknown USB device: vendor 0x14dd product 0x0002 
bus uhub3
Dec  9 02:28:11 ipmitest kernel: ugen3.2:  at usbus3
Dec  9 02:28:11 ipmitest kernel: umass0:  on usbus3
Dec  9 02:28:11 ipmitest kernel: umass0:  SCSI over Bulk-Only; quirks = 0x
Dec  9 02:28:13 ipmitest kernel: umass0:1:0:-1: Attached to scbus1
Dec  9 02:28:13 ipmitest kernel: ums0:  on usbus3
Dec  9 02:28:13 ipmitest kernel: ums0: 3 buttons and [Z] coordinates ID=0
Dec  9 02:28:13 ipmitest kernel: ukbd0:  on usbus3
Dec  9 02:28:13 ipmitest kernel: kbd2 at ukbd0
Dec  9 02:28:13 ipmitest kernel: (probe0:umass-sim0:0:0:0): TEST UNIT READY. 
CDB: 0 0 0 0 0 0
Dec  9 02:28:13 ipmitest kernel: (probe0:umass-sim0:0:0:0): CAM Status: SCSI 
Status Error
Dec  9 02:28:13 ipmitest kernel: (probe0:umass-sim0:0:0:0): SCSI Status: Check 
Condition
Dec  9 02:28:13 ipmitest kernel: (probe0:umass-sim0:0:0:0): UNIT ATTENTION 
asc:29,0
Dec  9 02:28:13 ipmitest kernel: (probe0:umass-sim0:0:0:0): Power on, reset, or 
bus device reset occurred
Dec  9 02:28:13 ipmitest kernel: (probe0:umass-sim0:0:0:0): Retrying Command 
(per Sense Data)
Dec  9 02:28:13 ipm

Re: Dell PowerEdge Virtual Media

2010-06-09 Thread Alexander Motin
Steven Hartland wrote:
> For the record this appears to have been fixed in 8.1-BETA so we can
> now successfully use the fixit CD mounted from an iso under the IPMI
> tool on our supermicro machines. It even fixes the issue where
> previously you had to select device rescan for it to see the usb
> cdrom after boot :)

It should be SVN rev 203108 of 2010-01-28.

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


Re: FreeBSD eats 169.254.x.x addressed packets

2010-06-09 Thread Stephen Clark

On 06/08/2010 03:00 PM, Stephen Clark wrote:

On 06/08/2010 02:49 PM, Peter C. Lai wrote:

On 2010-06-08 11:44:29AM -0700, Jeremy Chadwick wrote:

On Tue, Jun 08, 2010 at 02:26:10PM -0400, Stephen Clark wrote:

On 06/08/2010 02:05 PM, Jeremy Chadwick wrote:

On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote:

Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when
4.9 didn't?


The following output would help:

- ifconfig -a
- netstat -rn
- Contents of /etc/rc.conf

Also, be aware that RELENG_6 is to be EOL'd at the end of this year:
http://security.freebsd.org/


Hi Jeremy,

I am not sure that information is relevant. We have two systems
configured
identically one using 4.9 the other 6.3.


My concern was that someone had botched something up in rc.conf or
during the OS upgrade/migration, resulting in there being no loopback
interface. I also wanted to verify that your routing table looked
correct for what ifconfig showed.

Other users pointed you to RFC 3927. Wikipedia has this to say:

http://en.wikipedia.org/wiki/Link-local_address

"Based on RFC 3927, IPv4 uses the 169.254.0.0/16 range of addresses.
However, the first and last /24 subnet (256 addresses each) in this
block have been excluded from use and are reserved by the standard.[1]"

I read this to mean 169.254.0.0/24 and 169.254.255.0/24.

Your previous ifconfig statement shows:


$ ifconfig rl0
rl0: flags=8843 mtu 1500
options=8
inet 192.168.129.1 netmask 0xff00 broadcast 192.168.129.255
inet 169.254.1.1 netmask 0x broadcast 169.254.255.255
ether 00:30:18:ae:7c:77
media: Ethernet autoselect (100baseTX)
status: active


With this configuration, you're using both the first and last /24
netblocks -- 169.254.0.0 for your network address, and 169.254.255.255
for your broadcast address.

You should be able to avoid this by using 169.254.1.0/24.



RFC 3927 also has complicated rules involving when one can or should not
use a link-local address on the same interface as a routable IP, so at
best your configuration may not be supported anyway. One should not use
a link-local address as if it were under RFC 1918 rules, in particular
because link-local involves self-assigned addresses and internal
conflict mitigation.


Again what happened we had a box in the field that was running 4.9 being
used as a router/nat/vpn/firewall device. It was handing out ip addresses
to the internal lan using the range 169.254.202.0/24, who knows why this
address range was picked. It worked great but
the hardware died, so we were replacing it with our current SW which is
based on 6.3 we duplicated the configuration and have been struggling
trying to
get it to work for the customer since Saturday with no luck. Today I
finally
tried to ping the internal address from the box itself and it wouldn't
ping,
so I started trying using other addresses on the internal interface and
they
worked but not 169.254.202.1. In googling I discovered that 169.254/16
was supposed to be assigned if a box couldn't obtain an ip but saw
nothing about
an OS dropping them.

So anyway I know the reason behind the change now.


One final comment - I still don't understand why FreeBSD "won't" respond to 
pings
when it has an address like 169.254.1.1. I can ssh to the unit but it won't
respond to pings. I tried setting up a linux box with an address like
169.254.1.2 and it "would" respond to pings.

--

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)


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


Re: nfe0 loses network connectivity (8.0-RELEASE-p2)

2010-06-09 Thread Olaf Seibert
On Mon 07 Jun 2010 at 22:48:46 +0300, Mikolaj Golub wrote:
> It looks like the issue that has been fixed in STABLE.
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/144330

Indeed, and I applied the patch in there, rebooted, and at least over
the course of the past day, mbuf cluser useage seems not to grow
anymore.

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


Re: FreeBSD eats 169.254.x.x addressed packets

2010-06-09 Thread Jeremy Chadwick
On Wed, Jun 09, 2010 at 07:59:16AM -0400, Stephen Clark wrote:
> On 06/08/2010 03:00 PM, Stephen Clark wrote:
> >On 06/08/2010 02:49 PM, Peter C. Lai wrote:
> >>On 2010-06-08 11:44:29AM -0700, Jeremy Chadwick wrote:
> >>>On Tue, Jun 08, 2010 at 02:26:10PM -0400, Stephen Clark wrote:
> On 06/08/2010 02:05 PM, Jeremy Chadwick wrote:
> >On Tue, Jun 08, 2010 at 01:45:59PM -0400, Stephen Clark wrote:
> >>Why does FreeBSD 6.3 eat 169.254.x.x addressed packet when
> >>4.9 didn't?
> >
> >The following output would help:
> >
> >- ifconfig -a
> >- netstat -rn
> >- Contents of /etc/rc.conf
> >
> >Also, be aware that RELENG_6 is to be EOL'd at the end of this year:
> >http://security.freebsd.org/
> >
> Hi Jeremy,
> 
> I am not sure that information is relevant. We have two systems
> configured
> identically one using 4.9 the other 6.3.
> >>>
> >>>My concern was that someone had botched something up in rc.conf or
> >>>during the OS upgrade/migration, resulting in there being no loopback
> >>>interface. I also wanted to verify that your routing table looked
> >>>correct for what ifconfig showed.
> >>>
> >>>Other users pointed you to RFC 3927. Wikipedia has this to say:
> >>>
> >>>http://en.wikipedia.org/wiki/Link-local_address
> >>>
> >>>"Based on RFC 3927, IPv4 uses the 169.254.0.0/16 range of addresses.
> >>>However, the first and last /24 subnet (256 addresses each) in this
> >>>block have been excluded from use and are reserved by the standard.[1]"
> >>>
> >>>I read this to mean 169.254.0.0/24 and 169.254.255.0/24.
> >>>
> >>>Your previous ifconfig statement shows:
> >>>
> $ ifconfig rl0
> rl0: flags=8843 mtu 1500
> options=8
> inet 192.168.129.1 netmask 0xff00 broadcast 192.168.129.255
> inet 169.254.1.1 netmask 0x broadcast 169.254.255.255
> ether 00:30:18:ae:7c:77
> media: Ethernet autoselect (100baseTX)
> status: active
> >>>
> >>>With this configuration, you're using both the first and last /24
> >>>netblocks -- 169.254.0.0 for your network address, and 169.254.255.255
> >>>for your broadcast address.
> >>>
> >>>You should be able to avoid this by using 169.254.1.0/24.
> >>>
> >>
> >>RFC 3927 also has complicated rules involving when one can or should not
> >>use a link-local address on the same interface as a routable IP, so at
> >>best your configuration may not be supported anyway. One should not use
> >>a link-local address as if it were under RFC 1918 rules, in particular
> >>because link-local involves self-assigned addresses and internal
> >>conflict mitigation.
> >>
> >Again what happened we had a box in the field that was running 4.9 being
> >used as a router/nat/vpn/firewall device. It was handing out ip addresses
> >to the internal lan using the range 169.254.202.0/24, who knows why this
> >address range was picked. It worked great but
> >the hardware died, so we were replacing it with our current SW which is
> >based on 6.3 we duplicated the configuration and have been struggling
> >trying to
> >get it to work for the customer since Saturday with no luck. Today I
> >finally
> >tried to ping the internal address from the box itself and it wouldn't
> >ping,
> >so I started trying using other addresses on the internal interface and
> >they
> >worked but not 169.254.202.1. In googling I discovered that 169.254/16
> >was supposed to be assigned if a box couldn't obtain an ip but saw
> >nothing about
> >an OS dropping them.
> >
> >So anyway I know the reason behind the change now.
> >
> One final comment - I still don't understand why FreeBSD "won't" respond to 
> pings
> when it has an address like 169.254.1.1. I can ssh to the unit but it won't
> respond to pings. I tried setting up a linux box with an address like
> 169.254.1.2 and it "would" respond to pings.

I tried to explain it as best as I could here:
http://lists.freebsd.org/pipermail/freebsd-stable/2010-June/057191.html

The IP stack (not a firewall, etc.) is basically blackholing the packet.

-- 
| Jeremy Chadwick   j...@parodius.com |
| Parodius Networking   http://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 "freebsd-stable-unsubscr...@freebsd.org"


Re: FreeBSD eats 169.254.x.x addressed packets

2010-06-09 Thread Reko Turja
One final comment - I still don't understand why FreeBSD "won't" 
respond to pings
when it has an address like 169.254.1.1. I can ssh to the unit but 
it won't
respond to pings. I tried setting up a linux box with an address 
like

169.254.1.2 and it "would" respond to pings.


Linux is not really any measuring stick in standard compliance...

-Reko 


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


Re: Dell PowerEdge Virtual Media

2010-06-09 Thread Steve Polyack

On 12/08/09 12:41, Jeff Blank wrote:

Hi,

I'm having a little trouble using the "virtual media" function of
Dell's PowerEdge R-series (R710 in this case) iDRAC6 under FreeBSD
(7.1, 8.0).  This is presented as /dev/cd0, a USB/"SCSI" device, I
guess.  This is in the dmesg buffer when I boot up the existing 7.1
installation with the virtual optical drive mapped to the 8.0-RELEASE
amd64 DVD image:
   
We're having some similar issues with our older PowerEdge 1850s 
(DRAC4).  Things were alright on 6.3-RELEASE, but now there is a large 
hangup when trying to install 8.0-RELEASE:


We see ~ 30x of these in dmesg:
  acd1: WARNING - READ_TOC read data overrun 20>12

Followed by this in sysinstall:
  "The disc in your drive looks more like an audio disc than a
  FreeBSD Release" (1).

The DRAC Virtual Media and physical CDROM drives are probed like this in 
dmesg:

acd1: DVR  at ata2-slave PIO3
acd0: CDROM 

This is with the latest DRAC firmware available from Dell.

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


Re: FreeBSD eats 169.254.x.x addressed packets

2010-06-09 Thread Stephen Clark

On 06/09/2010 08:28 AM, Reko Turja wrote:

One final comment - I still don't understand why FreeBSD "won't"
respond to pings
when it has an address like 169.254.1.1. I can ssh to the unit but it
won't
respond to pings. I tried setting up a linux box with an address like
169.254.1.2 and it "would" respond to pings.


Linux is not really any measuring stick in standard compliance...

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


But reading the RFC it says the packets should not be routed - I don't see
where it says that pings should not be responded to. Think about it
the RFC was for link local devices - shouldn't on device on a link be
able to ping another device and get a response.

--

"They that give up essential liberty to obtain temporary safety,
deserve neither liberty nor safety."  (Ben Franklin)

"The course of history shows that as a government grows, liberty
decreases."  (Thomas Jefferson)


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


Re: FreeBSD eats 169.254.x.x addressed packets

2010-06-09 Thread jhell
On 06/09/2010 08:28, Reko Turja wrote:
>> One final comment - I still don't understand why FreeBSD "won't"
>> respond to pings
>> when it has an address like 169.254.1.1. I can ssh to the unit but it
>> won't
>> respond to pings. I tried setting up a linux box with an address like
>> 169.254.1.2 and it "would" respond to pings.
> 
> Linux is not really any measuring stick in standard compliance...
> 

I do not believe that is what he was implying by comparing this to
Linux.  I think he might be using Linux as a example of "They have not
limited their users to only changing source code" to get the objective
completed. They should have.

In this case and reviewing the previous messages + remembering these:

http://bit.ly/9sigji

http://bit.ly/9pfE9A

http://bit.ly/9CNT3K

FreeBSD takes the correct action for this scenario which could proudly
be used as an exemplary piece of code that other forms of OS's should
use as a reference for integrity.  http://bit.ly/byHBzN


Regards,

-- 

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


Re: FreeBSD eats 169.254.x.x addressed packets

2010-06-09 Thread sthaug
> > One final comment - I still don't understand why FreeBSD "won't" 
> > respond to pings
> > when it has an address like 169.254.1.1. I can ssh to the unit but 
> > it won't
> > respond to pings. I tried setting up a linux box with an address 
> > like
> > 169.254.1.2 and it "would" respond to pings.
> 
> Linux is not really any measuring stick in standard compliance...

If 169.254.0.0/16 addresses are supposed to be link local then I'd
definitely expect a reply to a ping from another box on the same
LAN, sourced from another 169.254.0.0/16 address.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


(no subject)

2010-06-09 Thread Thorsten Baumeister
Hi everyone!
I have a problem to get my KDE4 Terminal working. I use a German keyboard, and 
I am not able to use some special keys. Especially I miss the pipe symbol 
('|'), but there are some more like '§', '@', '€'. I compiled KDE on my own 
computer running a FreeBSD 8.0-STABLE kernel. All packages are up to date. Any 
hints? If I use an SSH connection (PuTTY), everything is fine.

Thorsten Baumeister
-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: (no subject)

2010-06-09 Thread Christian Walther
Hi Thorsten,

On 9 June 2010 18:11, Thorsten Baumeister  wrote:
> Hi everyone!
> I have a problem to get my KDE4 Terminal working. I use a German keyboard, 
> and I am not able to use some special keys. Especially I miss the pipe symbol 
> ('|'), but there are some more like '§', '@', '€'. I compiled KDE on my own 
> computer running a FreeBSD 8.0-STABLE kernel. All packages are up to date. 
> Any hints? If I use an SSH connection (PuTTY), everything is fine.

I created a /etc/X11/xorg.conf file using

# X -configure

and added/changed the following section:

Section "InputDevice"
Identifier "Keyboard0"
Driver "keyboard"
Option "XkbModel" "pc105"
Option "XkbLayout" "de"
Option "XkbVariant" "nodeadkeys"
Option "XkbOptions" "terminate:ctrl_alt_bksp"
EndSection

The last Option line isn't necessary, but it makes it possible to
terminate the X server by pressing Ctrl+Alt+Backspace, which has been
deactivated in recent default configurations.

If you add the above mentioned Section "InputDevice", make sure that
the Section "ServerLayout" contains a CoreKeyboard entry matching the
given identifier. In my case, Section "ServerLayout" looks like:

Section "ServerLayout"
Identifier "XFree86 Configured"
Screen  0  "Screen0" 0 0
InputDevice"Mouse0" "CorePointer"
InputDevice"Keyboard0" "CoreKeyboard"
Option "Clone" "off"
EndSection


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


Re: Resizing GPT partitions

2010-06-09 Thread Andrey V. Elsukov
Stephane Dupille wrote:
> I dumped this disk image to a real machine, which has a 160 Go disk.
> The system works fine, but I can only use 10 Go of disk space. How can
> I gain more space ?
> 
> How can I enlarge the last partition of the disk to use the whole disk ?
> 
> I tried to create a new partition on the disk, and planned to add it
> in the zfs pool, but that didn't work :
> # gpart add -t freebsd-zfs -l disk0f ad0
> gpart: autofill: No space left on device
> 
> That's odd, because it seems that gpart is aware of the new geometry.

Currently there is no easy way to do it. GPT holds information about
first and last usable sectors. You can see them in your output:

> last: 20971486
> first: 34

You can look at freebsd-geom's mail list archive. There was a topic
"OCE and GPT" with similar problem.

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature


Re: Dell PowerEdge Virtual Media

2010-06-09 Thread Steven Hartland

Try 8.1 to see if that helps, did here :)
- Original Message - 
From: "Steve Polyack" 


We're having some similar issues with our older PowerEdge 1850s 
(DRAC4).  Things were alright on 6.3-RELEASE, but now there is a large 
hangup when trying to install 8.0-RELEASE:


We see ~ 30x of these in dmesg:
  acd1: WARNING - READ_TOC read data overrun 20>12

Followed by this in sysinstall:
  "The disc in your drive looks more like an audio disc than a
  FreeBSD Release" (1).

The DRAC Virtual Media and physical CDROM drives are probed like this in 
dmesg:

acd1: DVR  at ata2-slave PIO3
acd0: CDROM 

This is with the latest DRAC firmware available from Dell.

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




This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. 


In the event of misdirection, illegible or incomplete transmission please 
telephone +44 845 868 1337
or return the E.mail to postmas...@multiplay.co.uk.

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


Re: FreeBSD eats 169.254.x.x addressed packets

2010-06-09 Thread sthaug
> > > One final comment - I still don't understand why FreeBSD "won't" 
> > > respond to pings
> > > when it has an address like 169.254.1.1. I can ssh to the unit but 
> > > it won't
> > > respond to pings. I tried setting up a linux box with an address 
> > > like
> > > 169.254.1.2 and it "would" respond to pings.
> > 
> > Linux is not really any measuring stick in standard compliance...
> 
> If 169.254.0.0/16 addresses are supposed to be link local then I'd
> definitely expect a reply to a ping from another box on the same
> LAN, sourced from another 169.254.0.0/16 address.

Having tested this in the lab I'd say FreeBSD 7.x works exactly as
expected. Traffic on the same LAN works, traffic to other LANs is
not routed. All is well.

Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: netstat output changes in 8.0?

2010-06-09 Thread Nick Rogers
On Tue, Jan 26, 2010 at 12:49 PM, Nick Rogers  wrote:

> Thanks a lot. Thats a bummer. What are the chances of getting something
> like that worked into arp(8) permanently?
>
>
I recently noticed that arp(8) was changed a few months back to show when an
entry expires. Thanks!

http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/arp/arp.c?rev=1.75
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: arp -na performance w/ many permanent entries

2010-06-09 Thread Nick Rogers
On Sun, Jun 6, 2010 at 4:23 PM, Nick Rogers  wrote:

>
>
> On Sat, Jun 5, 2010 at 11:54 PM, Garrett Cooper wrote:
>>
>>
>> I agree with Jeremy. I think that the problem that you've
>> discovered is the fact that it's using stdio-based buffered output
>> instead of buffering more of the contents in a string and punting it
>> out in larger chunks.
>> HTH,
>> -Garrett
>>
>
> I don't think so. The performance difference when taking out the interface
> lookup is huge even though the data output to STDOUT is mostly the same.
> I'll try the other lists, thanks.
>
>
FYI there is a bugfix/patch for this issue being discussed in
freebsd-hackers:

http://www.mail-archive.com/freebsd-hack...@freebsd.org/msg157097.html

Thanks again for suggesting I try another list.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"