|Deletions are marked like this.||Additions are marked like this.|
|Line 53:||Line 53:|
|* `yaboot` uses a system path to the device, and does not need modification.||* `yaboot` uses a system path to the device, and does not need urgent modification in order for the system to keep booting; however, the `boot=` and `root=` lines in `/etc/yaboot.conf` need to be updated.|
Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/libata-for-all-ata-disks
Packages affected: linux-source-2.6.17, udev, partman-target, base-files, grub, lilo, yaboot, silo, palo, elilo
Replace the existing PATA storage drivers in the IDE subsystem with libata-pata drivers which expose the devices through the SCSI subsystem, and migrate users to using mounting by UUID to allow for changes in either direction.
The success of libata for SATA support has resulted in Alan Cox working to port the existing IDE subsystem drivers to libata as well. This will eventually result in us having to only cope with one "storage" subsystem and make our lives somewhat simpler. In a gesture of being good community members, we can offer Alan wide-spread testing for his code by deploying it in our development release and make a positive contribution to the community.
Alan Cox's patches are available from http://zeniv.linux.org.uk/~alan/IDE/ and will be applied to our kernel; we will disable any of the drivers that appear to be completely missing or unsupported and leave enabled those that are well-tested or for which we can give mass testing.
In particular, ide-generic can be disabled in favour of the libata-pata legacy support.
If significant problems occur before release, the drivers can be disabled and the existing IDE subsystem ones used.
The scripts run by udev in the initramfs are largely driver-independant, and will automatically load the correct driver after the migration. The only change will be the name of the legacy driver we load.
When installing new systems, partman-target will write the UUID of the partitions to /etc/fstab with a comment above giving the name of the device as the installer saw it. The generated fstab would then look something like:
proc /proc proc defaults 0 0 # /dev/hda1 UUID=0080a51f-df64-4932-8ce4-ee1d9b520708 / ext3 defaults,errors=remount-ro 0 1 /dev/hda5 none swap sw 0 0
Existing install migration
When a user updates their system, the postinst of base-files will rewrite the /etc/fstab file to match that which the installer would have written. The first version of the kernel to ship with the patch applied will depend on this version of base-files to ensure that the migration has happened.
This will work because the migration is performed on the old kernel while the disk information is still available in the right form, the UUID can be obtained using vol_id on the /dev/hdXY device.
Boot loaders need to update their configurations so that they pass root=UUID=$UUID to the kernel for the root filesystem, which initramfs-tools supports. They may also need to update the install device if they require such things, as noted below:
grub infers the install device.
yaboot uses a system path to the device, and does not need urgent modification in order for the system to keep booting; however, the boot= and root= lines in /etc/yaboot.conf need to be updated.
others require modification to use the appropriate /dev/disk/by-uuid/$UUID symlink.
To ensure this is performed before the kernel is upgraded, and to correct [https://launchpad.net/bugs/43531 the problem of being able to have a kernel without a bootloader], all bootloaders will provide a linux-boot-loader virtual package. The kernel will depend on this, and declare conflicts (or breaks, when implemented) versions older than necessary boundaries.
While the author of the patch is somebody with a great deal of knowledge, there's obviously some amount of potential for things to go horribly wrong. People should be warned by a mail to ubuntu-devel-announce which IDE drivers are moving to libata in edgy, and request that people test those if they don't mind losing their filesystem.
The mail would also suggest that people make sure their backups are fully up to date, in case of critical failure, and make sure that they report the problem with full debugging information (which we can then provide to Alan).
For those who are unwilling to sacrifice their filesystem it would be strongly recommended that they avoid edgy or the new kernels for the time being.
Should things go badly, the patch will be disabled for the problem drivers and edgy released with the ordinary IDE subsystem drivers.