missing dmraid support needed to access SATA raids

Hi Phillip,
thanks for the investigation (that i would have to do myslef given i just got
such hardware).

I confirm that dmraid does the trick and indeed works, but we will have to see
how it can be
integrated into the installer and possibly into initramfs. At the moment
upstream doesn't
support the latter. I will see anyway if i can get a binary into the archive before
Breezy releases.

Fabio

Ok i uploaded dmraid to the archive. The code is still marked as sort of
experimental, so
i will not suggest it's inclusion in main or any CD for now.

In any case you will be able to install it from the universe archive and it will
work out of the box.
No fancy scripts are required by the user. The raid devices will be initialized
at boot automatically.

Also .. we will keep this bug open to track the integration during dapper.

Fabio

I'm glad that you added a package for this and that it helped you get your
system working. I found that dmraid currently has a bug where it seems to
assume a stripe size of 16 KB. I had used a stripe size of 64 KB when I built
my array last year so I had to manually reconfigure the stripe size with dmsetup
to get it working.

I'm reporting the bug to the maintainers of dmraid so hopefully it will get fixed.

Now I'm trying to figure out how to get ubuntu installed, seeing as how the
setup cd does not contain dmraid, and neither does the initfs. Hopefully the
next release of ubuntu will have this built in.

They just released a new version this morning ( 1.0.0.rc9 ) that seems to have
fixed the bug. Simply running dmraid -ay now correctly sets up the raid mapper
device.

I'm now in the process of attempting to resize my NTFS partition and manually
installing ubuntu from the livecd.

I added bug 22524 as blocking this bug. Getting ubuntu installed doesn't do
much good when lilo won't install.

As an update, I added the dmraid utility to the initramfs that the ubuntu kernel
package installed by extracting the cpio archive, adding the file, and a script
to invoke it, and repacking the cpio archive. I believe this should make it
work when booted.

I was not able to figure out how to customize mkinitramfs to build a new
initramfs with the dmraid utility included. Maybe someone else can help with that?

