Chad David <[EMAIL PROTECTED]> writes:
> My company built a tool a few years back for creating a bootable cdrom
> based on a running host FreeBSD 3/4 system, which promptly got shelved and
> forgotten.I recently had to update it for FreeBSD 5 and thought that
> perhaps the community at large could
If I understand your email correctly, you were able to get all the
files tar'd up from the original system. And you put those tar's on a
second hard drive that you mounted in the dying system, then a day
later, the primary boot drive died. So right now you have a
non-bootable drive formated wit
My company built a tool a few years back for creating a bootable cdrom
based on a running host FreeBSD 3/4 system, which promptly got shelved and
forgotten.I recently had to update it for FreeBSD 5 and thought that
perhaps the community at large could make use it before it gets forgotten
again.
Th
> I am using kqemu and qemu built from May 2 snapshot if that
> matters. This was a stock 5.4-RELEASE complied locallly
> with
>
> makeoptionsDEBUG=-g
>
> added the kernel config file. The host was also running 5.4
> but that should not matter.
Ugh... Should've done a diff with GENER
Hmm... I've used qemu a bit to debug the kernel. Even used
it to debug a loadable module. Here is what I did:
# qemu -s img
# cd
# gdb kernel.debug
(gdb) target remote localhost:1234
...
(gdb) l kldload
739 /*
740 * MPSAFE
741 */
742 int
743 kldload(struct thread *td, stru
where (physically) are you?
It is possible there is someone nearby that can help you..
Sydney Hole & Owen Huffaker wrote:
Hello,
Wonder if you can give me a little advise.
[...]
Regards,
Owen
___
freebsd-hackers@freebsd.org mailing lis
Stephan Uphoff wrote:
In my opinion the original proposal described a non volatile write cache
using dedicated cache disks.
Yes, I think that best describes what I have in mind. Here's the
proposal that went to Google yesterday:
http://geri.cc.fer.hr/~ivoras/proposal.pdf
__
Hi hackers,
I have got an HP DL 385 dual opteron system,
with 2 on-board broadcom network cards.
If I use more NICs, I have to have ACPI turned on.
But if the ACPI is turned on, kernel does not boot,
this is an error message:
panic: npx: can't get ports
Does anybody knows a solution for that ?
On Tue, 2005-06-07 at 16:52, Scott Long wrote:
> David Malone wrote:
> > On Tue, Jun 07, 2005 at 09:40:05PM +0200, Pawel Jakub Dawidek wrote:
> >
> >>+> Does it make sense to do it this way? Is it worth applying for the SoC?
> >>
> >>Not sure. Basically this is simlar what softupdate does, I think
Hello,
We have tried to use qemu for debugging of kernel-level code the same way we
used
bochs in past.
The qemu whether with or without kqemu is quite fast for our needs. The gdb
connects
to guest just fine, however breakpoints break things and qemu stops working.
Our guest OS is FreeBSD 5.3
Scott Long wrote:
>Again, I'm not exactly sure how a generic mechanism can handle the
>distinction of data vs. metadata vs. journal data. Also, what you
Ivan Voras wrote:
>I don't care about the distinction at this level - all data is treated
>equal.
Scott Long wrote:
>But for j
Ivan Voras wrote:
Scott Long wrote:
Again, I'm not exactly sure how a generic mechanism can handle the
distinction of data vs. metadata vs. journal data. Also, what you
I don't care about the distinction at this level - all data is treated
equal.
But for journalling to work, you must c
Scott Long wrote:
Again, I'm not exactly sure how a generic mechanism can handle the
distinction of data vs. metadata vs. journal data. Also, what you
I don't care about the distinction at this level - all data is treated
equal :)
___
freebsd-hack
Ivan Voras wrote:
Scott Long wrote:
An alternate SoC project that would be very useful is block-level
snapshots. I'm not sure if I'll be able to retain the filesystem
snapshot functionality in UFS with journalling enabled, so moving to
doing the snapshots in the block layer would be a good w
Eric Anderson wrote:
Scott Long wrote:
Richard Coleman wrote:
Scott Long wrote:
/me jumps up and down and waves his hands
The problem with journalling at the block layer is that you pretty
much become forced to journal metadata and data, since the block
layer really doesn't know the dist
Sydney Hole & Owen Huffaker wrote:
Hello,
Wonder if you can give me a little advise.
[..snip..]
I am going to try this tomorrow morning and wondered if you might have some
good advise.
I do have a copy of BSD 4.5 and 5.o from a FreeBSD Unleashed book by Michael
Urban and Brian Tieman. I also
Hi,
Sydney Hole & Owen Huffaker wrote:
Wonder if you can give me a little advise.
But not much more.
I do have a copy of BSD 4.5 and 5.o from a FreeBSD Unleashed book by Michael
Urban and Brian Tieman. I also have the absolute BSD by Michael Lucas.
I would not touch them as they are real
Hello,
Wonder if you can give me a little advise.
I don't have a background in freebsd. I maintained a Unix V5 system years
ago and I have been called in to look at an installation that is ailing.
This system is a 4.4 version that is acting as a web server. It has some
web functionality on it w
Scott Long wrote:
Richard Coleman wrote:
Scott Long wrote:
/me jumps up and down and waves his hands
The problem with journalling at the block layer is that you pretty
much become forced to journal metadata and data, since the block
layer really doesn't know the distinction, and definitely
Scott Long wrote:
An alternate SoC project that would be very useful is block-level
snapshots. I'm not sure if I'll be able to retain the filesystem
snapshot functionality in UFS with journalling enabled, so moving to
doing the snapshots in the block layer would be a good way to make up
for
Richard Coleman wrote:
Scott Long wrote:
/me jumps up and down and waves his hands
The problem with journalling at the block layer is that you pretty
much become forced to journal metadata and data, since the block layer
really doesn't know the distinction, and definitely not in a
filesyste
21 matches
Mail list logo
