Discussion:
[Sisuite-devel] systemconfigurator and device.map (r711)
Andrea Righi
2008-02-17 16:08:56 UTC
Permalink
Hi Erich,

about this:
http://svn.systemimager.org/comp.php?repname=systemconfigurator&path=&compare%5B%5D=%***@710&compare%5B%5D=%***@711&manualorder=1

if we don't always force the re-creation of device.map for grub the
imaging will fail with clients that have different disk types respect to
the golden client (sda vs hda for example). But at this point we can
easily fix this in systemimager, before running systemconfigurator, as
it's already done with /etc/fstab, menu.lst, etc.

I've to test it, but I think this is the best solution, it allows to
correctly handle clients with a lot of external LUNs (as you reported in
the commit log) and also clients with different disk types.

-Andrea
---

Index: etc/autoinstallscript.template
===================================================================
--- etc/autoinstallscript.template (revision 4387)
+++ etc/autoinstallscript.template (working copy)
@@ -398,7 +398,7 @@
[ -z $DISKORDER ] || {
echo "Editing files for actual disk configuration..."
##SHOW_DISK_EDITS##
- for file in /etc/fstab /etc/systemconfig/systemconfig.conf /boot/grub/menu.lst /etc/lilo.conf /etc/grub.conf; do
+ for file in /etc/fstab /etc/systemconfig/systemconfig.conf /boot/grub/menu.lst /etc/lilo.conf /etc/grub.conf /boot/grub/device.map; do
[ -f /a/$file ] || continue
echo " $file"
cp /a/$file /a/$file.image
Erich Focht
2008-02-18 09:41:52 UTC
Permalink
Hi Andrea,

as far as I understand, you suggest that if a device.map file is present,
you copy it to /a/boot/grub/device.map.image . Moving would be bad,
but copying is fine, so that we have under control whether we provide
a file or not. Guess your're aiming at pre-install scriptlets?

In fact through the overrides one has very fine-grained control on what
would be done on a node with respect to the device.map file, for the case
that the nodes have different types of disks than the golden client.
That's why I saw no real problem with the patch r711. My point was to have
at least some way of disabling the device.map generation (which is
unreliable).

I tagged systemconfigurator 2.2.12 but didn't put the RPMs on the download
page, as nobody ever complained about this kind of issue. If no other
patches show up in near future, I'll complete the "release".

Best regards,
Erich
Post by Andrea Righi
Hi Erich,
if we don't always force the re-creation of device.map for grub the
imaging will fail with clients that have different disk types respect to
the golden client (sda vs hda for example). But at this point we can
easily fix this in systemimager, before running systemconfigurator, as
it's already done with /etc/fstab, menu.lst, etc.
I've to test it, but I think this is the best solution, it allows to
correctly handle clients with a lot of external LUNs (as you reported in
the commit log) and also clients with different disk types.
-Andrea
---
Index: etc/autoinstallscript.template
===================================================================
--- etc/autoinstallscript.template (revision 4387)
+++ etc/autoinstallscript.template (working copy)
@@ -398,7 +398,7 @@
[ -z $DISKORDER ] || {
echo "Editing files for actual disk configuration..."
##SHOW_DISK_EDITS##
- for file in /etc/fstab /etc/systemconfig/systemconfig.conf /boot/grub/menu.lst /etc/lilo.conf /etc/grub.conf; do
+ for file in /etc/fstab /etc/systemconfig/systemconfig.conf /boot/grub/menu.lst /etc/lilo.conf /etc/grub.conf /boot/grub/device.map; do
[ -f /a/$file ] || continue
echo " $file"
cp /a/$file /a/$file.image
Andrea Righi
2008-02-18 14:12:18 UTC
Permalink
Post by Erich Focht
Hi Andrea,
as far as I understand, you suggest that if a device.map file is present,
you copy it to /a/boot/grub/device.map.image . Moving would be bad,
but copying is fine, so that we have under control whether we provide
a file or not. Guess your're aiming at pre-install scriptlets?
Not exactly. The old device.map is saved + the disk names inside it are
modified according to the disk devices detected/used by SystemImager:
the ##SHOW_DISK_EDITS## and ##EDIT_DISK_NAMES## labels in
etc/autoinstallscript.template are translated in the opportune "sed"
commands when the .master script is created (look at edit_disk_names()
and show_disk_edits() in lib/SystemImager/Server.pm for details).

Anyway, my patch in systemimager doesn't change anything with previous
versions of SC, because device.map is always re-created. With SC 2.2.12
instead it would help to automatically fix device.map when it's present
in the image (with no need of fine-grained manual changes in the
overrides or similar stuff).
Post by Erich Focht
In fact through the overrides one has very fine-grained control on what
would be done on a node with respect to the device.map file, for the case
that the nodes have different types of disks than the golden client.
That's why I saw no real problem with the patch r711. My point was to have
at least some way of disabling the device.map generation (which is
unreliable).
ok.
Post by Erich Focht
I tagged systemconfigurator 2.2.12 but didn't put the RPMs on the download
page, as nobody ever complained about this kind of issue. If no other
patches show up in near future, I'll complete the "release".
ok for me.

-Andrea

Loading...