(In reply to comment #5)
> I added bug 22524 as blocking this bug. Getting ubuntu installed doesn't do
> much good when lilo won't install.
>
> As an update, I added the dmraid utility to the initramfs that the ubuntu kernel
> package installed by extracting the cpio archive, adding the file, and a script
> to invoke it, and repacking the cpio archive. I believe this should make it
> work when booted.

It won't work. dmraid build on top of klibc is not working yet.

Fabio

(In reply to comment #4)
> They just released a new version this morning ( 1.0.0.rc9 ) that seems to have
> fixed the bug. Simply running dmraid -ay now correctly sets up the raid mapper
> device.
>
> I'm now in the process of attempting to resize my NTFS partition and manually
> installing ubuntu from the livecd.

It is already in the archive as we speak. Upstream delayed the release to merge
a bunch
of patches from us.

Fabio

(In reply to comment #6)
> It won't work. dmraid build on top of klibc is not working yet.
>
> Fabio

I still don't quite get klibc. It sounds to me more like it is a smaller
version of libc so is handy for building small initramfs, but is not required to
build a working initramfs. I went ahead and put it in my initramfs image only
the kernel does not seem to be using the initramfs. What do you have to pass
boot= as to tell the kernel to use the initramfs? I have lilo configured for
initrd=/boot/my_initramfs and when the kernel starts up, it reports a ram disk
found at block 0, but then panics saying it can't mount the root device.

Err, I meant root= not boot=

(In reply to comment #8)
> I still don't quite get klibc. It sounds to me more like it is a smaller
> version of libc so is handy for building small initramfs, but is not required to
> build a working initramfs. I went ahead and put it in my initramfs image only
> the kernel does not seem to be using the initramfs. What do you have to pass
> boot= as to tell the kernel to use the initramfs? I have lilo configured for
> initrd=/boot/my_initramfs and when the kernel starts up, it reports a ram disk
> found at block 0, but then panics saying it can't mount the root device.

(In reply to comment #8)
> (In reply to comment #6)
> > It won't work. dmraid build on top of klibc is not working yet.
> >
> > Fabio
>
> I still don't quite get klibc. It sounds to me more like it is a smaller
> version of libc so is handy for building small initramfs, but is not required to
> build a working initramfs. I went ahead and put it in my initramfs image only
> the kernel does not seem to be using the initramfs. What do you have to pass
> boot= as to tell the kernel to use the initramfs? I have lilo configured for
> initrd=/boot/my_initramfs and when the kernel starts up, it reports a ram disk
> found at block 0, but then panics saying it can't mount the root device.
>
>

This is going way offtopic for this bug. klibc is sort of a smaller glibc, but
different
implementation. The kernel does use initramfs. The error you get is because the
image
you created is borken.

Anything else should move to ubuntu support mailing list.

Fabio

Fabio, I am not sure why you keep bringing up klibc, it doesn't even seem to be
used in the existing ubunto initramfs. It has the standard libc in /lib.
Anyhow, I got the system working. It turned out that the kernel wants the cpio
archive in newc format, but cpio defaults to using bin format, so the kernel
simply ignored it.

What I did was place the dmraid binary in /bin of the initramfs, and added a
script to scripts/local-top named dmraid which just does a modprobe to load the
mapper device driver, then calls dmraid -ay to discover the raid.

I am not sure how to modify mkinitramfs to do this automatically, maybe you know?

Anyhow, as for getting ununtu to support this, it seems like it doesn't take
much. This is what I've got so far:

1) add the dmraid utility to the setup/livecd and have it invoked during init to
discover any devices.
2) add the dmraid utility to the initramfs packages
3) fix gparted so it can correctly manipulate these disks. See the related bug.
4) lilo. This is a bit complex. See the related bug on the subject.

dmraid is packaged and working. Next step will be to get dmraid in the initramfs.
After that please reassign the bug to debian-installer for integration.

Fabio

> I am not sure how to modify mkinitramfs to do this automatically, maybe you know?

I need to document this more clearly, but the initramfs-tools have a collection
of hooks that will solve your problem. While there's no way that Breezy could
do this in the install, we could certainly include the scripts in the package
(Especially if you're willing to test them to make sure they work! *g*)

There are two phases that need to be accounted for. The first is the install
phase for generating the initramfs, the second is run-time phase for actually
doing the needed magic.

To install the components you need, look at the scripts in
/usr/share/initramfs-tools/hooks. evms and acpid are good choices. You can see
a bunch of header stuff at the top that basically guarantees that things are run
in the right order if they need to be. Two functions that will interest you:

copy_exec copies a binary and any libraries it depends on
manual_add_modules takes bareword module names (like fan, thermal, etc) and
installs those modules and any of their dependancies into the initramfs.

The runtime phase is handled by scripts in /usr/share/initramfs-tools/scripts/
you probably want to start up at about the same point as lvm, md, and evms do,
so local-top is a good directory to look in.
You can see the same sort of magic at the top of the script, although lvm and
evms each require that md run first.

I hope this helps. I'll paste this text into a HACKING file on the hopes that
someone will see fit to improve it. That person will probably be me, mind you... =)

Tks,
Jeff Bailey

Created an attachment (id=4241)
dmraid hook file for initramfs-tools/hooks/dmraid

Created an attachment (id=4242)
dmraid script for initramfs-tools/scripts/local-top

Ok, here are the scripts I added to make it work. They probably need cleaned
up, but it works for me.

(From update of attachment 4241)
#!/bin/sh
# copied from /usr/share/doc/initramfs-tools/examples/example_hook

# no pre-requirements
PREREQ=""

prereqs()
{
 echo "$PREREQ"
}

case $1 in
# get pre-requisites
prereqs)
 prereqs
 exit 0
 ;;
esac

. /usr/share/initramfs-tools/hook-functions

if [ -x /sbin/dmraid ]; then
 copy_exec /sbin/dmraid sbin
fi

manual_add_modules dm-mod
exit 0

That did not quite do what I wanted it to. That last comment was supposed to
update the attached script.

I have updated the dmraid package with the proper scripts to integrate with the initramfs, and uploaded to REVU. Please check the changes and upload to the universe.

I believe the next step is to udebify the package then integrate it with the installer, is this correct?

This hook makes sure also the dm-mod and dm-mirror modules get copied to the initrd.

This one makes sure also dm-mirror (for RAID-1 mirrors) gets loaded from initrd at boot.

Removed "breezy" from the title since this is the same in dapper.

BTW the newest dmraid 0.9.9+1.0.0.rc9-2 does not have any hooks. Why, are Phillip's patches still not in yet?

Also, doesn't this bug belong to dmraid (and debian-installer) rather than initramfs-tools?

Sorry for the poor QA. This one actually works.

Me needs sleep. (how can I delete attachments in launchpad?)

Fixed "prereq" dependency on udev.

Thank you for the scripts. I use them to boot on my raid1 (on a Sil controller).

The only problem I had was that, after an upgrade (aptitude upgrade) of some packages (I don't remember which exactly). I rebooted my system and I got an error "Cannot find root file system"...

From busybox, I looked around and started "dmraid -ay" manually. I could boot from there.

At first I thought that the script file was removed from the initramfs folder but that wasn't the case...

I updated the script (new version 2006-03-24) and did a "dpkg-reconfigure linux-image-2.6.15-19-k7". It fixed the problem and I can again boot from my raid 1.

Do you think this problem could have been linked to the old version of the script (previously I was using both files from Tormod Volden 2006-03-21)?

> Do you think this problem could have been linked to the old version of the script

Yes, exactly. The old version broke with the udev update the 24th, hence the new version of the script.

These scripts are now included in the dmraid_0.9.9+1.0.0.rc9-2ubuntu1 upload.

To be nitpicking, the released fix fixes bug #36409. The remaining issue (and original bug description) is that dmraid is not on the install or live disk, so that you can not install on a fakeraid system.

I would reassign this bug to debian-installer or dmraid, but I don't know which.

The installer needs a dmraid-udeb in order to do this.

And I suspect there's no chance in heck we'll be able to squeeze this into the installer between now and release, though I could very quickly wrangle a udeb if it was something we wanted to push.

Matt, is this a hardware configuration we really, really want to be able to support in dapper (to the point of throwing resources at it this late in the game), or am I correct in assuming this should just be deferred to edgy?

On Thu, May 18, 2006 at 03:10:33AM -0000, Adam Conrad wrote:
> And I suspect there's no chance in heck we'll be able to squeeze this
> into the installer between now and release, though I could very quickly
> wrangle a udeb if it was something we wanted to push.
>
> Matt, is this a hardware configuration we really, really want to be able
> to support in dapper (to the point of throwing resources at it this late
> in the game), or am I correct in assuming this should just be deferred
> to edgy?

There isn't time; let's do this deliberately and methodically for Edgy
instead.

--
 - mdz

I upgraded to dapper today and tried to rebuild my initramfs with dmraid_0.9.9+1.0.0.rc9-2ubuntu1. After reading this, I've double-checked for the prereq udev and found it there though strangely when I got dmraid through apt-get in dapper universe, the prereq udev wasn't there and I got lots of trouble getting my FakeRAID back online before stumbling upon the prereq udev tip in the forum.

Just reread myself and I think I should clarify.

I checked in the .deb distributed on packages.ubuntu.com and the prereq udev was there.

But, when I downloaded dmraid_0.9.9+1.0.0.rc9-2ubuntu1 through the dapper universe repo, the prereq udev wasn't there. And that was the cause of my trouble.

Bloodypriest (sic) are you sure you don't have your own hook versions dangling in /etc/mkinitramfs? The package provides them in /usr/share/initramfs-tools but they will be overridden by your own in that case.

> Bloodypriest (sic) are you sure you don't have your own hook versions
> dangling in /etc/mkinitramfs? The package provides them in /usr/share
> /initramfs-tools but they will be overridden by your own in that case.
>
Please make sure that upgrade to dapper works fine also for all the
users that have manually added and regular already use dmraid on breezy
after followed this howto[1].

[1] https://wiki.ubuntu.com/FakeRaidHowto

The local-top script on that wiki page was missing the udev prereq, I just corrected it now. I also included some notes on upgrading to 6.06, as well as installing fresh with 6.06.

Nobody can guarantee that all fakeraid setups self-made in Breezy (which doesn't officially have fakeraid support) will upgrade smoothly to Dapper. But there's a good chance. And whoever was brave and clever enough to set it up it Breezy, will be able to recover from any trouble that would arise.

BTW, can anyone point me to that forum discussion Bloodypriest mentioned?

Il giorno sab, 20/05/2006 alle 17.29 +0000, Tormod Volden ha scritto:
> The local-top script on that wiki page was missing the udev prereq, I
> just corrected it now. I also included some notes on upgrading to 6.06,
> as well as installing fresh with 6.06.
>
> Nobody can guarantee that all fakeraid setups self-made in Breezy (which
> doesn't officially have fakeraid support) will upgrade smoothly to
> Dapper. But there's a good chance. And whoever was brave and clever
> enough to set it up it Breezy, will be able to recover from any trouble
> that would arise.
>
> BTW, can anyone point me to that forum discussion Bloodypriest
> mentioned?
>
It could be too complex, if dmraid script are founded
in /etc/mkinitramfs/ ask with a debconf question to automatically
remove it bacause now it was integrated in dmraid package.?

Thanks

Howdy. On your advice I tried out Ubuntu. Who knew? It's pretty cool. Alas, my Nvidia raid0 array done in windows doesn't seem to detect stripe size correctly. F10 on the bios (Asus a8n-sli for those who care) reports that yes, indeed, stripe size is set to 32k, but dmraid -s detects 64. Sure enough, it won't work, mount, fdisk, etc...

Is there a way to reset to manual settings? Hard-enter 32k?
Am I missing the point? :)

Is dmraid -s saying the stripe factor is 64k, or 64 sectors? I thought
it showed it in sectors, which would indeed be correct for 32k. If it
is actually wrong, then try dumping the metadata and posting it to the
dmraid mailing list ( <email address hidden> ) and the developers might
be able to fix it. I had a similar problem initially that was fixed in
this way.

beastly wrote:
> Howdy. On your advice I tried out Ubuntu. Who knew? It's pretty cool.
> Alas, my Nvidia raid0 array done in windows doesn't seem to detect
> stripe size correctly. F10 on the bios (Asus a8n-sli for those who
> care) reports that yes, indeed, stripe size is set to 32k, but dmraid -s
> detects 64. Sure enough, it won't work, mount, fdisk, etc...
>
> Is there a way to reset to manual settings? Hard-enter 32k?
> Am I missing the point? :)
>

>> The remaining issue (and original bug description) is that dmraid is not on the install or live disk, so that you can not install on a fakeraid system.

> The installer needs a dmraid-udeb in order to do this.

The new feisty version has a udeb...

Thanks, I will try this

On 12/16/06, Tormod Volden <email address hidden> wrote:
>
> >> The remaining issue (and original bug description) is that dmraid is
> not on the install or live disk, so that you can not install on a
> fakeraid system.
>
> > The installer needs a dmraid-udeb in order to do this.
>
> The new feisty version has a udeb...
>
> --
> missing dmraid support needed to access SATA raids
> https://launchpad.net/bugs/22107
>

Is this on the standard CD or do I need the Alternate CD?

Since this is a udeb it should be loaded at bootup? Or are there some
options I need to pass it. Just trying to get my ducks in order before I
install.

Thanks,
Scott

On 12/16/06, Tormod Volden <email address hidden> wrote:
>
> >> The remaining issue (and original bug description) is that dmraid is
> not on the install or live disk, so that you can not install on a
> fakeraid system.
>
> > The installer needs a dmraid-udeb in order to do this.
>
> The new feisty version has a udeb...
>
> --
> missing dmraid support needed to access SATA raids
> https://launchpad.net/bugs/22107
>

Kibbled_bits, my comment was just a wishful hint to the maintainers of the installer CD that dmraid now has what it needs to get on the CD. Even if not all the other installer components are prepared for fakeraid and will support it correctly, it would make things a lot easier to just get the package on the CD.
Sorry, you'll have to wait some time before fakeraid will be properly supported.

Would this help to get the dmraid package on the installer CD? https://wiki.ubuntu.com/MainInclusionReportDmraid
Please help to get that properly filled out and reviewed.

The package doesn't have to be installed by default in the first place, but at least be available as a .deb on the CD (like for instance the linux-wlan-ng package). For the alternate install CD, there should be a way to have the udeb easily installed.

This sounds like a good idea. Could we get this on the alternate CD in time
for Feisty?

Thanks,
Scott

On 1/17/07, Tormod Volden <email address hidden> wrote:
>
> Would this help to get the dmraid package on the installer CD?
> https://wiki.ubuntu.com/MainInclusionReportDmraid
> Please help to get that properly filled out and reviewed.
>
> The package doesn't have to be installed by default in the first place,
> but at least be available as a .deb on the CD (like for instance the
> linux-wlan-ng package). For the alternate install CD, there should be a
> way to have the udeb easily installed.
>
> --
> missing dmraid support needed to access SATA raids
> https://launchpad.net/bugs/22107
>

Following the instructions in UbuntuMainInclusionRequirements I posted the request to ubuntu-devel, but since that list is moderated, it didn't get through. Is there a developer in the audience? Help, please.

I'm not a developer, but you can try posting to the ubuntu-motu list or
ubuntu-devel-discuss.

I think there are no problems with initramfs-tools with regard to this issue. dmraid is also fine, it just needs to get onto the installer cd.

The remaining issue is with the partitioner used in the installer(s), which do not grok dmraid devices and screw the pooch. In particular, gparted does not even see the dmraid volume anymore.

Phillip, gparted is gone from the installer; let it die peacefully like it deserves.

Frans Pop did a good deal of work on a partman-dmraid package at Debconf, and that's in Debian now. From what I've seen of its design it will be very hard to integrate into Ubiquity before it's cleaned up substantially, but we may be able to include it on the alternate install CD at least.

Hrm.. so what is used now to partition from the livecd, and is there any hope to make it dmraid aware? I'll have to test out the new tribe release and take a look at partman-dmraid.

ubiquity has used a custom-written frontend over partman (the partitioner from d-i) for a while now. It stands a chance of picking up partman-dmraid eventually, but really partman-dmraid needs to become a bit more "normal" first.

There's no point in looking at the new Tribe releases yet. If any of this was in Ubuntu I would have said so.

GParted killed my mainboard after it failed to partition my IDE drive which sits as C: together with the SATA RAID0 E: (WINXP Boot) and Ubuntu assigned partitions (/root, /boot, /home and /swap)

Previously followed the guides Howto: which left out some VERY important details.
1) That this guide was designed for a single SATA RAID0 system
2) No instruction on how to open the editor to edit the menu.lst

