OEM Rescue/Reimaging
Status
Created: 25/04/2005 by ColinWatson
Priority: MediumPriority
People: ColinWatsonLead, TollefFogHeenSecond
Contributors: ColinWatson, TollefFogHeen
Interested: JeffWaugh
Status: ApprovedSpecification, BreezyGoal, DistroSpecification, MattZimmermanQueue
- Depends: OEMInstaller
UduSessions: 1 (0)
Introduction
Provide a rescue/reimaging method to be supplied with OEM installations.
Rationale
OEMs will want to provide a way for users to return an installed system to a pristine state. This is mainly to reduce support costs as they can ask the user to just return the system to its shipped state and restore data from backup.
Scope and Use Cases
An OEM creates a system image per OEMInstaller, and wants to include a rescue partition on the image which they can tell the end user to use to restore the system to its factory state.
Implementation Plan
The rescue partition will be an Ubuntu installation consisting of the base and standard seeds plus a new oem-rescue seed consisting of desktop infrastructure (preferably without any Ubuntu branding), a rescue application, and perhaps a few other tools such as a graphical partition editor. To prevent users attempting to use the rescue partition for real work, it will normally be mounted read-only with a writable tmpfs, and the desktop seed (including e.g. openoffice.org) has intentionally been omitted.
OEMs requiring this functionality are expected to create a partition of sufficient size (normally using the existing automatic partitioning facilities) designated for use as the rescue partition. An extension to the installer will be written that sets up this rescue partition after installing the normal base system. This will copy the normal base system into the rescue partition and install the standard and oem-rescue seeds. Suitable options will be added to the system's bootloader configuration.
After the OEM has customized the normal system, the OEMInstaller documentation will instruct them to boot the rescue partition with a special parameter that causes it to store an image of the normal system and remember the current partition layout and bootloader configuration.
When the end user boots the rescue partition, it will boot directly into a special desktop session that launches the rescue application. If the partition layout does not match its stored values, it will fail; otherwise, it will ask whether it can restore its saved image, and if so it will proceed to do so (using dd or similar) and then restore the saved bootloader configuration.
Data Preservation and Migration
No data preservation, the user will be told that the hard drive will be wiped and that he should restore from backups.
Packages Affected
New oem-rescue, oem-rescue-udeb packages; bootloader installers. New seed.
User Interface Requirements
The rescue application will probably be written in PyGTK or similar and run inside X. The rescue option should either be in the grub menu (with an appropriate warning) or hook into the BIOS boot sequence similar to how the "ThinkPad button" on IBM laptops work. The application must be very clear about it causing user data to be destroyed permanently and offer to cancel at any point (up to the point where the actual reimaging starts).
Outstanding Issues
Is there anything more sensible we can do if the partition layout does not match the stored values? If that happens, the index of the rescue partition may have changed. We might want to just tell the user that she has modified his system in a way which the system cannot recover from and she should contact support.
UDU BOF Agenda
UDU Pre-Work
Comments
JohnMoser: I've said this many a time, but here is a demonstration of why a separate /home is superior in design. While here the data is lost, a "rescue" mode could wipe / and reinstall. If the user's profile is a problem, he can copy all important data to a shared directory (chmod 01777 /home/shared) or use a home repair tool which could correct issues. For example, "I can't log in: Ubuntu accepts my password but immediately logs me back out" would probably be solved by erasing the GNOME configuration; while a broken Firefox or Thunderbird could be solved by attempting to gently repair the profile or in the worst case store important data (the Mail directory in thunderbird) and wipe the rest of the configuration. Both options can be completed from an OEM LiveCD, and the profile sanitizing option can operate on individual users' home directories. The mentioned sanitizing tool to gently repair individual applications' configurations can be discussed elsewhere.
PaulSladen: on x86, the HPA (Host Protected Area) spec may allow the recovery facilities the the OEM needs without having to worry about the recovery-partition being a normal, visible partition. The specs defines that the AT drives be commanded by the BIOS to return 'fake' information about its true length; thus obscuring the rescue area. The BEER specification allows a number of bootable areas (eg. reinstall OS, make backups, restore backups), each of which is an emulated bootable floppy image in much the same way as a CDROM boots. These can be selected during startup by pressing down a key; the BIOS then commands the IDE device to return its true-capacity when queried, this allows the recovery OS full access to both itself and the rest of the disk where the normal OS will be installed/backed up from.
KarlHegbloom: My vision of a restore/rescue system is a little different. Rather than have it using space on the hard drive, I thought it should be on a set of CD-R or DVD-R. There should be a tool the OEM Installation Technician can run to create the ISO-9660 file system images for that. It would also be very nice if the end-user could use it as a backup solution. I'd like a CD-R that serves as the restore/rescue boot CD, and a separate CD or set of CD's to hold the system image and perhaps partman recipe or other system-specific metadata. It would naturally be based on the Debian Installer and 'partman-auto', allowing the user to change the partitioning layout if desired, so that, for instance, migration from single disc to RAID or restoration to a replacement hard drive can be acheived. The same RR CD would work with any customized system image set, say for each of several computer models in an OEM product line.
- It will use 'dar' to create the file system image after the installation is complete. Dar has several advantages for this application.
- Dar supports extended attributes, eg. for SELinux.
- On archive creation, 'dar' can be asked to skip certain files by extension or location in the file system, so that log files and other (configurable?) cruft can be left out to reduce the size of the archive.
- The 'fstab' should not be in the archive, since the 'partman-auto' should re-create it.
- A separate /home and/or /opt volume can be skipped, and the restoration program should know how to cope with that and leave the old data in place, mounting those file systems on the restored system. It should also support arbitrary other partitions of that nature, for things like /data used by scientists or multimedia artists.
- Dar supports incremental backups, so it may be possible to have a restoration procedure that allows application of incremental backups created by the end-user after base system restoration is complete.
- Dar knows how to break the archive into multiple files. During the restoration procedure, the progress meter can then be updated once for each archive segment. That is much faster than attempting to parse the verbose output of the 'dar' and update the meter once for each file. Many smaller (20 Mb) files are easier to break into maximally filling sets for multiple CD storage.
- Like it or not, some vendors will offer the end user a choice of Linux distributions, and a 'dar' based restoration tool can be independant of the base system distribution. It could just as easily restore a Gentoo system as an Edubutu. If the Ubuntu restore/rescue system is useable even so, perhaps it will put our name on the map in places that otherwise may never have tried Ubuntu?
- Q: Can it be made to support non-Linux OS installed in other partitions? Some OEM are offering dual-boot machines with both Windows XP and Ubuntu Linux pre-installed.
- Having the restore/rescue system on multiple volumes will require that the system be capable of running entirely from RAM, so that the CD disc can be changed during the procedure. This implies something like µbuntu or a specialized Live-CD with a reduced package set, so that it can run in less RAM.
- Given that, it should also be made easily bootable from a USB stick or USB/Firewire hard drive.
The Gentoo-based System Rescue CD supports those features, ostensibly. I could not get it to boot from a USB stick, but the 'cdcache' boot option works flawlessly and allows umounting and changing the compact disc.
PhillipSusi: IIRC libata disables the HPA by default, exposing the full disk. Using it also prevents the user from removing the partition if they so choose. For this reason I do not like the use of HPA. The hidden partition and external media each have their own advantages, so I think it best to have a system that is equally at home in either, and offers to transfer itself to the other. In other words, recreate the restore cd from the hidden partition, or recreate the hidden partition with the restore cd.
By the way, using dump instead of tar or dar may prove beneficial. It seems to be quite a bit faster than tar. An initial level 0 dump could be done during OEM install and provide an emergency base to return to in the event of catastrophe. An option could be included on the grub boot menu to create/update a level 1 backup that the user could choose periodically to update the changes they have made to the system that could be optionally restored or not on top of the base level 0 dump. This level 1 dump could be located on the restore partition, or possibly on external media. In the event of catastrophic restore, the user could be given the choice between restoring to the factory default state of just the level 0 dump, or also including their backed up data in the level 1 dump as well.