On Tue, May 13, 2014 at 09:02:31 -0400, Vivek Goyal wrote:
On Tue, May 13, 2014 at 12:36:04PM +0200, Martin Milata wrote:
> On Tue, May 13, 2014 at 13:51:16 +0800, Baoquan He wrote:
> > On 05/12/14 at 06:05pm, Martin Milata wrote:
> > > Hi,
> > > I have released system-config-kdump-2.0.15-1 for rawhide and F20
> > > (currently in updates-testing). The new release allows you to select a
> > > path even if no FS is explicitly chosen.
> > >
> > > Any testing is appreciated.
> >
> > Hi Martin,
> >
> > Thanks for this update.
> >
> > I tested s-c-k-2.0.15-1 on f20, when no target specified, "path" can
be
> > edited now.
> > The diagram is like below with your update:
> >
> > ------------------------------------------------------------------
> > Path: /var/crash
> > Local file system: Partition: Root file system
> > core will be in /var/crash/%DATE on rootfs
> > -----------------------------------------------------------------
> >
> > There are some comments:
> >
> > 1) the text for Partition should be "Unspecified" in this case, since
it
> > can present that user didn't specify a target, "Root file system"
is a
> > little confusing, misguide user to think that core is dumped into rootfs
> > device.
>
> Good point! I'll change it.
>
> > 2) The string "core will be in /var/crash/%DATE on rootfs" may be
not
> > accurate for this case. If disk is mounted on /var or /var/crash, the
> > core will be not in rootfs, just in a absolute path which begins from
"/".
> > So 2 different ideas are raised, one is to explain this "Path",
namely
> > "/var/crash" is a absolute path, the other is to tell user the mount
> > info.
> >
> > E.g:
> > The text of 1st would be like:
> > core will be in /var/crash/%DATE which is an absolute path
> >
> > The text of 2nd would be like below (assume /dev/sdc mounted on /var)
> > core will be in /crash/%DATE on ext4 /dev/sdc
> > or (if no disk mounted on /var or /var/crash)
> > core will be in /var/crash/%DATE on rootfs
> >
> > I personally prefer the 1st, the 2nd could be more detailed. Let's
> > review and discuss it.
>
> The second option sounds better to me as well. I'll look into it and
> provide a new build.
>
> These new texts won't be true for old kexec-tools versions that do not
> have the auto-mounting feature. I propose to solve this by requiring a
> new enough version of kexec-tools for system-config-kdump. What is the
> N-V-R of the first version with this feature?
I am not a big fan of this idea. Why not leave it as follows.
------------------------------------------------------------------
Path: /var/crash
Local file system: Partition:
core will be in /var/crash/%DATE/
-----------------------------------------------------------------
Reason being.
- First of all now system-config-kdump will have to implement the logic to
map which disk /var/crash is mounted on and then do the relative path
calculation on that disk.
- More importantly, this is not kdump API. If kdump changes behavior down
the line, system-config-kdump will be out of sync again.
So to me let us not try to be too intelligent. Once we say core will be
saved in /var/crash/%DATE, I think it is clear. Who cares what's the disk
and what's the filesystem. Admin has plenty of ways to figure out what's
the disk backing /var/crash/.
Oops, I didn't catch this email yesterday and went ahead implementing
it. Scratch builds if you want to try it:
F20:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6848717
rawhide:
http://koji.fedoraproject.org/koji/taskinfo?taskID=6848763
To be honest, I have no idea what's more suitable for a typical
s-c-kdump user. I agree with Vivek's point about trying to be smarter
than the user. Perhaps we should use what he proposes but with a
Partition: combobox item that concisely explains what's going on?
Martin