> It seems well established by now that there is no magic bullet for your
> problem, since it is a problem few if anyone has had to address before
> within the constraints you have described.
This is a good summary for that quite long thread.
Again, thanks to everybody! I really do appreciate all
Otto,
thanks for your hint.
> Can we end this now?
I thought I had initiated the end of this thread this morning by writing:
> I'm happy that some of you took the time and tried to explain over
> and over again what you thought was best for me. I really appreciate the
> good will.
But I have
@Gregory
> What he rather need is to boot GENERIC, then record dmesg, and strip
> the kernel down according to that dmesg.
That is exactly what I've done and this led me to my first posting here,
because it generally worked fine, but only to a certain extend. It
didn't work completely. Something
> So: your machine has 32MB of Flash storage that holds the entire
> system. On boot, it all gets loaded as a RAMDISK. Right?
Doesn't have to do with my question, but: more or less correct.
> It certainly sounds interesting. Out of curiosity: what do these
> system do? Are their routers? Rocket
Thanks to everybody. I'll dig deeper into the config files soon. For now
I think we've got it discussed as much as is possible in a ML.
Stuart,
I really don't want to be misunderstood: I really appreciate the help
that's being offered from various users of this ML.
However, the following is somewhat off topic as it does not contribute
to the thread itself.
>> Because of the permanent repeating of "USE THE GENERIC KERNEL"
> not
Andres,
may I kindly ask one more question, I'm sure after that I'll get it
right myself.
See:
# make
ld -Ttext 0xD0200120 -e start -N --warn-common -S -x -o bsd
${SYSTEM_HEAD} vers.o ${OBJS}
acpi_machdep.o(.text+0xcf): In function `acpi_sl
Andres,
thanks a lot for your quick reply! I'm going to try this in a minute.
>> dmassage -t
> i might be wrong, but is this really aggressive auto spelling
> corrector for "dmesg"?
I found an example usage of dmassage on the web, but could not find the
program. So I thought the same way as yo
Hi!
I'm trying to build a new kernel. However, while compiling I get
complaints about undefined references like this:
ld -Ttext 0xD0200120 -e start -N --warn-common -S -x -o bsd
${SYSTEM_HEAD} vers.o ${OBJS}
machdep.o(.text+0x2791): In function `sys_sigreturn':
: undefined reference to `fpu_mxcsr
Folks, yes, I appreciate your attempt to help a lot. And I really am on
your side if we're talking about "normal" machines.
However, obviously nobody believes me when I say "For us there is no
reason to update to newer versions of OpenBSD yet. On the contrary,
maintenance is a lot easier for us if
[old versions on new hardware]
> And the answer is that we wouldn't know, since we don't run old code.
I didn't expect that anyone of the OpenBSD core-team would have an
answer due to the obvious fact that you must be working with the latest
versions.
But who knows, maybe I'm lucky and there's s
> OpenBSD 4.3 is no longer officially supported.
That wasn't my question. I didn't ask for support, I thought maybe
someone has an idea which recent boards could be compatible to 4.3.
It's a valid question, isn't it? ;-)
Hi!
We're using OpenBSD 4.3 kernels on a larger number of machines.
(For us there is no reason to update to newer versions of OpenBSD yet.
On the contrary, maintenance is a lot easier for us if we try to keep
all systems on the same versions for as long as possible.)
Yet we have been using Intel
>> It gives me the exact same error all the time: broken MBR.
> My guess is that you never ran fdisk -i on this disk.
You are so right!!!
Thanks a lot!!!
("Kaum macht man es richtig, schon funktioniert's!")
T.
Hi!
I'm having trouble using installboot. Here some facts that are the way
they are (Test environment on which I simulate things), no need to
discuss them:
OpenBSD4.3 (probably the same issue with any other version anyway)
Hardware is VMWare ESXi 4
Here's what I do:
- fresh install of OpenBSD o
>> Anyway, I agree with you here that I maybe should have taken a closer
>> look at MFS. I just didn't take it into consideration because I have
>> worked with rdconfig since OpenBSD 3.2 without problems.
>
> There's not much crosslinking in the manual between them, I wonder
> whether rd(4) should
Problem: Using disklabel on /dev/rd0c causes a kernel panic.
>>> I think you're looking for mount_mfs(8), its use is demonstrated
>>> in fstab(5).
>> No. MFS != ramdisk
> Exactly. rd(4) is for ramdisks built-in to kernels, MFS is for
> normal use...
> Doesn't the fact that you have to build a
>> Problem: Using disklabel on /dev/rd0c causes a kernel panic.
> I think you're looking for mount_mfs(8), its use is demonstrated
> in fstab(5).
No. MFS != ramdisk
Just try what I wrote in my first mail. Create a ramdisk with rdconfig
and then you'll see what I mean.
T.
In case anyone could be interested:
I found a workaround. As far as I understand the disk structure of an
internal ramdisk, I would regard the workaround as to be senseless, but
it works:
OpenBSD 3.9:
Problem: Using disklabel on /dev/rd0c causes a kernel panic.
Workaround: Use fdisk on rd0, creat
Hi!
Using the ramdisk kernel feature results in a kernel problem when I use
the disklabel command on the ramdisk.
This is what I do :
Use 3.9 (tried sys.tgz from mirror as well as updated sources from cvs)
in /usr/src/sys/arch/i386/conf
cp GENERIC Test
echo pseudo-device rd 1
20 matches
Mail list logo
