[softwaremgmt] dist update with KMPs
Hi, if I have KMPs installed from some driver kit (add-on with registered online update source), and the drivers won't make it to the next product / SP release, then I'll need to upgrade the KMP's add ons alongside the base product. Also, the KMPs (and the base products) need to be updated alongside the kernel, before a reboot, because after reboot without KMP update, the new kernel may fail to access the repos (network) or the disk (storage) or the display device (graphics). Will this be fixed / work with 11.1? Where can I find info on how the integrated upgrade of base distro with add-ons is planned? S. -- Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business OPS Engineering Maxfeldstraße 5 Processes and Infrastructure Nürnberg SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
Hi, thx to some kind pointer off-list I found and checked http://en.opensuse.org/Product_Management/Code11/Upgrade This all looks great as long as you don't depend on an add-on with KMPs (aka driver kit) to get your machine booting. In that case a few things need to be addressd: - The inst source and the KMPs need to be protected from incidential force-deinstallation. They are not outdated per se, only if they are obsoleted explicitely. btw, in general the assumption that a package shall be removed if it has no successor will silently remove functionality. The user then has no choice to tell that he was not aware of this implication. So if some packages need to be removed for a dist-update, then there needs to be some mechanism that checks back with the user wether this really is what she wants (ovverridable with some '--yes-to-uninstalls'). - There needs to be a way to migrate several repos in one step simultanously, so the kernel and the KMPs get updated in one single step, before reboot. This simultaneous migration of base product and add-ons must not depend on an interactive tool, else it will not meet larger deployment's need for unattendend, prescheduled maintenance mass roll-outs. I can put this as known gaps into the wiki but I wanted to check back here before I touch that page. S. full quote below as it's been a while... Susanne Oberhauser <froh@novell.com> writes:
Hi,
if I have KMPs installed from some driver kit (add-on with registered online update source), and the drivers won't make it to the next product / SP release, then I'll need to upgrade the KMP's add ons alongside the base product.
Also, the KMPs (and the base products) need to be updated alongside the kernel, before a reboot, because after reboot without KMP update, the new kernel may fail to access the repos (network) or the disk (storage) or the display device (graphics).
Will this be fixed / work with 11.1? Where can I find info on how the integrated upgrade of base distro with add-ons is planned?
S.
-- Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business OPS Engineering Maxfeldstraße 5 Processes and Infrastructure Nürnberg SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
* Susanne Oberhauser <froh@novell.com> [Sep 26. 2008 16:09]:
Hi,
thx to some kind pointer off-list I found and checked http://en.opensuse.org/Product_Management/Code11/Upgrade
This all looks great as long as you don't depend on an add-on with KMPs (aka driver kit) to get your machine booting.
Well, if you need a driver for _booting_, driverupdate (aka 'dud') is your friend: http://en.opensuse.org/Linuxrc#p_driverupdate
In that case a few things need to be addressd:
- The inst source and the KMPs need to be protected from incidential force-deinstallation. They are not outdated per se, only if they are obsoleted explicitely.
Not quite. A package will be removed if its dependencies cannot be fulfilled any longer. Any kernel driver has a rather high probability of broken dependencies on a distribution upgrade.
btw, in general the assumption that a package shall be removed if it has no successor will silently remove functionality. The user then has no choice to tell that he was not aware of this implication.
The 'to be removed' packages are explicitly listed.
So if some packages need to be removed for a dist-update, then there needs to be some mechanism that checks back with the user wether this really is what she wants (ovverridable with some '--yes-to-uninstalls').
There is little value in keeping a binary package with broken dependencies installed ;-) The 'override' is to lock the package explicitly. But the binary/driver won't work anyways.
- There needs to be a way to migrate several repos in one step simultanously, so the kernel and the KMPs get updated in one single step, before reboot.
The update stack in 11.1 / SLE11 supports 'services', a collection of repositories. See http://duncan.mac-vicar.com/blog/archives/351 However, this requires knowledge of old and new repositories which is hard to collect.
This simultaneous migration of base product and add-ons must not depend on an interactive tool, else it will not meet larger deployment's need for unattendend, prescheduled maintenance mass roll-outs.
I think everyone working on the update stack is very aware of this fact.
I can put this as known gaps into the wiki but I wanted to check back here before I touch that page.
Please do touch the wiki so questions and gaps can be answered and documented there persistently. Klaus -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
Klaus Kaempf <kkaempf@suse.de> writes:
* Susanne Oberhauser <froh@novell.com> [Sep 26. 2008 16:09]:
Hi,
thx to some kind pointer off-list I found and checked http://en.opensuse.org/Product_Management/Code11/Upgrade
This all looks great as long as you don't depend on an add-on with KMPs (aka driver kit) to get your machine booting.
Well, if you need a driver for _booting_, driverupdate (aka 'dud') is your friend: http://en.opensuse.org/Linuxrc#p_driverupdate
For initial install, I agree. For an update, I don't understand: the driver kit update is available online, in parallel to the the base product: SLE GA -> SLE SP1 driver kit for SLE GA -> driver kit for SLE SP1 If the kernel and the drivers are updated in one run, then there is no need for a DUD. So why are you mentioning a DUD in a discussion of a system update? Btw, I have well understood that with the workflow we have, it may be needed. However as scetched above I believe this is something we could change if we wanted to.
In that case a few things need to be addressd:
- The inst source and the KMPs need to be protected from incidential force-deinstallation. They are not outdated per se, only if they are obsoleted explicitely.
Not quite. A package will be removed if its dependencies cannot be fulfilled any longer. Any kernel driver has a rather high probability of broken dependencies on a distribution upgrade.
Yah. For exactly that reason there should be no update unless there is an update for the KMP that resolves them.
btw, in general the assumption that a package shall be removed if it has no successor will silently remove functionality. The user then has no choice to tell that he was not aware of this implication.
The 'to be removed' packages are explicitly listed.
Which is good. However what I'm talkign about is the following current siutation: SLE GA + some driver kit for SLE GA is updated to SLE SP1 without driver kit and then 'somehow' you need to get that to SLE SP1 + driver kit for SP1 What I'm proposing is to update the registered repos for base product and add-ons in _one_ step, and then to update the packages for all updated repos in one second step, and to only reboot after all packages have been updated: SLE GA + some driver kit for SLE GA is updated to SLE SP1 + driver kit for SP1 in 'one' step.
So if some packages need to be removed for a dist-update, then there needs to be some mechanism that checks back with the user wether this really is what she wants (ovverridable with some '--yes-to-uninstalls').
There is little value in keeping a binary package with broken dependencies installed ;-)
There is even less value in rendering a system unbootable with a kernel update that removes driver ;)
The 'override' is to lock the package explicitly. But the binary/driver won't work anyways.
Indeed :D So that's not a solution ;) Have we ever considered refining the 'package locking' into 'remember what the user wanted'? i.e. wich resolvables did the user ever explicitely select and which ones were autogenerated? Now as having the system and it's components accessible to me seems like something desirable in gneral, I'd lift driver kits that were registered by Jockey into the class of 'explicitely selected resolvables', too. Then a Release n+1 migration will only succeede once all the driver kits can also me migrated. Or the user explicitely deselects the driver kits, and that can then come with a warning 'if you remove this instsource, you may loose hardware functionality'. that would be more helpfull than the current package level locking, and it would also be more helfull than the current long list of packages that will be removed now.
- There needs to be a way to migrate several repos in one step simultanously, so the kernel and the KMPs get updated in one single step, before reboot.
The update stack in 11.1 / SLE11 supports 'services', a collection of repositories. See http://duncan.mac-vicar.com/blog/archives/351
However, this requires knowledge of old and new repositories which is hard to collect.
If the SLE GA repo gets an optional patch which updates to the next SP, then the driver kit's repo can get a corresponding patch that migrates to the driver kit's successor. The two migration patches can be linked via Is Required For. All this needs is an explicit, reliable mechanism to update repos with a patch.
This simultaneous migration of base product and add-ons must not depend on an interactive tool, else it will not meet larger deployment's need for unattendend, prescheduled maintenance mass roll-outs.
I think everyone working on the update stack is very aware of this fact.
Good. Just mentioning it as I only read about an interactive tool.
I can put this as known gaps into the wiki but I wanted to check back here before I touch that page.
Please do touch the wiki so questions and gaps can be answered and documented there persistently.
Will do. thx S. -- Susanne Oberhauser +49-911-74053-574 SUSE -- a Novell Business OPS Engineering Maxfeldstraße 5 Processes and Infrastructure Nürnberg SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
* Susanne Oberhauser <froh@novell.com> [Oct 04. 2008 00:32]:
Klaus Kaempf <kkaempf@suse.de> writes:
* Susanne Oberhauser <froh@novell.com> [Sep 26. 2008 16:09]:
Hi,
thx to some kind pointer off-list I found and checked http://en.opensuse.org/Product_Management/Code11/Upgrade
This all looks great as long as you don't depend on an add-on with KMPs (aka driver kit) to get your machine booting.
Well, if you need a driver for _booting_, driverupdate (aka 'dud') is your friend: http://en.opensuse.org/Linuxrc#p_driverupdate
For initial install, I agree.
For an update, I don't understand: the driver kit update is available online, in parallel to the the base product:
SLE GA -> SLE SP1 driver kit for SLE GA -> driver kit for SLE SP1
Right, thats the ideal case when a (3rd party) driver is available with SP1.
If the kernel and the drivers are updated in one run, then there is no need for a DUD.
If you do the update in the running system, there is no need for a DUD.
So why are you mentioning a DUD in a discussion of a system update?
If you update by booting from a DVD, you might need a DUD.
The 'to be removed' packages are explicitly listed.
Which is good.
However what I'm talkign about is the following current siutation:
SLE GA + some driver kit for SLE GA
is updated to
SLE SP1 without driver kit
This update will not work. Except if you explicitly remove the drivers with broken dependencies.
and then 'somehow' you need to get that to
SLE SP1 + driver kit for SP1
What I'm proposing is to update the registered repos for base product and add-ons in _one_ step, and then to update the packages for all updated repos in one second step, and to only reboot after all packages have been updated:
SLE GA + some driver kit for SLE GA
is updated to
SLE SP1 + driver kit for SP1
in 'one' step.
Thats what the upgrade process is trying to do. Ideally, NCC knows your system and reports all repositories needed for a successful SP migration. However, this will only work with driver repositories we know (resp. have control over). If a customer has additional driver repositories added (or some repositories don't have SP1 drivers available), this 'one step' scenario will break.
Have we ever considered refining the 'package locking' into 'remember what the user wanted'?
i.e. wich resolvables did the user ever explicitely select and which ones were autogenerated?
Yes.
Now as having the system and it's components accessible to me seems like something desirable in gneral, I'd lift driver kits that were registered by Jockey into the class of 'explicitely selected resolvables', too.
Drivers might be automatically installed due to hardware dependencies (http://en.opensuse.org/Software_Management/Dependencies/Hardware).
Then a Release n+1 migration will only succeede once all the driver kits can also me migrated.
Right.
Or the user explicitely deselects the driver kits, and that can then come with a warning 'if you remove this instsource, you may loose hardware functionality'.
that would be more helpfull than the current package level locking, and it would also be more helfull than the current long list of packages that will be removed now.
This requires knowledge about which package came from which repository. The just introduced 'package logging' provides this functionality.
- There needs to be a way to migrate several repos in one step simultanously, so the kernel and the KMPs get updated in one single step, before reboot.
The update stack in 11.1 / SLE11 supports 'services', a collection of repositories. See http://duncan.mac-vicar.com/blog/archives/351
However, this requires knowledge of old and new repositories which is hard to collect.
If the SLE GA repo gets an optional patch which updates to the next SP, then the driver kit's repo can get a corresponding patch that migrates to the driver kit's successor.
For driver repositories controlled by Novell, yes, this can work. For other 3rd party repositories, its up to the customer to track down the correct drivers. (And push the driver vendor to get the driver upstream ;-)). Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-softwaremgmt+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-softwaremgmt+help@opensuse.org
participants (2)
-
Klaus Kaempf -
Susanne Oberhauser