Mailinglist Archive: opensuse-bugs (15063 mails)

[bugzilla_noreply@xxxxxxxxxx]

https://bugzilla.novell.com/show_bug.cgi?id=309837#c34





--- Comment #34 from Olaf Dabrunz <odabrunz@xxxxxxxxxx>  2007-09-14 12:48:19 MST ---
This comment addresses the problems of the wrong device names and the wrong
default section.

coolo@, your theory is correct.

In short, perl-Bootloader expects a fairly consistent view of the system for
the information it needs. This includes that /etc/fstab,
/boot/grub/device.map and the output of udevinfo all present a consistent
view to perl-Bootloader.

But we have the libata migration, and some parts of the system already use
the information about the new devices (udevinfo, because we have
bind-mounted the devices from the inst-sys which runs the new kernel), other
parts will only be migrated to the new device names at the end of the
installation (including /etc/fstab and /boot/grub/device.map).


Possible solutions:

We can either solve this by correcting the information in the system early
during the update or by updating the bootloader configuration late (in
yast2-bootloader, as we did before).

1) Some suggestions have been made to correct the information in the system
   early, such as:

    a.1) Moving(/copying/calling) the libata migration code of yast2-storage
       and yast2-bootloader into some yast client that runs directly before
       package installation starts (e.g.
       packager/src/clients/inst_kickoff.ycp).

        - This requires that this code does not need a consistent system
          view itself.

          AFAICS it may just work in this case, as we mainly need to know
          the version of the system before the update and the version of the
          system after the update to find the correct pre-configured mapping
          of device names for this case.

          Anyhow the code needs to be adapted to this special case, so that
          e.g. the device.map libata migration code does not try to find the
          BIOS device for that device, because then at least an up-to-date
          yast2-storage, libstorage, hwinfo, a working /sys tree and who
          knows what (e.g. evms-to-BIOS-device mapper?) are required in
          the target system.

    a.2) Porting/re-implementing the libata migration code of yast2-storage
       and yast2-bootloader in some script that can be called from
       pre-/post-install code that needs it, and from YaST.

        - Same requirements as in a.1).

    b) Using callbacks into YaST-code, e.g. from pre-/post-install scripts,
       to make the parts of the system consistent that are required to run
       the rest of the code in the pre-/post-install scripts.

        - This requires that routines in the running YaST are callable from
          the outside, specifically from code running on the target system.

          ATM, this is not designed or implemented.

        - Callback code needs to be written.

    c) Calling pre-/post-install hooks from yast2-installation: YaST modules
       could then register pre-/post-install handlers for specific packages
       with yast2-installation, and set up a consistent system view as
       required by these packages.

        - This requires support for these hooks from yast2-installation.

          ATM, this is not designed or implemented.

        - Callback code needs to be written.


   All these approaches require that

    - packages required to execute the pre-/post-install scripts are known
      and specified as dependencies in the to-be-installed package and

    - the steps to have a running environment for each of these packages are
      known and it is clear how to set this up in the target system (e.g.
      for hwinfo have a /sys file system mounted (at the adequate place) in
      the target system).


Altogether, these approaches add several requirements to YaST, packaging,
maintaining special code and variants of existing code, etc. And these
concepts and methods are not even tried and tested, conceptually simple or
known to work.

These are new concepts and new features, so I do not see how we can fix the
problem in this way for 10.3.

I have been asked before what problems I would see when the
post-installation of the kernel executes perl-Bootloader during an update.
Unfortunately, as I do not have documentation myself to refer to *), my
answer was rather incomplete: "I would really not do this, as I do not know
which things do not work during installation or update." and "The system
configuration is not consistent during package installation or update." **)

Please take this as a more complete answer.


*) We really need more documentation about workflows, information flows and
   implementation. Otherwise we keep forgetting things ourselves. This is
   really something we need to put more time into, but this unfortunately
   has not been possible so far. Big Problem (TM), it would save us a lot of
   work and at least half of the mess.

**) As far as YaST is concerned, the system configuration state during
   package installation was not expected to be consistent. Rather, YaST
   needed to assume that the system configuration would only stabilize when
   package installation was finished (and this is currently the policy of
   YaST). This was especially true during the time when files were moved
   between packages, dependencies changed and lots of code in YaST, in
   package pre-/post-installation scripts, system rc scripts, hwinfo, HAL
   and the like was changing quickly, dramatically and at the same time.

   Maybe today the situation is somewhat more stable, and we can actually
   start to rely on interdependencies during the package installation
   workflow. If this is the case, we have a chance to introduce and document
   some sort of installation staging, so each package knows roughly when it
   is installed and what state of the system it can expect and rely on.

   Also, during the first years the YaST license did not allow others to
   reuse YaST or YaST code. That seems to be one of the reasons why YaST was
   not called back from package installation scripts: this would tie the
   installation of these packages too tightly to the SUSE-owned YaST.

   But now that YaST is Open Source, it may be possible to integrate it
   better with package installation scripts in one or the other way.

   AFAIK, making YaST code callable from the outside is actually a wanted
   feature.

   If we can go in that direction, we could make it possible to do such
   things like concentrating section removal and creation code in
   perl-Bootloader (which would actually help maintainability).



2) Updating the bootloader configuration late (in yast2-bootloader, as we
   did before).

   This means that we do not call perl-Bootloader (bootloader_entry,
   update-bootloader) from the postinstall-script during an installation or
   update any more, but let yast2-bootloader adjust the configuration.

   The only problem here is that we now loose the information about the
   previous default kernel flavour, because the section for the old
   (oS 10.2) kernel will be deleted by the postuninstall script of the old
   kernel (which is OK, this can always be done without real problems).

   To keep this information, we need perl-Bootloader to save the default
   flavour somewhere, so yast-bootloader can try to make the same flavour of
   kernel the default when it needs to make that decision.

   I would suggest to introduce a new comment into menu.lst:

        ### YaST: default kernel flavour: bigsmp ###

   perl-Bootloader would save this comment whenever it removes a default
   section. yast2-bootloader would use this comment during an update only,
   and fall back to a builtin list as in: if it exists use "bigsmp",
   otherwise "default".

   This requires some changes in perl-Bootloader and in yast2-bootloader. I
   believe this should not be difficult and it could be finished in a few
   days (with the help of aosthof@ from Monday).


So I believe solution 2 is what we need to do. duwe@ and sf@ have acked
this. Implementing...


-- 
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.