system-config-kdump has hardcoded whitelist of major numbers for block devices that can be used as raw kdump targets. With the current list it does not show virtio disks [1] as possible targets. The major device number for virtio is assigned dynamically, thus I cannot simply add a new number.
I have no idea how the major numbers in the list were chosen. I see these possibilities for fixing the bug:
* Do not try to outsmart the user, throw away the list, and offer all devices that are listed in /proc/partitions.
* Add all the numbers that can be used for dynamic assignment to the whitelist.
* Determine whether a device is suitable by some other means. For example, /sys/dev/block/MAJOR:MINOR/ro should contain 1 if the device is read-only. However it contains 0 for my optical drive, so using this is probably not as useful.
I'll be grateful for any suggestions, Martin
[0] https://git.fedorahosted.org/cgit/system-config-kdump.git/tree/src/system-co... [1] https://bugzilla.redhat.com/show_bug.cgi?id=1077470
On Thu, Sep 25, 2014 at 12:15:49PM +0200, Martin Milata wrote:
system-config-kdump has hardcoded whitelist of major numbers for block devices that can be used as raw kdump targets. With the current list it does not show virtio disks [1] as possible targets. The major device number for virtio is assigned dynamically, thus I cannot simply add a new number.
This is interesting. I did not know that system-config-kdump does this kind of hardcoding.
I have no idea how the major numbers in the list were chosen. I see these possibilities for fixing the bug:
I also have no idea. If there is a block device, it should be able to act as a raw device, isn't it? If yes, we should just check if a device is block device or not, IMO.
Secondly, we also should do some checks if raw device has a file system or if a raw device is a slave device of another block device and warn user about it.
Thanks Vivek
On Fri, Sep 26, 2014 at 09:34:55 -0400, Vivek Goyal wrote:
On Thu, Sep 25, 2014 at 12:15:49PM +0200, Martin Milata wrote:
system-config-kdump has hardcoded whitelist of major numbers for block devices that can be used as raw kdump targets. With the current list it does not show virtio disks [1] as possible targets. The major device number for virtio is assigned dynamically, thus I cannot simply add a new number.
This is interesting. I did not know that system-config-kdump does this kind of hardcoding.
Yes, it does all kinds of weird things:/
I have no idea how the major numbers in the list were chosen. I see these possibilities for fixing the bug:
I also have no idea. If there is a block device, it should be able to act as a raw device, isn't it? If yes, we should just check if a device is block device or not, IMO.
Secondly, we also should do some checks if raw device has a file system or if a raw device is a slave device of another block device and warn user about it.
I forgot to mention that s-c-kdump already does that - if the device is mounted or otherwise used (e.g. device mapper) then it is excluded from the list.
Thanks, Martin
On 09/25/14 at 12:15pm, Martin Milata wrote:
system-config-kdump has hardcoded whitelist of major numbers for block devices that can be used as raw kdump targets. With the current list it does not show virtio disks [1] as possible targets. The major device number for virtio is assigned dynamically, thus I cannot simply add a new number.
I have no idea how the major numbers in the list were chosen. I see these possibilities for fixing the bug:
Do not try to outsmart the user, throw away the list, and offer all devices that are listed in /proc/partitions.
Add all the numbers that can be used for dynamic assignment to the whitelist.
Determine whether a device is suitable by some other means. For example, /sys/dev/block/MAJOR:MINOR/ro should contain 1 if the device is read-only. However it contains 0 for my optical drive, so using this is probably not as useful.
For CDROM we can not check the /sys/dev/block/MAJOR:MINOR/ro because it depends on the media type in the drive. Anyway we do not support writing to cdrom so it's safe to skip any devices in /proc/sys/dev/cdrom/info The first line should list the cdrom device names.
BTW, how about let user provide the device path name manually instead provide a list in UI?
Thanks Dave
On Mon, Sep 29, 2014 at 13:02:07 +0800, Dave Young wrote:
On 09/25/14 at 12:15pm, Martin Milata wrote:
system-config-kdump has hardcoded whitelist of major numbers for block devices that can be used as raw kdump targets. With the current list it does not show virtio disks [1] as possible targets. The major device number for virtio is assigned dynamically, thus I cannot simply add a new number.
I have no idea how the major numbers in the list were chosen. I see these possibilities for fixing the bug:
Do not try to outsmart the user, throw away the list, and offer all devices that are listed in /proc/partitions.
Add all the numbers that can be used for dynamic assignment to the whitelist.
Determine whether a device is suitable by some other means. For example, /sys/dev/block/MAJOR:MINOR/ro should contain 1 if the device is read-only. However it contains 0 for my optical drive, so using this is probably not as useful.
For CDROM we can not check the /sys/dev/block/MAJOR:MINOR/ro because it depends on the media type in the drive. Anyway we do not support writing to cdrom so it's safe to skip any devices in /proc/sys/dev/cdrom/info The first line should list the cdrom device names.
Thanks for the suggestion. Looks like blacklisting devices instead of whitelisting makes more sense here.
BTW, how about let user provide the device path name manually instead provide a list in UI?
I don't know - I guess the point of s-c-kdump is configuring kdump without much typing?:) I don't see any advantage (except perhaps in the case when the list is very long).
Cheers, Martin
On Mon, Sep 29, 2014 at 02:27:50PM +0200, Martin Milata wrote:
On Mon, Sep 29, 2014 at 13:02:07 +0800, Dave Young wrote:
On 09/25/14 at 12:15pm, Martin Milata wrote:
system-config-kdump has hardcoded whitelist of major numbers for block devices that can be used as raw kdump targets. With the current list it does not show virtio disks [1] as possible targets. The major device number for virtio is assigned dynamically, thus I cannot simply add a new number.
I have no idea how the major numbers in the list were chosen. I see these possibilities for fixing the bug:
Do not try to outsmart the user, throw away the list, and offer all devices that are listed in /proc/partitions.
Add all the numbers that can be used for dynamic assignment to the whitelist.
Determine whether a device is suitable by some other means. For example, /sys/dev/block/MAJOR:MINOR/ro should contain 1 if the device is read-only. However it contains 0 for my optical drive, so using this is probably not as useful.
For CDROM we can not check the /sys/dev/block/MAJOR:MINOR/ro because it depends on the media type in the drive. Anyway we do not support writing to cdrom so it's safe to skip any devices in /proc/sys/dev/cdrom/info The first line should list the cdrom device names.
Thanks for the suggestion. Looks like blacklisting devices instead of whitelisting makes more sense here.
I agree. Removing devices from list which are not writables makes more sense.
BTW, how about let user provide the device path name manually instead provide a list in UI?
I don't know - I guess the point of s-c-kdump is configuring kdump without much typing?:) I don't see any advantage (except perhaps in the case when the list is very long).
If it is not too hard, I think it is not a bad idea to provide user list of devices. To me it just makes configuration easier. Instead of asking user to figure out the path.
Thanks Vivek
-
Dave Young -
Martin Milata -
Vivek Goyal