##(see the SpecSpec for an explanation) * '''Launchpad Entry''': https://launchpad.net/distros/ubuntu/+spec/libata-for-all-ata-disks * '''Created''': <> by AndersKarlsson * '''Contributors''': BenCollins, ScottJamesRemnant, ColinWatson, AdamConrad, JeffBailey, AndersKarlsson * '''Packages affected''': linux-source-2.6.17, udev, partman-target, base-files, grub, lilo, yaboot, silo, palo, elilo == Summary == 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. == Rationale == 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. == Design == 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. == Implementation == === udev === 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. === Installer === 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-loader migration === 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. == Data preservation == 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. ---- CategorySpec