https://bugzilla.novell.com/show_bug.cgi?id=309837#c34
--- Comment #34 from Olaf Dabrunz 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.