Thus:
1) I failed to have GRUB load which instead automatically brought me to Windows XP
2) I ended up doing the entire process listed in the Howto from Step 1 again and again
3) GPart failed to repartition my IDE drive which stores some personal data. AND possibly destroyed it...

This suggestion is now about 4 years old, other distros like Fedora and KNOPPIX have dm-raid support out-of-the-box, so why isn't it included in ubuntu? Would be very nice ;)

Dmraid support is planned for Intrepid.

(@Luke Yelavich)

Imho it is a shame that server edition does not support dmraid and that this bug is not assigned to anyone for years.
Who ever would setup a server not using mirroring?

A first solution to the problem would be:
- Include module md in the startup code of installer etc.
- Change the installing script in such a way that "Detecting harddiscs" recognizes raids.

After that, people who install servers would be competent enough to do in a console ;-)

On Sat, Jun 28, 2008 at 01:17:26PM -0000, tricky1 wrote:
> (@Luke Yelavich)
>
> Imho it is a shame that server edition does not support dmraid and that this bug is not assigned to anyone for years.
> Who ever would setup a server not using mirroring?

There are many other mirroring setups which do not depend on dmraid. Let's
focus on what we can do about the bug in the near future, rather than the
past.

--
 - mdz

@Matt
Those reading the whole see that I did focus on a solution for Ubuntu.

