I've spent the last four days trying to figure out why my previously working (in feisty) cryptdisks were silently failing to mount during gutsy's boot, but would happily mount manually if I invoked the scripts after login.
This is a critical bug because:
1. anyone who *properly* uses Ubuntu's *standard* encryption init.d scripts to mount an encrypted /tmp will leave their Ubuntu system unbootable - this is the case even though the user did everything right. Any bug that leaves a system unbootable must be rated critical.
2. encrypted swap fails to mount, *and fails silently* so there are people out there with laptops relying on Ubuntu's encryption infrastructure who are going to be a bit upset;
3. cryptdisks is normal init.d infrastructure - people who use it are not doing something weird.
4. linking against a mount point that doesn't necessarily exist at the Sxx time cryptdisks is executed is plain silly.
I've spent the last four days trying to figure out why my previously working (in feisty) cryptdisks were silently failing to mount during gutsy's boot, but would happily mount manually if I invoked the scripts after login.
This is a critical bug because:
1. anyone who *properly* uses Ubuntu's *standard* encryption init.d scripts to mount an encrypted /tmp will leave their Ubuntu system unbootable - this is the case even though the user did everything right. Any bug that leaves a system unbootable must be rated critical.
2. encrypted swap fails to mount, *and fails silently* so there are people out there with laptops relying on Ubuntu's encryption infrastructure who are going to be a bit upset;
3. cryptdisks is normal init.d infrastructure - people who use it are not doing something weird.
4. linking against a mount point that doesn't necessarily exist at the Sxx time cryptdisks is executed is plain silly.