Drop iscsi initrd generation hack, it is not longer needed now that the
kernel.spec does initrd generation with %posttrans
---
backend.py | 15 +--------------
1 files changed, 1 insertions(+), 14 deletions(-)

diff --git a/backend.py b/backend.py
index 6ca14a8..f1364b2 100644
--- a/backend.py
+++ b/backend.py
@@ -81,23 +81,10 @@ class AnacondaBackend:
log.error("Could not copy firmware file %s: %s" % (f, e.strerror))

def doPostInstall(self, anaconda):
- has_iscsi_disk = False
-
- # See if we have an iscsi disk. If we do we rerun mkinitrd, as
- # the initrd might need iscsi-initiator-utils, and chances are
- # it was not installed yet the first time mkinitrd was run, as
- # mkinitrd does not require it.
- root = anaconda.storage.rootDevice
- disks = anaconda.storage.devicetree.getDevicesByType("iscs i")
- for disk in disks:
- if root.dependsOn(disk):
- has_iscsi_disk = True
- break
-
#always copy the firmware files from DD
self.copyFirmware(anaconda)

- if anaconda.extraModules or has_iscsi_disk:
+ if anaconda.extraModules:
for (n, arch, tag) in self.kernelVersionList(anaconda.rootPath):
packages.recreateInitrd(n, anaconda.rootPath)

--
1.7.0

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

On 03/05/2010 10:38 AM, Hans de Goede wrote:

Drop iscsi initrd generation hack, it is not longer needed now that the
kernel.spec does initrd generation with %posttrans
---


Ack.

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

On Fri, 2010-03-05 at 10:38 +0100, Hans de Goede wrote:
> Drop iscsi initrd generation hack, it is not longer needed now that the
> kernel.spec does initrd generation with %posttrans

> - # See if we have an iscsi disk. If we do we rerun mkinitrd, as
> - # the initrd might need iscsi-initiator-utils, and chances are
> - # it was not installed yet the first time mkinitrd was run, as
> - # mkinitrd does not require it.
> - root = anaconda.storage.rootDevice
> - disks = anaconda.storage.devicetree.getDevicesByType("iscs i")
> - for disk in disks:
> - if root.dependsOn(disk):
> - has_iscsi_disk = True
> - break
> -

This only works if the install is guaranteed to happen in the same
transaction. As we have discussed elsewhere, this is only true if you
have a single media of whatever type and the package layout is
consistent. I'm sure this is probably fine, but before lots of this
happens it might be worth codifying what guarantee of transactions and
ordering is actually being given.

For example, if Anaconda will always undertake to install "certain
kernel related stuff from this comps group" at the same time, and if the
comps are smart enough to have the media laid out just right, cool. If
however, this might break on CD installs because ordering could randomly
change, then, not so cool.

Jon.


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

Hi,

On 03/05/2010 09:22 PM, Jon Masters wrote:

On Fri, 2010-03-05 at 10:38 +0100, Hans de Goede wrote:

Drop iscsi initrd generation hack, it is not longer needed now that the
kernel.spec does initrd generation with %posttrans



- # See if we have an iscsi disk. If we do we rerun mkinitrd, as
- # the initrd might need iscsi-initiator-utils, and chances are
- # it was not installed yet the first time mkinitrd was run, as
- # mkinitrd does not require it.
- root = anaconda.storage.rootDevice
- disks = anaconda.storage.devicetree.getDevicesByType("iscs i")
- for disk in disks:
- if root.dependsOn(disk):
- has_iscsi_disk = True
- break
-


This only works if the install is guaranteed to happen in the same
transaction. As we have discussed elsewhere, this is only true if you
have a single media of whatever type and the package layout is
consistent. I'm sure this is probably fine, but before lots of this
happens it might be worth codifying what guarantee of transactions and
ordering is actually being given.



Good point, thanks for pointing this out, this is definitely something
to keep in mind.

Note though that this was the only hack of this kind, the move to
posttrans of initrd generation was done to avoid needing a similar hack
for multipath.

Removing the iscsi hack means that we now treat iscsi, fcoe and multipath
the same (they now all depend on the needed packages being there when
posttrans runs).

Still this is a very valid remark, and something to watch. If this causes
issues we need to hardcode things in the disk splitting so that
the iscsi, fcoe and multipath tools end up on the first disk.

Regards,

Hans

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list