2012/8/20 Steven Chamberlain ste...@pyro.eu.org:
On 20/08/12 20:16, Axel Beckert wrote:
[...] clearly something _after_ the fsck does that.
Looking back at my 'dot' graph of initscript dependencies, it seems like
freebsdutils is the only thing that is free to run before, after, or at
the
tags 672959 +patch
--
Hi.
/sbin/startpar -p 4 -t 20 -T 3 -M boot -P N -R S
And the same happens even with -p 0. This is a single-CPU VM running
kfreebsd-i386.
I'm beginning to think that startpar is malfunctioning in some way
(after checkroot.sh returns, but before it runs the next
Hi,
Petr Salinger wrote:
I'm beginning to think that startpar is malfunctioning in some way
(after checkroot.sh returns, but before it runs the next script).
Thanks to Steven for excelent hint.
Indeed. That fits perfectly with my observation that always the last
thing I saw before the crash
retitle 672959 startpar triggers kfreebsd panic: vm_fault_copy_wired
thanks
On 21/08/12 09:16, Petr Salinger wrote:
I'm beginning to think that startpar is malfunctioning in some way
(after checkroot.sh returns, but before it runs the next script).
Thanks to Steven for excelent hint.
I'm
On Tue, Aug 21, 2012 at 10:47:57AM +0200, Axel Beckert wrote:
Hi,
Petr Salinger wrote:
I'm beginning to think that startpar is malfunctioning in some way
(after checkroot.sh returns, but before it runs the next script).
Thanks to Steven for excelent hint.
Indeed. That fits
Hi Roger,
Roger Leigh wrote:
I've put a test package here:
http://people.debian.org/~rleigh/sysvinit/sysvinit_2.88dsf-33.dsc
I'd be grateful if anyone could build this and double-check that this
is correct, and fixes the bug. I'll upload this as soon as that's
done.
Works for me on
Hi!
On 21/08/12 22:43, Roger Leigh wrote:
I've put a test package here:
http://people.debian.org/~rleigh/sysvinit/sysvinit_2.88dsf-33.dsc
I'd be grateful if anyone could build this [...]
That works okay, even with a genuinely dirty rootfs where fsck carries
out a repair. I'm using
Something that popped into mind:
Has the exact sysvinit version where this issue crept in been
positively identified?
While the bug report was filed against version 2.88dsf-22.1, I'm
wondering if that was the exact sysvinit version where fsck.ufs
started crashing the boot process in such a
Hi,
Martin-Éric Racine wrote:
Something that popped into mind:
Has the exact sysvinit version where this issue crept in been
positively identified?
AFAIK not yet, because nobody tried.
While the bug report was filed against version 2.88dsf-22.1, I'm
wondering if that was the exact
On 20/08/12 16:07, Axel Beckert wrote:
Has the exact sysvinit version where this issue crept in been
positively identified?
AFAIK not yet, because nobody tried.
2.88dsf-22.1 is simply what I had installed when I filed the bug. It
most likely affects earlier versions too. It would be a good
On 20/08/12 19:26, Petter Reinholdtsen wrote:
If the kernel can crash, it is a bug in the kernel.
Well, something in the initscripts could be telling the kernel to do
something bad. Maybe to do with the rootfs, or swap. Then it might be
acceptable for the kernel to panic and that wouldn't be a
Maybe I am stupit or something, but if fsck called by some init script
causes the kernel to crash, why are you trying to figure out how the
init script changed to cause this, instead of looking at the kernel
and fsck?
If the kernel can crash, it is a bug in the kernel. If fsck can cause
the
Petter Reinholdtsen wrote:
Maybe I am stupit or something, but if fsck called by some init script
causes the kernel to crash,
No, it doesn't. As I wrote, clearly something _after_ the fsck does
that.
Regards, Axel
--
,''`. | Axel Beckert a...@debian.org,
Hi Steven,
Steven Chamberlain wrote:
2.88dsf-22.1 is simply what I had installed when I filed the bug. It
most likely affects earlier versions too. It would be a good idea to
check this I think.
Axel, have you tested any more recent versions than this?
So far all my tests where with
On 20/08/12 20:16, Axel Beckert wrote:
[...] clearly something _after_ the fsck does that.
Looking back at my 'dot' graph of initscript dependencies, it seems like
freebsdutils is the only thing that is free to run before, after, or at
the same time as checkroot.sh and thus could be affected by
Hi,
I tried commenting out the code in checkroot.sh that remounts the rootfs
as writable after fsck is finished. It still panics, but then the
filesystem isn't marked as dirty on next boot (because fsck succeeded,
marked it as clean, and the fs was still mounted read-only at the time
of the
Hi,
here are my observations so far after several hours and evenings of
rebooting my kFreeBSD EeeBox again and again.
I've unfortunately not yet found the real cause or an solution, but
maybe some of my observations spark ideas at others. I'll continue
debugging the issue on Monday evening as
Hi,
I ran into that on Saturday, too.
Roger Leigh wrote:
I guess this is reproducible by simply installing Debian/kFreeBSD AMD64
on a virtual machine and forcing and unclean shutdown (killing the qemu
process when the virtual machine is running).
It seems so, yes. It seems triggered by
On Sat, Jul 21, 2012 at 11:47:24PM +0200, Carlos Alberto Lopez Perez wrote:
On 21/07/12 23:32, Roger Leigh wrote:
Looking at the screenshot you attached, I can't see any obvious
reason for fsck to make the kernel panic. There's no indication
of odd scripts (other than geli) running in
On 16/05/12 22:37, Robert Millan wrote:
#!/bin/sh
exec bash /dev/console /dev/console 2 /dev/console
If I do that and start each script in /etc/rcS.d/S* manually one at a
time, there is no problem. The rootfs is mounted read-only to begin
with, it gets fixed/marked clean during the checkfs
this just by creating a /forcefsck file:
Activating swap:.
Will now check root file system:fsck from util-linux 2.20.1
[/sbin/fsck.ufs (1) -- /] fsck.ufs -f -a /dev/ad0s1
/dev/ad0s1: 15710 files, 260322 used, 682949 free (11855 frags, 83883 blocks,
1.3% fragmentation)
.
panic
2012/5/16 Steven Chamberlain ste...@pyro.eu.org:
I tried setting kFreeBSD.init_path to a shell but as mentioned on the
FAQ that doesn't work:
http://wiki.debian.org/Debian_GNU/kFreeBSD_FAQ#Q._How_do_I_make_the_kFreeBSD_kernel_launch_another_binary_instead_of_.2BAC8-sbin.2BAC8-init.3F
Init is
ufs:/dev/ad0s1
WARNING: / was not properly dismounted
mount option nodev is unknown
mount option nodev is unknown
mount option nodev is unknown
panic: vm_fault_copy_wired: page missing
cpuid = 1
KDB: stack backtrace:
Uptime: 4s
Cannot dump. Device not defined or unavailable.
Automatic
Hi!
Steven Chamberlain ste...@pyro.eu.org writes:
This problem came back after an unclean, forced reset of a crashed VM.
This time I managed to log startup messages via serial console.
After this problem occurred, it would persist between resets. I had to
boot d-i, drop to a shell, run
On 14/05/12 17:08, Steven Chamberlain wrote:
Hi,
This problem came back after an unclean, forced reset of a crashed VM.
This time I managed to log startup messages via serial console.
After this problem occurred, it would persist between resets. I had to
boot d-i, drop to a shell, run
, and confirmed by two others on
debian-bsd@lists.d.o; see
http://lists.debian.org/4fa80dbd.3000...@pyro.eu.org
Trying to mount root from ufs:/dev/ad0s1
WARNING: / was not properly dismounted
mount option nodev is unknown
mount option nodev is unknown
mount option nodev is unknown
panic
On 07/05/12 23:53, Christoph Egger wrote:
I've been trying to debug this today on a testing kfreebsd-i386 system
with no ZFS involved at all (kernel panic in vm_fault_copy_wired) ..
Thanks, good to know I'm not the only one :)
This is still a mystery to me, the problem went away almost by
too but not the kernel;
kernels 8.3 or 9.0 both did the same thing.
I got a panic: vm_fault_copy_wired: page missing early in the /etc/rcS.d
scripts; I think it may be to do with the swap which was on a ZFS zvol.
Using the installer as a rescue system, I made sure my UFS rootfs was
clean
it was due to
installing these. I'd upgraded some other stuff too but not the kernel;
kernels 8.3 or 9.0 both did the same thing.
I got a panic: vm_fault_copy_wired: page missing early in the /etc/rcS.d
scripts; I think it may be to do with the swap which was on a ZFS zvol.
I've been trying to debug
29 matches
Mail list logo
