[11:50] cjwatson, I'like to know if you have any good idea to remove the mountbind to /boot in wubi, as that is a bottleneck for a few other things [11:51] well, I can't say anyone has convinced me about the reliability of any replacement for that yet :( [11:51] how're you going to guarantee that the ntfs copy gets updated if a user fiddles about in /boot by hand? [11:52] we need a syncfs :) [11:53] any approach I can think of will involve copying the files from /boot to /host/ubuntu/disks/boot at some stage [11:54] and of course you can always think of cases where the 2 dirs are out of sync at boot time [11:55] do you have a current list of problems traceable to the bind-mount? [11:56] On top of my head, there is this issue with kernel upgrades in vfat (apt does the hard link trink) and the issue about using a CD content instead of the ISO [11:56] let me fetch the bugs [11:56] hi... does anyone knows how to make it so that in the installer process, a certain package is run at a higher debconf priority, without having to change it globally ? [11:57] yannickm_: no way to do that at present [11:57] fix the package to ask the questions at the priority you want, or preseed the answers to the questions if that isn't possible [11:58] 252900 243105 207137 [11:59] 201046 [11:59] ugh... i would rather not want to have to mess with the standard ubuntu package (in this case slapd), there's no other way ? [11:59] ha [11:59] too bad [12:00] I guess i'll file a RFE to debian installer lol... thanks anyway [12:04] bah, he left. what's wrong with preseeding? [12:05] cjwatson could you apply 289791? [12:09] xivulon: done with minor modifications [12:09] 243105 has never been diagnosed and might well be fixable if we could figure it out [12:09] grub-installer: cjwatson * r758 ubuntu/ (debian/changelog grub-installer): [12:09] grub-installer: Hide GRUB menu if grub-installer/bootdev_directory is preseeded; this is [12:09] grub-installer: used in the Wubi case where GRUB is used as a secondary boot loader, and [12:09] grub-installer: so the user already had a chance to boot from another operating system [12:09] grub-installer: (thanks, Agostino Russo; LP: #289791). [12:09] 207137 does not obviously have anything to do with the bind-mount [12:10] ditto 201046 [12:10] Well in the sense that 243105 blocks both [12:10] so yes addressing 243105 will also fix such issues [12:10] don't just list lots of tenuously related bugs, I'm only interested in the ones that are actually directly related [12:11] then the first 2 [12:11] it might be worth checking for link() errno == ENOSYS in dpkg [12:11] and falling back to copying the file [12:12] That will work, it is similar to an old fix we had in the past (in update-initramfs IIRC) [12:13] In fact it would be great if that could be pushed to intrepid updates [12:13] no. [12:13] I'm not pushing any such dpkg change to a stable release [12:13] scares me *far* too much [12:14] ok anyway,. people deserve to be punished for using fat... [12:14] I wasn't saying that, I just don't think it's worth the risk [12:15] it's awkward that link() gets EPERM rather than ENOSYS though [12:15] if it were ENOSYS then I'd be comfortable with providing a replacement [12:16] EPERM can also mean that the source of the link is a directory though [12:17] I've created a task on dpkg though [15:18] cjwatson: hiya [15:18] hi [15:18] cjwatson: i've actually committed a couple of minor patches upstream that enables mount.ecryptfs_private to encrypt/mount/decrypt your entire /home/kirkland directory ;-) [15:19] yow [15:19] I don't think I have the nerve to use that myself :) [15:19] cjwatson: ;-) [15:20] cjwatson: the changes to the binary are actually remarkably simple [15:20] cjwatson: the fs layout of /home/kirkland and /home/.kirkland are, um, innovative ;-) [15:20] that means a user can't do this for themselves [15:21] cjwatson: correct [15:21] if it requires a new directory under /home [15:21] cjwatson: that's what brings me here [15:21] cjwatson: it would require patching adduser, as well as ecryptfs-setup-private [15:21] cjwatson: actually ..... [15:22] cjwatson: you've just triggered something interesting in my mind [15:22] cjwatson: i'll go play with that [15:23] glad to serve as a potted plant :-) [15:23] cjwatson: :-) [15:23] cjwatson: but, not doing it themself is a requirement i think i'm going to need [15:24] cjwatson: because "migration" of a non-encrypted home dir to an encrypted-homedir is a really dicey operation [15:24] cjwatson: would need to ensure that there are no other readers/writers on that user's home dir during the "migration" [15:24] yeah, I think it's OK [15:25] cjwatson: seems like an impossible situation if the migration ran as the user [15:25] cjwatson: so it would be something that you'd want at adduser time, or not [15:25] cjwatson: i can wiki up some instructions how to do the migration safely, as root, in runlevel 1 [15:25] cjwatson: which is what i did to bootstrap my system [15:26] cjwatson: but i don't want to publish a tool to do this for someone, as it's riddled with complexity :-) [15:28] cjwatson: I understand that you won't be at UDS, but I'm asking Rick to schedule another Encrypted Home Directory session, where I'd like to demo what I've done so far, and seek some discussion/concerns/etc [15:30] * kirkland expects no lack of forceful opinions ;-) [15:34] cjwatson: encrypted filename patches are undergoing review/revision on LKML right now [15:52] kirkland: I think you should explicitly look at what the ubiquity UI might look like [15:53] it seems to me that it ought to go on the user page, but exactly how it should be laid out I'm not sure [15:53] cjwatson: okay, i'll make sure i have a proposal about that [15:55] cjwatson: i got a bug report recently, saying that MacOSX encrypts home dirs by default (not confirmed by me), requesting Ubuntu provide the option; got me thinking about this, and it's starting to actually appear doable ;-) [15:55] cjwatson: but I will definitely think about the Ubiquity aspect [15:59] I don't think Mac OSX encrypts home directories by default. FileVault apparently does not play well with Time Machine. [15:59] I can check now...wife has a Powerbook [15:59] And it definitely does not do it in my copy of OSX (I'm assuming 10.4) [16:04] 10.5 doesn't do it either. Maybe it's a new feature for 10.6? [16:12] https://bugs.edge.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/277894 [16:12] Launchpad bug 277894 in ecryptfs-utils "anyone with a livecd can acces data on ubuntu -- encrypt home directories" [Wishlist,In progress] [16:12] that was the bug report, albeit somewhat noobish [16:13] he marked it a "security vulnerability" :-) [16:45] kirkland: http://docs.info.apple.com/article.html?path=Mac/10.5/en/8736.html [16:46] from what I can see on OSX 10.5.5 it doesn't appear that the home directories are encrypted by default [16:46] but this machine was upgraded...so maybe on fresh install it provides the option [16:46] * evand ponders https://bugs.launchpad.net/ubuntu/+source/linux/+bug/292159 [16:46] Launchpad bug 292159 in linux "MASTER update-initramfs is disabled since running on a live CD but it is running from a flash drive. " [Low,Triaged] [16:47] robbiew: *great* link ... [16:47] robbiew: that's some skillful text there, cjwatson [16:47] kirkland: which is? [16:47] i remember vacillating over the different ways of stating that [16:47] cjwatson: http://docs.info.apple.com/article.html?path=Mac/10.5/en/8736.html [16:47] oh right [16:48] evand: odd, sounds like it's copying the casper-ified filesystem rather than the squashfs! [16:48] evand: oh, running as a live image, not installed? [16:49] ja [16:49] it explodes when there's a new kernel [16:49] which is particularly bad when you're running off a USB disk with persistence [16:49] how about making that casper script conditional on persistence? [16:50] and fix whatever bug it is that makes it explode in non-persistent mode rather than just silently doing nothing [16:50] but in persistent mode it should definitely let update-initramfs work as normal [16:50] indeed [16:51] I'm also going to conditionalize setting the clock to UTC, if that's fine by you [16:52] yeah, I think so [16:53] ok, great [16:54] would it be worthwhile to check for persistence and disable the cron daemon's init script if persistence is off? I seem to remember reading a report somewhere that a syslog rotation script could cause /var/log/syslog to be renamed and the wrong file copied into the resultant install [17:01] cron is already supposed to be disabled [17:01] ./scripts/casper-bottom/25configure_init [17:01] if that isn't working then somebody should work out why [17:03] i'll try to find the original report of it [17:04] I've seen such reports myself before and tried to debug them, and run up against "er, well, it's supposed to work already" [17:04] not claiming for sure that it *does* work [17:06] cjwatson: is there any historical reason why we overwrite /etc/localtime in casper? It's already UTC on the squashfs. [17:06] s/any/a/ [17:07] I'm tempted to just remove the script entirely if we don't need it. [17:08] perhaps it just predates that being the case in the squashfs [17:08] if the script isn't necessary, go ahead and remove it [17:08] will do, thanks [17:17] casper: evand * r565 casper/ (scripts/casper-bottom/02timezone debian/changelog): [17:17] casper: * scripts/casper-bottom/02timezone: [17:17] casper: - Remove as it's no longer needed and resets the timezone when [17:17] casper: persistence is enabled (LP: #296855).