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
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
On 16/05/12 07:37, Robert Millan wrote:
Erm sorry, disregard that. I didn't notice that userland output isn't
being included in your log.
Oooh I didn't realise that either, the serial console only shows the
kernel output. I saw the nodev errors which are triggered from
mountkernfs.sh, but
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
Package: src:sysvinit
Version: 2.88dsf-22.1
Severity: important
Tags: sid wheezy
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
X-Debbugs-Cc: debian-bsd@lists.debian.org
Hi,
Not exactly sure yet where to file this bug, perhaps initscripts, a
kernel (kfreebsd-8 and -9) bug or something else
22 matches
Mail list logo
