Re: Changes to kern.geom.debugflags?
On Dec 25, 2012, at 6:25 PM, Marius Strobl wrote:
So, does anyone know if something has gone unstable in the sparc64 zfsboot
in recent months? If I boot from the cdrom again and load the July zfsboot
via gpart bootcode, it boots correctly again.
Please see
http://www.freebsd.org/cgi/getmsg.cgi?fetch=0+0+/usr/local/www/db/text/2012/freebsd-sparc64/20121223.freebsd-sparc64
and provide debug information.
I built the world with DEBUG_FLAGS=-g, and installed new zfsboot and zfsloader
on my sparc64. However, ctrace isn't helpful:
FreeBSD/sparc64 ZFS boot block
Boot path: /pci@1c,60/scsi@2/disk@1,0:a
Consoles: Open Firmware console
ERROR: Last Trap: Division by Zero
{1} ok ctrace
No saved state
{1} ok
Anything else you can suggest to get debugging information out of zfsloader?
- Chris
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Changes to kern.geom.debugflags?
On Dec 25, 2012, at 18:25 , Marius Strobl mar...@alchemy.franken.de wrote: Please see http://www.freebsd.org/cgi/getmsg.cgi?fetch=0+0+/usr/local/www/db/text/2012/freebsd-sparc64/20121223.freebsd-sparc64 and provide debug information. Thank you. I can rebuild everything with DEBUG_FLAGS=-g. But do I need to do that in only boot? And, that message says: Please use debug versions of the loaders and report the output of `ctrace` on the boot monitor prompt. Building debug versions is most easily done via `make DEBUG_FLAGS=-g` in path/to/src/boot when building natively. You can also add the same when cross- compiling but then you'll end up with debug versions of everything. In both cases, make sure to not have any old object files in place. But, I'm not sure what the boot monitor prompt refers to, where i'm supposed to enter ctrace. When the boot crashes, I'm left at the open prom. Is that where I'm supposed to enter ctrace? Apologies if so, I just haven't known of that OBP command previously. Thank you. I'll try to come up with the debugging output you're requesting. And more directions would be appreciated. - Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Changes to kern.geom.debugflags?
On Dec 23, 2012, at 16:56 , Chris Ross cross+free...@distal.com wrote:
I had brought up a machine months ago with freebsd-9-stable. I configured it
to boot off of a single disk, with ZFS, expecting I would likely later attach
the other disk to the zpool. I tried to do that today, but find that I can't
write the bootloader to either disk.
gpart: /dev/da0a: Operation not permitted
[...]
Okay. It occurred to me today what was likely the problem. I was running,
even when single user, off of the zfs pool on the disks I was trying to write
the bootloader to.
I tar'd up /boot after my recent install from a Dec 22 9-stable, and moved it
off-host. Then, I booted off of the July stable-9 CD-ROM I have in the
machine, and was able to write bootblocks (with gpart bootcode) and a
bootloader (dd if=/boot/zfsloader of=/dev/${disk}a bs=512 oseek=1024
conv=notrunc).
Now, the new problem. When I try to boot my sparc64 with these bits, I see:
FreeBSD/sparc64 ZFS boot block
Boot path: /pci@1c,60/scsi@2/disk@0,0:a
Consoles: Open Firmware console
ERROR: Last Trap: Division by Zero
{1} ok
So, does anyone know if something has gone unstable in the sparc64 zfsboot in
recent months? If I boot from the cdrom again and load the July zfsboot via
gpart bootcode, it boots correctly again.
Thanks. Any feedback appreciated.
- Chris
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Changes to kern.geom.debugflags?
I had brought up a machine months ago with freebsd-9-stable. I configured it
to boot off of a single disk, with ZFS, expecting I would likely later attach
the other disk to the zpool. I tried to do that today, but find that I can't
write the bootloader to either disk.
Google searching shows what I used last time, that if you get a:
gpart: /dev/da0a: Operation not permitted
you need to run
sysctl kern.geom.debugflags=0x10
But, that doesn't change anything for me now. I can write the boot label
(using gpart bootcode -p /boot/zfsboot ${disk}) to neither disk, getting the
same error in both cases.
Has something changed recently? I'm currently using a Dec 22 9-stable
codebase, built locally with GENERIC kernel.
- Chris
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Locally modifying ports
So, I've been a NetBSD user for many years, and am looking more at FreeBSD now. Trying to build myself a system, I find that I have a long-held delta to a package on my NetBSD system, and I keep it in a patch-local-* file in NetBSD pkgsrc. I can't figure out if FreeBSD ports has a way to keep and automatically apply local patches to ports. I want to modify the way the internals of a package/port operate, and not in a way that makes sense to move up- stream. It's just my preference. Is there a way in FreeBSD ports to keep a make this change to the source code after extracting and before compiling type of thing in the tree? Thanks - Chris ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
