Upgrading preloaded Ubuntu to the next Ubuntu release
Today you can buy a computer preloaded with Ubuntu from many different vendors. The OS image used at the factory is often modified to provide better hardware support. It may also contain customizations such as additional bookmarks or applications. As a result of these customizations, the upgrade path to the next version of Ubuntu is not as clean as it could be.
Blueprint information
- Status:
- Not started
- Approver:
- Kate Stewart
- Priority:
- Undefined
- Drafter:
- Steve Magoun
- Direction:
- Needs approval
- Assignee:
- Steve Magoun
- Definition:
- New
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Whiteboard
Work items:
[smagoun] dkms enhancements to ensure dkms modules can be obsoleted by new upstream kernels
[smagoun] Investigate alternatives framework for launching applications instead of hardcoded .desktop files
[smagoun] Investigate making preload images available to the community
[smagoun] Discuss upgrade blacklists with mvo for systems that aren't supported in newer versions of Ubuntu
== Session Notes ==
Focus of discussion is on upgrading preloaded versions of Ubuntu (primarily dist-upgrades but also normally upgrades). Preloaded versions of Ubuntu may be customized (both via packages specific to the project and more rarely customizations of packages that also exists in Ubuntu). We want the upgrade experience to be as seemless as possible notwithstanding.
Define: What is a clean upgrade of Ubuntu for preloaded units?
* System continues to pass certification requirements.
* No regressions of customizations (e.g. desktop icons still work)
Out of scope:
* New bugs and regressions in the newer version of Ubuntu itself.
* Improvements to upgrade experience (e.g. not going to try and prevent debconf questions, etc).
Classes of problems:
1. Customized version of an Ubuntu package
* New version in preload, newer version in Ubuntu: customizations may get lost during upgrade
Possible Solution: Push customizations into Ubuntu
2. Need a patched driver that is already upstream or process of being upstreamed. Functionality in DKMS to indicate a DKMS module has been obsoleted is non-functional/
Possible Solution: Another session tackling this. ( https:/
3. Removing dependencies upstream in Ubuntu can break customized packages downstream
Possible Solution: Review changes list and add Release Notes alerting users
4. Package name transitions
- e.g. preinstalled desktop icons which become invalid (ooffice -> libreoffice). This is a broader problem for user-created .desktop files.
Possible Solution: rather than launch of specific applications, use the alternatives framework to launch the generic type of application.
5. Hardware loses support (e.g. Poulsbo graphics). Can the system be blacklisted for upgrade and the user informed?
6. Disk space - what extra considerations should be given here?
Testing:
* Canonical typically has access to the hardware and so can test upgrades - expensive in QA time but desirable.
* Some aspects are hard to automate (e.g. testing external audio)
* Can we give them the preload image to get help from community with testing who has hardware?
* May have to develop a process to rip out the royalty bearing bits
