I just merged a change from current to libstand which increases the number
of open file descriptors. This could be what was causing your problems.
Can you test it out with the latest RELENG_7?
On Sun, Jun 14, 2009 at 7:08 PM, Dan Allen danalle...@airwired.net wrote:
On 14 Jun 2009, at 5:08
On Sunday 14 June 2009 7:08:50 pm Daniel Eischen wrote:
On Sun, 14 Jun 2009, Dan Allen wrote:
On 14 Jun 2009, at 1:27 AM, Daniel Eischen wrote:
From one of your older emails, you mention you are using
ad0s2a as / and ad0s2b as swap, and then say that ad0s2c
is unused (I may have the
On 2009-Jun-13 17:56:49 -0600, Dan Allen danalle...@airwired.net wrote:
How do I get to the old loader when the machine boots and immediately
stops? There is no ability at this point in the boot process to try
and get to the old loader that I know of. Is there a hidden magic key
On Sat, 13 Jun 2009, Dan Allen wrote:
How do I get to the old loader when the machine boots and immediately stops?
There is no ability at this point in the boot process to try and get to the
old loader that I know of. Is there a hidden magic key combination that
allows this?
You are correct
On Sat, 13 Jun 2009 19:56 -, danallen46 wrote:
On 13 Jun 2009, at 5:42 PM, Paul B. Mahol wrote:
On 6/13/09, Dan Allen danalle...@airwired.net wrote:
I have now proven that the recent post June 8th version of
/usr/src/sys/boot/i386/loader/Makefile
causes catastrophic data loss.
On 14 Jun 2009, at 10:38 AM, CmdLnKid wrote:
Is it possible that you have most likely been playing around with ZFS
before this and left some of the configurations of ZFS embedded in
your
drive and the loader is picking that up.
No, I have never used ZFS.
The drive is partitioned and the
On 14 Jun 2009, at 1:27 AM, Daniel Eischen wrote:
From one of your older emails, you mention you are using
ad0s2a as / and ad0s2b as swap, and then say that ad0s2c
is unused (I may have the ad0s2 part wrong). But ad0s2c
should be the entire slice (or partition depending on
the wording you are
On Sun, 14 Jun 2009, Dan Allen wrote:
On 14 Jun 2009, at 1:27 AM, Daniel Eischen wrote:
From one of your older emails, you mention you are using
ad0s2a as / and ad0s2b as swap, and then say that ad0s2c
is unused (I may have the ad0s2 part wrong). But ad0s2c
should be the entire slice (or
On 14 Jun 2009, at 5:08 PM, Daniel Eischen wrote:
On Sun, 14 Jun 2009, Dan Allen wrote:
# /dev/ad0s2:
8 partitions:
#size offsetfstype [fsize bsize bps/cpg]
a: 43591708 20971524.2BSD0 0 0
b: 20971520 swap
c: 456888600unused
I have now proven that the recent post June 8th version of
/usr/src/sys/boot/i386/loader/Makefile
causes catastrophic data loss.
Why on earth would this change not be immediately rolled back out of
the STABLE branch? For those on the bleeding edge with CURRENT they
expect to lose
On Sat, Jun 13, 2009 at 1:53 PM, Dan Allendanalle...@airwired.net wrote:
I have now proven that the recent post June 8th version of
/usr/src/sys/boot/i386/loader/Makefile
causes catastrophic data loss.
Then it should be disabled by default until the problem is fixed.
Why on earth
On 6/13/09, Dan Allen danalle...@airwired.net wrote:
I have now proven that the recent post June 8th version of
/usr/src/sys/boot/i386/loader/Makefile
causes catastrophic data loss.
Why on earth would this change not be immediately rolled back out of
the STABLE branch? For those on
On 13 Jun 2009, at 5:42 PM, Paul B. Mahol wrote:
On 6/13/09, Dan Allen danalle...@airwired.net wrote:
I have now proven that the recent post June 8th version of
/usr/src/sys/boot/i386/loader/Makefile
causes catastrophic data loss.
I hardly doubt that such change cause loss of
13 matches
Mail list logo
