Re: cdrtools /devel and wodim broken
Andriy Gapon wrote: > > on 16/10/2010 20:21 Jakub Lach said the following: >> No, I don't use hal. Since when it's requirement? > > Hm, why did you decide that it is a requirement? > I just asked a question, and thanks for the answer. > I thought this was that "stupid mistake" on my part. Sorry for confusion. Yes, wodim is based on earlier cdrecord branch, that's why I checked it too, problems started after cdrtools got updated, but I wanted to rule it out as coincidence, because I just rarely burn cd/dvds. BTW, it is in ports, /usr/ports/sysutils/cdrkit/. best regards, - Jakub Lach -- View this message in context: http://old.nabble.com/cdrtools--devel-and-wodim-broken-tp29978939p29983168.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
ZFS WARNING: Cannot open ad4s3d for writting; how do I clear it?
Hi, I have running FreeBSD 7.1-RELEASE-p14. I had had a ZFS partition as one of data area on a system and replicated a system using dump/restore. On the replicated system, I don't use ZFS and ad4s3d is mounted as /usr. I get "ZFS WARNING: Cannot open ad4s3d for writting." each time I run "zfs import" on relicated system. How can I clear this meta-data information ZFS carries? Thanks, Hiro ___ 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"
ifconfig, vnets and interface names
Hello, While playing with vnet jails I've discovered the following oddity, which probably is not what's expected to happen : First I'm creating two epair(4) interfaces : [16:51]r...@nas:/home/ndenev# ifconfig epair0 create epair0a [16:51]r...@nas:/home/ndenev# ifconfig epair1 create epair1a Then I'm creating two vnet jails : [16:51]r...@nas:/home/ndenev# jail -c vnet name=test1 host.hostname=test1 path=/ persist [16:51]r...@nas:/home/ndenev# jail -c vnet name=test2 host.hostname=test2 path=/ persist Now push one side of the epairs to each vnet : [16:51]r...@nas:/home/ndenev# ifconfig epair0b vnet test1 [16:52]r...@nas:/home/ndenev# ifconfig epair1b vnet test2 Rename the interfaces in the vnet jails : [16:52]r...@nas:/home/ndenev# jexec test1 ifconfig epair0b name eth0 [16:52]r...@nas:/home/ndenev# jexec test2 ifconfig epair1b name eth0 And now I'm destroying the vnets, so all of the interfaces are "reclaimed" by the host : [16:52]r...@nas:/home/ndenev# jail -r test1 [16:52]r...@nas:/home/ndenev# jail -r test2 And that's what ifconfig shows after this : [16:52]r...@nas:/home/ndenev# ifconfig <... snip lo0 and physical interface ...> epair0a: flags=8842 metric 0 mtu 1500 ether 02:8c:53:00:03:0a epair1a: flags=8842 metric 0 mtu 1500 ether 02:b6:49:00:05:0a eth0: flags=8842 metric 0 mtu 1500 ether 02:8c:53:00:04:0b ether 02:b6:49:00:06:0b Instead of two interfaces, I'm seeing one with to lladdrs, because of the interface names being the same. Then I'm trying to destroy them : [16:52]r...@nas:/home/ndenev# ifconfig eth0 destroy [16:53]r...@nas:/home/ndenev# ifconfig <... snip lo0 and physical interface ...> epair1a: flags=8842 metric 0 mtu 1500 ether 02:b6:49:00:05:0a eth0: flags=8842 metric 0 mtu 1500 ether 02:b6:49:00:06:0b [16:53]r...@nas:/home/ndenev# ifconfig eth0 destroy So in this case there may be not a clean way to address one of the interfaces specifically (i.e. destroy only the second one)? I've not investigated further, but I'm thinking probably this is just a "bug" in ifconfig interpreting/parsing the information from the kernel. Maybe a solution is to extend ifconfig to be able print the interface list along with the ifIndex values and also manage the interfaces by index? Auto renaming also is also probably a possible solution (i.e. eth0_1 , eth0_2 ) as these are interfaces coming from destroyed vnet's and are not likely to be in use. (but still sounds scary :) ) Regards, Nikolay___ 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: ifconfig, vnets and interface names
On Sun, 17 Oct 2010, Nikolay Denev wrote: Hello, While playing with vnet jails I've discovered the following oddity, which probably is not what's expected to happen : ... And that's what ifconfig shows after this : [16:52]r...@nas:/home/ndenev# ifconfig <... snip lo0 and physical interface ...> epair0a: flags=8842 metric 0 mtu 1500 ether 02:8c:53:00:03:0a epair1a: flags=8842 metric 0 mtu 1500 ether 02:b6:49:00:05:0a eth0: flags=8842 metric 0 mtu 1500 ether 02:8c:53:00:04:0b ether 02:b6:49:00:06:0b Instead of two interfaces, I'm seeing one with to lladdrs, because of the interface names being the same. Then I'm trying to destroy them : [16:52]r...@nas:/home/ndenev# ifconfig eth0 destroy [16:53]r...@nas:/home/ndenev# ifconfig <... snip lo0 and physical interface ...> epair1a: flags=8842 metric 0 mtu 1500 ether 02:b6:49:00:05:0a eth0: flags=8842 metric 0 mtu 1500 ether 02:b6:49:00:06:0b [16:53]r...@nas:/home/ndenev# ifconfig eth0 destroy So in this case there may be not a clean way to address one of the interfaces specifically (i.e. destroy only the second one)? I've not investigated further, but I'm thinking probably this is just a "bug" in ifconfig interpreting/parsing the information from the kernel. Maybe a solution is to extend ifconfig to be able print the interface list along with the ifIndex values and also manage the interfaces by index? Auto renaming also is also probably a possible solution (i.e. eth0_1 , eth0_2 ) as these are interfaces coming from destroyed vnet's and are not likely to be in use. (but still sounds scary :) ) It's actually a bug in sys/net/if.c:if_vmove* we know about and that's on the todo list. I am not sure when the behaviour of ifconfig changed as previousy it would only show you one of the two interfaces with the single ether address. ifconfig -l however had shown eth0 twice. Neither is really what one would expect thus needs changing. /bz PS: freebsd-virtualization@ is the best list to report "VIMAGE" or "vnet" related problems. -- Bjoern A. Zeeb Welcome a new stage of life. ___ 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: ifconfig, vnets and interface names
On Oct 17, 2010, at 7:17 PM, Bjoern A. Zeeb wrote: > On Sun, 17 Oct 2010, Nikolay Denev wrote: > >> [ ... snip ... ] > > It's actually a bug in sys/net/if.c:if_vmove* we know about and that's > on the todo list. > Thanks, good to know. > I am not sure when the behaviour of ifconfig changed as previousy it > would only show you one of the two interfaces with the single ether > address. ifconfig -l however had shown eth0 twice. Neither is really > what one would expect thus needs changing. > > /bz > > PS: freebsd-virtualization@ is the best list to report "VIMAGE" or > "vnet" related problems. > Ok, I'll keep that in mind. > -- > Bjoern A. Zeeb Welcome a new stage of life. Regards, Nikolay ___ 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 8.1 + xorg + radeonhd hang
On Sat, 16 Oct 2010, Jim Pingle wrote: Not meaning to resurrect a month-old thread but I'm a bit behind on my list mail. I just thought I'd pass long that I had problems in the past with my older Radeon when using a VGA to DVI connector. Using either a normal VGA port, or a DVI cable on the DVI port worked fine. http://lists.freebsd.org/pipermail/freebsd-x11/2007-September/005251.html That may have had something to do with the problem, but my card only had two dvi ports and one s-video. There's no vga port so I couldn't move it. Thanks for the information though. I may try using the card again if something turns up. -- _ _ // \\// Eivind Evensen \/ ___ 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: kpanic on install >32GB of RAM
> We've successfully installed RHEL 5u4 on it, I'll fire that up and post > the boot output shortly. > > Sean Perhaps this is something as simple as a hardware failure? HP DL980 looks sick, but I'm not sure. Here's the hardware logs, from the iLO on the box as screen scraping on the console is pointless as it's garbled too badly. Bad CPU, Bad Ram or other? http://people.freebsd.org/~sbruno/dl980_Machcheck_exceptions.png Sean ___ 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: out of HDD space - zfs degraded
On 10/4/2010 7:19 AM, Alexander Leidinger wrote: Quoting Dan Langille (from Sun, 03 Oct 2010 08:08:19 -0400): Overnight, the following appeared in /var/log/messages: Oct 2 21:56:46 kraken root: ZFS: checksum mismatch, zpool=storage path=/dev/gpt/disk06-live offset=123103157760 size=1024 Oct 2 21:56:47 kraken root: ZFS: checksum mismatch, zpool=storage path=/dev/gpt/disk06-live offset=123103159808 size=1024 [...] Given the outage from yesterday when ada0 was offline for several hours, I'm guessing that checksum mismatches on that drive are expected. Yes, /dev/gpt/disk06-live == ada0. If you have the possibility to run a scrub of the pool, there should be no additional checksum errors accouring *after* the scrub is *finished*. If checksum errors still appear on this disk after the scrub is finished, you should have a look at the hardware (cable/disk) and take appropriate replacement actions. For the record, there have been no further checksum errors. :) -- Dan Langille - http://langille.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Reproducible Kernel Panic on 8.1-STABLE [SEC=UNCLASSIFIED]
0n Fri, Oct 15, 2010 at 04:27:51PM +0200, Ivan Voras wrote: >On 10/15/10 03:43, Wilkinson, Alex wrote: >> >> 0n Thu, Oct 14, 2010 at 04:51:10PM +0800, Wilkinson, Alex wrote: >> >> > 0n Thu, Oct 14, 2010 at 02:13:27PM +0600, Sergey Nikolenko wrote: >> > >> > >On 14.10.2010 09:26, Wilkinson, Alex wrote: >> > >> I have come across a bug that triggers a kernel panic on 8.1-STABLE(r213395) through the >> > >> use of /usr/ports/sysutils/fusefs-sshfs. Typically i do an sshfs mount as such: >> > >> >> > >> #sshfs usern...@hostname:/home/username local_mountpoint/ >> > >> >> > >> This mounts the remote filesystem fine. However, when i edit and save a file in >> > >> say vi on the remote sshfs i get the following panic everytime: >> > > >> > >Try this out >> > >http://www.freebsd.org/cgi/query-pr.cgi?pr=149674 >> > >> >Yes! GREAT! This patch fixes the kernel panic! Can we get this committed ASAP ? >> >> Committed! > >How stable is fuse & sshfs lately? It looks like every time in the past >I tried it I soon ended up panicking the system. since this patch it has been very stable so far! -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ 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"
