Hi Alan.
You may remember a while back a suggestion that panic messages be
dumped to floppy so they can be read afterwards.
I've been looking into this idea for a while, in between working on my
plans to get married, and looking for a job somewhere, and I think I
have the bones of it laid out now.
I'm NOT planning on making panics automatically dump to floppy. What I
was looking at instead was to add a SysRq option to dump the current
syslog buffer to floppy. This would be available at any time, but ONLY
if the kernel has SYSRQ support compiled in, and has additionally
enabled CONFIG_SYSRQ_DUMPLOG (which appears when SYSRQ is enabled). In
addition, it would need to be enabled at runtime, probably by writing
to a root-owned /proc file with 0600 permissions.
Before I go any further with this, I would like to ask a few questions
relating to it:
1. Is there any likelihood of this making it into the official
kernel, or am I just wasting my time?
2. Would I be right in thinking it's too late for either the
2.2 or 2.4 kernels ???
Assuming it'd be of interest to Linus and yourself...
3. My investigations so far have indicated that the current
syslog buffer at 16k is too small to guarantee that all
the relevant messages are still there. I would therefore
be looking at increasing this to at least 32k, and would
probably include a config menu to select the size to use
if CONFIG_SYSRQ_DUMPLOG is enabled, offering 32k, 64k,
128k, 256k, 512k and 1M as options.
Would this cause any problems?
4. My choice would be to use SYSRQ-D to activate this. Are
there any other plans for that combination, that you are
aware of?
5. I was wondering about providing some means of selecting
whether to dump to /dev/fd0 or /dev/fd1 (or others if
present). What would be your opinion on this?
6. A while back, I developed a high-level floppy formatter
that produces a non-standard DOS-compatible format that
allows 1436k of data on a 1440k floppy, and produced a
bash script that would produce disks formatted in this
format.
My current plans are for SYSRQ-D to raw write direct to
/dev/fd0 and effectively reformat the disks in this
format, dropping the log file thereon in the process. I
don't plan on doing the low-level format, just the
high-level one.
Can you see anything wrong with this idea?
Best wishes from Riley.
Riley Williams writes:
> I'm NOT planning on making panics automatically dump to floppy. What I
> was looking at instead was to add a SysRq option to dump the current
> syslog buffer to floppy. This would be available at any time, but ONLY
> if the kernel has SYSRQ support compiled in, and has additionally
> enabled CONFIG_SYSRQ_DUMPLOG (which appears when SYSRQ is enabled). In
> addition, it would need to be enabled at runtime, probably by writing
> to a root-owned /proc file with 0600 permissions.
Just as an FYI, there is a patch that does essentially what you are
looking at: kmsgdump, by Willy Tarreau. It does a syslog dump to
floppy with SysRq-D, and has the excellent feature that it writes a
(simple) MS-DOS formatted floppy, which also has a "pass-through"
boot sector, so you can leave it in the floppy drive and it will not
halt booting. You can have syslog sizes up to 64kB. It also supports
printing to the printer port.
http://www-miaif.lip6.fr/willy/pub/linux-patches/kmsgdump/
This would actually be very handy in conjunction with the "loadable
sysrq functions" patch that has been posted here a couple of times.
I suspect that such a patch wouldn't make it into 2.2 or 2.4. I also
don't see why you want to have a strangely formatted floppy, since even
a regular 1.44 format will hold your proposed maximum 1MB buffer. Since
the printk buffer is pinned kernel memory, you probably don't want that
any larger (if 1MB at all).
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
Riley Williams <[email protected]> said:
[...]
> Before I go any further with this, I would like to ask a few questions
> relating to it:
>
> 1. Is there any likelihood of this making it into the official
> kernel, or am I just wasting my time?
Depends, I'd say... perhaps after a long shakeout and much use.
> 2. Would I be right in thinking it's too late for either the
> 2.2 or 2.4 kernels ???
No way.
> Assuming it'd be of interest to Linus and yourself...
[...]
> 5. I was wondering about providing some means of selecting
> whether to dump to /dev/fd0 or /dev/fd1 (or others if
> present). What would be your opinion on this?
Keep it as simple as possible. I'd leave the option open if not hard, but
not implement it at all at first.
> 6. A while back, I developed a high-level floppy formatter
> that produces a non-standard DOS-compatible format that
> allows 1436k of data on a 1440k floppy, and produced a
> bash script that would produce disks formatted in this
> format.
>
> My current plans are for SYSRQ-D to raw write direct to
> /dev/fd0 and effectively reformat the disks in this
> format, dropping the log file thereon in the process. I
> don't plan on doing the low-level format, just the
> high-level one.
KISS, again. What use is a non-standard 1436Kb DOS format when writing at
most 1Mb? I'd just dump it raw to /dev/fd0, whoever wants to read it later
will have all kinds of tools at hand.
Remember:
- Bloat
- This will have to work even in a thoroughly hosed system to be of any use
--
Horst von Brand [email protected]
Casilla 9G, Vin~a del Mar, Chile +56 32 672616
Hi Horst.
>> Before I go any further with this, I would like to ask a few
>> questions relating to it:
>> 1. Is there any likelihood of this making it into the official
>> kernel, or am I just wasting my time?
> Depends, I'd say... perhaps after a long shakeout and much use.
Fair enough - I'd expect that much...
>> 2. Would I be right in thinking it's too late for either the
>> 2.2 or 2.4 kernels ???
> No way.
Good...
I've included a patch against 2.2.17 that deals with all of the
existing files and implements a version of this facility that just
prints "(Not yet implemented)" into the SysLog. The final version will
basically consist of this patch with the printk("Not yet implemeted")
replaced by a call to the routine to actually perform the dump, plus a
new file kernel/dumplog.c containing the said routine.
Note that this patch tweaks ALL of the current architecture config.in
files to replace the CONFIG_MAGIC_SYSRQ definition with a command to
include the new arch/sysrq.in file at that point, and all the options
relating to SYSRQ are in this new file instead.
>> 5. I was wondering about providing some means of selecting
>> whether to dump to /dev/fd0 or /dev/fd1 (or others if
>> present). What would be your opinion on this?
> Keep it as simple as possible. I'd leave the option open if not
> hard, but not implement it at all at first.
OK. Initially, I'll look at dropping it strictly to /dev/fd0 and leave
the /dev/fd1 code until later.
>> 6. A while back, I developed a high-level floppy formatter
>> that produces a non-standard DOS-compatible format that
>> allows 1436k of data on a 1440k floppy, and produced a
>> bash script that would produce disks formatted in this
>> format.
>> My current plans are for SYSRQ-D to raw write direct to
>> /dev/fd0 and effectively reformat the disks in this
>> format, dropping the log file thereon in the process. I
>> don't plan on doing the low-level format, just the
>> high-level one.
> KISS, again. What use is a non-standard 1436Kb DOS format when
> writing at most 1Mb?
The said floppy formatter also works with other capacity disks, and
always minimises the system overhead for the disk size.
Also, part of my plan was to check that the disk is already in this
non-standard format, and refuse to dump if not. This would ensure that
doing so didn't overwrite somebody's master boot disk by accident, as
such disks will not normally be in this non-standard format.
> I'd just dump it raw to /dev/fd0, whoever wants to read it later
> will have all kinds of tools at hand.
> Remember:
> - Bloat
That's one reason why I was glad to note the error in the comments in
kernel/printk.c that I sent a patch to correct last week - this patch
will be MUCH simpler as a result.
> - This will have to work even in a thoroughly hosed system to be
> of any use
It's for precicely that reason that I'm working on it.
Best wishes from Riley.
On Tue, Oct 31, 2000 at 01:38:56PM +0000, Riley Williams wrote:
...
> Also, part of my plan was to check that the disk is already in this
> non-standard format, and refuse to dump if not. This would ensure that
> doing so didn't overwrite somebody's master boot disk by accident, as
> such disks will not normally be in this non-standard format.
Just write a magic number somewhere to the disk and mark these blocks
bad in the fat. Then just check if the blocks are marked as bad and
contain the magic number. No need for a special disk format per se...
Yours,
Dominik Kubla
--
http://petition.eurolinux.org/index_html - No Software Patents In Europe!