Another solution is installing Fedora 9 where mirroring combined with Luks and LVM works out of the box...

Yes, indeed Fedora actually worked for me when I tried it 2 years ago. But
then again it's no Ubuntu ;-)

On Mon, Jun 30, 2008 at 3:32 AM, tricky1 <email address hidden> wrote:

> ** Also affects: debian-installer
> Importance: Undecided
> Status: New
>
> --
> missing dmraid support needed to access SATA raids
> https://bugs.launchpad.net/bugs/22107
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Current daily builds of Intrepid should support dmraid, although only in the alternate and server install CDs; please give them a try and report back.

I no longer have the PC that was of issue so I am no longer able to test
this. Sorry.

On Tue, Sep 16, 2008 at 5:28 AM, Colin Watson <email address hidden>wrote:

> Current daily builds of Intrepid should support dmraid, although only in
> the alternate and server install CDs; please give them a try and report
> back.
>
> --
> missing dmraid support needed to access SATA raids
> https://bugs.launchpad.net/bugs/22107
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Gimme a link to the daily builds and I'll try a test. All I can find are the Alpha 5 CDs, which are timestamped far too long ago to be a daily build...

 I have an NVRAID setup, which should work for testing.

You can fetch the latest daily builds from here: http://cdimage.ubuntu.com/daily/current.

