hail,
as recently had issues in this regard, to install it can I just use
http://www.freebsd.org/doc/handbook/desktop-browsers.html or there is
another guide ?
I looked for and found nothing on wiki.freebsd.org.
thanks,
matheus
--
We will call you cygnus,
The God of balance you shall be
A: B
Hi,
I have found that the dtrace command on FreeBSD, in both STABLE and HEAD, does
not print out
aggregations properly, likely due to the difference in how Solaris and FreeBSD
signals work.
For example, this one liner will give no output:
sudo dtrace -n 'syscall:::entry { @[execname] = quantize
Hi,
please create a PR and send followups to freebsd-wirel...@freebsd.org .
Adrian
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@fre
In case anyone wants to take this on, this port fails to install on 10.0
because it uses its own version of libtool. I took a quick look but
there wasn't a solution obvious enough for me. :)
Doug
On 10/07/2011 09:15, Hajimu UMEMOTO wrote:
> ume 2011-10-07 16:15:47 UTC
>
> FreeBSD por
On Sat, 8 Oct 2011 02:03:37 +0300
Mykola Dzham mentioned:
> Hi!
> r226027 fix ( ... s/freebsd1\*)/SHOULDNOTMATCHANYTHING1)/ ...) is
> incorrect: this commit breaks metaports building:
>
> # cd /usr/ports/print/teTeX && sudo make clean all
> ===> Cleaning for teTeX-3.0_5
> ===> License check di
On Sat, 8 Oct 2011, Andrey V. Elsukov wrote:
On 07.10.2011 23:41, Glen Barber wrote:
In my experience, without kern.geom.debugflags=16, the MBR will not be
written to the memstick, leaving you with what would effectively be a
coaster in the not-so-distant past.
The problem is that this bad su
Hi!
r226027 fix ( ... s/freebsd1\*)/SHOULDNOTMATCHANYTHING1)/ ...) is
incorrect: this commit breaks metaports building:
# cd /usr/ports/print/teTeX && sudo make clean all
===> Cleaning for teTeX-3.0_5
===> License check disabled, port has not defined LICENSE
===> Found saved configuration for t
On Fri, 7 Oct 2011, Poul-Henning Kamp wrote:
In message , Warren Block
writes:
Followed by removing the memory stick without unmounting it to avoid
overwriting part of the image. No obvious problems, but no, it's not
polite. (I'm thinking "automounter" here.)
And you are sure the stick no
On 10/7/11 5:10 PM, Warren Block wrote:
>> Me not being one that uses hald or devd for USB, I'm certain the device
>> was not mounted when writing the memstick image. In the former case of
>> your test, is the USB stick bootable?
>
> I cleared the first 34 blocks and wrote it again to make sure,
Hi,
On Fri, Oct 7, 2011 at 5:10 PM, Poul-Henning Kamp wrote:
> In message , Warren Block
> write
> s:
>
>># mount /dev/da0p2 /mnt
>># dd if=/tmp/FreeBSD-9.0-BETA3-amd64-memstick.img of=/dev/da0 bs=64k
>>dd: /dev/da0: Operation not permitted
>># sysctl kern.geom.debugflags=16
>>kern.geom.debugfla
In message , Warren Block write
s:
># mount /dev/da0p2 /mnt
># dd if=/tmp/FreeBSD-9.0-BETA3-amd64-memstick.img of=/dev/da0 bs=64k
>dd: /dev/da0: Operation not permitted
># sysctl kern.geom.debugflags=16
>kern.geom.debugflags: 0 -> 16
># dd if=/tmp/FreeBSD-9.0-BETA3-amd64-memstick.img of=/dev/da0 b
On Fri, 7 Oct 2011, Glen Barber wrote:
On 10/7/11 4:27 PM, Warren Block wrote:
In my experience, without kern.geom.debugflags=16, the MBR will not be
written to the memstick, leaving you with what would effectively be a
coaster in the not-so-distant past.
Tried it just now with the 9.0-BETA3
2011/10/7 Daniel Kalchev :
> Then, "by standard" GPT cannot coexist with GLABEL. Such setup should be
> disallowed, or at least big nasty message that you have just shoot yourself
> in the leg should be output. (period)
GPT cannot coexist with ANY GEOM CLASS which writes metadata to the last sect
Hi,
On Fri, Oct 7, 2011 at 4:27 PM, Warren Block wrote:
> On Fri, 7 Oct 2011, Glen Barber wrote:
>
>> Hi,
>>
>> On 10/7/11 3:18 PM, Poul-Henning Kamp wrote:
My guess is that GEOM isn't letting go of the GPT table and you have
multiple partitions in the GPT table and you're not dest
On 10/7/11 4:27 PM, Warren Block wrote:
>> In my experience, without kern.geom.debugflags=16, the MBR will not be
>> written to the memstick, leaving you with what would effectively be a
>> coaster in the not-so-distant past.
>
> Tried it just now with the 9.0-BETA3 memstick image.
>
[...]
>
>
On Fri, 7 Oct 2011, Glen Barber wrote:
Hi,
On 10/7/11 3:18 PM, Poul-Henning Kamp wrote:
My guess is that GEOM isn't letting go of the GPT table and you have
multiple partitions in the GPT table and you're not destroying them
hierarchically in a proper manner.. but again, that's just a guess
ba
On 07.10.11 22:44, Lev Serebryakov wrote:
Hello, Perryh.
You wrote 7 октября 2011 г., 18:06:38:
GPT (and MBR) metadata placement is dictated from outside world,
where is no GEOM and geom_label. They INTENDED to be used on DISKS.
BIOSes should be able to find it :)
Certainly GPT and MBR mu
On 07.10.2011 23:41, Glen Barber wrote:
> In my experience, without kern.geom.debugflags=16, the MBR will not be
> written to the memstick, leaving you with what would effectively be a
> coaster in the not-so-distant past.
The problem is that this bad suggestion is everywhere in the Internet.
And
Hello, Perryh.
You wrote 7 октября 2011 г., 18:06:38:
>> GPT (and MBR) metadata placement is dictated from outside world,
>> where is no GEOM and geom_label. They INTENDED to be used on DISKS.
>> BIOSes should be able to find it :)
> Certainly GPT and MBR must place an instance of the partition
Hi,
On 10/7/11 3:18 PM, Poul-Henning Kamp wrote:
>> My guess is that GEOM isn't letting go of the GPT table and you have
>> multiple partitions in the GPT table and you're not destroying them
>> hierarchically in a proper manner.. but again, that's just a guess
>> based on hazy recollection.
>
>
On 07.10.2011 22:53, Warren Block wrote:
> The current documentation is
>
> sysctl kern.geom.debugflags=16
> dd if=memstick.img of=/dev/whatever0 bs=64k
Did you try just write your image without debugflags settings?
When /dev/whatever0 is not used nothing should prevent you write
your image.
In message
, Garrett Cooper writes:
>My guess is that GEOM isn't letting go of the GPT table and you have
>multiple partitions in the GPT table and you're not destroying them
>hierarchically in a proper manner.. but again, that's just a guess
>based on hazy recollection.
If none of the GPT parti
On Fri, Oct 7, 2011 at 12:03 PM, Poul-Henning Kamp wrote:
> In message , Warren Block
> write
> s:
>
> Which is the exactly right question to ask.
>
> The procedure documented is clearly flawed.
>>
>>Well, yes. The goal is to unprotect the device, regardless of what may
>>alread
In message , Warren Block write
s:
Which is the exactly right question to ask.
The procedure documented is clearly flawed.
>>>
>
>Well, yes. The goal is to unprotect the device, regardless of what may
>already be on it. Then the user can overwrite it with the memory stick
>image
On Fri, 7 Oct 2011, Warren Block wrote:
On Fri, 7 Oct 2011, Arnaud Lacombe wrote:
Hi,
On Fri, Oct 7, 2011 at 2:13 PM, Warren Block wrote:
On Fri, 7 Oct 2011, Poul-Henning Kamp wrote:
In message , Benjamin
Kaduk
writes:
Now, an ordinary user who is
doing this for the first time might ask
On Fri, 7 Oct 2011, Arnaud Lacombe wrote:
Hi,
On Fri, Oct 7, 2011 at 2:13 PM, Warren Block wrote:
On Fri, 7 Oct 2011, Poul-Henning Kamp wrote:
In message , Benjamin
Kaduk
writes:
Now, an ordinary user who is
doing this for the first time might ask, "why do I need to do something
with 'deb
Hi,
On Fri, Oct 7, 2011 at 2:13 PM, Warren Block wrote:
> On Fri, 7 Oct 2011, Poul-Henning Kamp wrote:
>
>> In message , Benjamin
>> Kaduk
>> writes:
>>
>>> Now, an ordinary user who is
>>> doing this for the first time might ask, "why do I need to do something
>>> with 'debugflags' in order to m
On Fri, 7 Oct 2011, Poul-Henning Kamp wrote:
In message , Benjamin Kaduk
writes:
Now, an ordinary user who is
doing this for the first time might ask, "why do I need to do something
with 'debugflags' in order to make a USB stick?
Which is the exactly right question to ask.
The procedure doc
In message , Benjamin Kaduk
writes:
>Now, an ordinary user who is
>doing this for the first time might ask, "why do I need to do something
>with 'debugflags' in order to make a USB stick?
Which is the exactly right question to ask.
The procedure documented is clearly flawed.
--
Poul-Hennin
On Fri, 7 Oct 2011, Garrett Cooper wrote:
On Fri, Oct 7, 2011 at 10:42 AM, Benjamin Kaduk wrote:
Dear all,
I feel like this has come up before, but a quick search didn't reveal
anything terribly recent, at least.
The new installation chapter of the handbook for 9.0 (that Warren and Glen
and
On Fri, Oct 7, 2011 at 10:42 AM, Benjamin Kaduk wrote:
> Dear all,
>
> I feel like this has come up before, but a quick search didn't reveal
> anything terribly recent, at least.
>
> The new installation chapter of the handbook for 9.0 (that Warren and Glen
> and Garrett and Gavin and more people
Dear all,
I feel like this has come up before, but a quick search didn't reveal
anything terribly recent, at least.
The new installation chapter of the handbook for 9.0 (that Warren and Glen
and Garrett and Gavin and more people I am probably missing have sunk huge
amounts of time into) has
On 10/07/11 12:26, Rene Ladan wrote:
Hi,
just experienced a panic with if_iwn on 9.0-BETA3-amd64 (base and
kernel compiled with clang, CPUTYPE?=core2, GENERIC with CAPABILITIES).
My network card: iwn0: mem
0xf520-0xf5201fff irq 17 at device 0.0 on pci3
iwn0: flags=8803 metric 0 mtu 2290
han
just an LF as in UNIX). If you'd like, I can try to come up to speed on
the code and help to debug, but I do not use X and so have no experience
with its default terminal emulator; I'd have to study that as well.
--Brett Glass
At 06:25 AM 10/7/2011, Ed Schouten wrote:
* Ed Schoute
At 05:02 AM 10/7/2011, Ed Schouten wrote:
>It should be xterm, since syscons now uses an xterm-style terminal
>emulator.
Interesting. Apparently, the xterm termcap does not work properly for it.
>I have never used jove before, so what should I do to
>reproduce this?
Have you ever used EMACS?
Lev Serebryakov wrote:
> GPT (and MBR) metadata placement is dictated from outside world,
> where is no GEOM and geom_label. They INTENDED to be used on DISKS.
> BIOSes should be able to find it :)
Certainly GPT and MBR must place an instance of the partition table
where the BIOS expects it, b
Hi Brett,
* Brett Glass , 20111007 15:40:
> The patch is an improvement. Not assuming that tabs blank the underlying
> cells is definitely a help. But it does not fix all of the artifacts.
Just let me know what's broken specifically. So what keys to press when
I start jove to reprod
Hi Brett,
* Brett Glass , 20111007 15:18:
> Among other things, you'll see portions of lines vanish from the
> screen while you're editing, until you hit ^L (the EMACS command to
> refresh the screen) a couple of times.
Yeah, that should be fixed now. I just ran `jove /e
* Ed Schouten , 20111007 13:02:
> It should be xterm, since syscons now uses an xterm-style terminal
> emulator. I have never used jove before, so what should I do to
> reproduce this?
After some tinkering, I think I know why it breaks. I thought that
when xterm processes a tab, it b
* Brett Glass , 20110926 02:52:
> 1) The jove editor worked strangely because, in /etc/ttys, the
> terminal type was set to "xterm" instead of "cons25" by default. (I
> do not run a GUI on servers, so of course there will not be an
> xterm.) As a result, parts of lines kept vanishing from under my
Hi,
just experienced a panic with if_iwn on 9.0-BETA3-amd64 (base and
kernel compiled with clang, CPUTYPE?=core2, GENERIC with CAPABILITIES).
My network card: iwn0: mem
0xf520-0xf5201fff irq 17 at device 0.0 on pci3
iwn0: flags=8803 metric 0 mtu 2290
ether 00:26:c6:xx:xx:xx
On Fri, Sep 30, 2011 at 2:12 PM, Jaakko Heinonen wrote:
>
> Looks mostly OK to me.
>
>
> Why do you use printf() + exit() here and errx() in atacontrol? Is there
> reason to not use errx() also here?
>
>
> errx(3) adds a newline character to the output. Thus the latter '\n' is
> redundant.
>
> bur
Hello, Perryh.
You wrote 7 октября 2011 г., 18:06:38:
>> GPT (and MBR) metadata placement is dictated from outside world,
>> where is no GEOM and geom_label. They INTENDED to be used on DISKS.
>> BIOSes should be able to find it :)
> Certainly GPT and MBR must place an instance of the partition
43 matches
Mail list logo