Thanks in advance for any testing you can provide.

I downloaded, burned and, installed from the September 16 AMD 64 nightly build CD. It successfully detected and installed to my RAID array.

I have an NVIDIA NForce 570 SLI chipset. My NVIDIA RAID ROM setting was switched to on. For reference, the motherboard model is a Abit KN9 SLI MCP.

Thanks so much for the fix! It didn't have any issues installing grub, either.

The only issue you may find is that if you dual boot with Windows, Windows is not in the grub menu. This is known, and a fix will be released as soon as possible.

Thanks for the installation test.

At home I have a Mythbuntu box, with NVIDIA RAID and 2 extra SATA drives waiting for 8.10 final.
My Work desktop has Intel based raid that I want to try 8.10 soon with raid.

I did get Ubuntu 8.04 x64 with raid working on a Dell Op... 755 ( my Boss' Desktop) Intel based raid but only the first kernel from the CD installed and booted correctly. He redid it without raid because not being able to update the kernel is not a good thing.

-- Christopher

Was installing on your raid setup more like installing on non-raid drives ( easy ) , or like on this howto https://help.ubuntu.com/community/FakeRaidHowto ( might be hard for the avg user ), or in-between?

I was unable to install Ubuntu-8.04.1 LTS server i386 on an ASUS A7V600 with on-board Via fakeraid. I found this bug report, and attempted to install the today snapshot intrepid-alternate-i386.iso. This one installs fine. The fakeraid array is detected properly.

However, I wanted to install the server version, so I downloaded intrepid-server-i386.iso as well. This one also detects the raid array properly, and the installation begins, but then it fails with a red background complaining it cannot install the base system. On console F4 the last message is that it cannot find dmraid. Needless to say its impossible to continue the installation from this point on.

I have repeated this using a 2 disk RAID-1 array twice, and a 2 disk RAID-0 array also twice. Both fail consistently. I have then tried to install this server version on a single disk (non-raid), and this one succeeds.

Could it be that the solution for the desktop version is not implemented or not properly implemented for the intrepid server (alpha) edition yet?

V - your problem sounds unrelated. Please open a new bug report for that.

Thanks

Sorry Chris, but I think it is very related. dmraid is not working in intrepid server i386 alpha, it specifically complains about dmraid missing, although it is actually present, and the /dev/mapper/via* entry as well. Installing on the same system without dmraid on a single SATA disk works flawlessly.

I think this is very related. When I tried installing dmraid in a live-cd, it detected the /dev/mapper entries and everything quite flawlessly, but it failed to install because the raid driver choked. I think it was installed but not installed to the kernel itself.

What I think is happening is that dmraid is installed but the kernel initramfs was not regenerated. This is interesting to me since it's just an LKM and shouldn't require a reboot (which is impossible with a live-cd), but somehow it is exhibiting the behaviour of needing to reboot.

So perhaps the fix that worked on the desktop edition needs to be applied to the server edition as well?

Yes, dmraid was missing from the server CD, although for a completely unrelated *reason*. :-) It wasn't anything to do with it needing to be "applied to the server edition" - it was a mistake in our data files that list packages needed on the CDs. I fixed it with this seed commit:

revno: 1338
committer: Colin Watson <email address hidden>
branch nick: ubuntu.intrepid
timestamp: Tue 2008-10-07 06:12:29 +0100
message:
  include d-i-requirements on server CDs

I suspect that's the reason, anyway. Please try with a newer daily build.

It looks like the alternate cd is working well with dmraid, but installing with the livecd still is a little bumpy. Specifically ubiquity crashes when trying to install GRUB. Once that is ironed out, this bug can finally be marked as fixed.

The bug appears to have been fixed already. Moving to "Confirmed". Next step is for the Ubuntu Bug Control team to move to "Triaged".

We don't need the upstream debian-installer task.

There's a separate bug for ubiquity (bug 90235 etc.) so we can close this out now that it works in d-i.