[01:14] <Sp0tter> Why does a guided LVM put all the available space in the / partition?  You can't shrink that while its up, so then whats the pointin the LVM?
[02:22] <Sp0tter> how do i keep my fully auto install from never ending?  install, reboot, install, reboot ?
[10:31] <xivulon> nable to make backup link of `./boot/vmlinuz-2.6.24-19-generic' before installing new version"
[10:31] <xivulon> had a few reports of broken kernel update: unable to make backup link of `./boot/vmlinuz-2.6.24-19-generic' before installing new version"
[10:32] <xivulon> we had this issue in the past whereby the kernel update tried to create a hardlink and failed on vfat
[10:33] <xivulon> I have no other info at the moment, will post if I find out more
[10:36] <cjwatson> mm, dpkg does seem to require that
[10:37] <cjwatson> (that code is not in the kernel package, it's in dpkg itself)
[10:37] <cjwatson> frankly if I were you I'd say "you need NTFS. sorry"
[10:39] <xivulon> cjwatson: is that a new requirement? I didn't run into that before
[10:39] <cjwatson> no, it's old as the hills.
[10:39] <cjwatson> we just didn't think of it before.
[10:40] <cjwatson> dpkg requires POSIX semantics from any filesystem on which it installs files.
[10:40] <cjwatson> we should have just gone for copying files onto the Windows filesystem after the fact, rather than trying these clever tricks with bind-mounting /boot
[10:41] <xivulon> but I am sure we had kernel installations on vfat in the past, particularly when we tested the copy-on-hardling-failure bit
[10:42] <xivulon> well for the future do you suggest rsyncing /boot in rc6.d?
[10:46] <cjwatson> you might have had kernel installations, but did you have upgrades?
[10:46] <cjwatson> rc6.d? goodness no, why would you want to do it there
[10:47] <cjwatson> postinst where it belongs :)
[10:47] <cjwatson> and copy the individual files rather than rsyncing the whole directory
[10:47] <cjwatson> you can't rely on rc6.d ever being called
[10:48] <xivulon> the reason I was thinking about reboot scripts is because I wouldn't be able to catch menu.lst manual edits otherwise.
[10:50] <xivulon> I would have thought we should have run into it earlier, since there were quite a few kernel upgrades since the beta stage, and there are several vfat users.
[10:59] <cjwatson> putting /boot/grub on vfat directly would probably be OK; there are no dpkg-managed files there
[11:02] <xivulon> we could also take care of the copying in update-grub and avoid bindmounts
[17:06] <Sp0tter> Greetings installers,  my question is how would you stop an auto-installation from cycling forever.  Shutdown after install you might say!  But i have that comptuer set to auto power on whenever it has power, I need some type of loop that can run til it gets manually reset, but if i reset it at the part where it says its about to reboot, grub dies.
[17:10] <cjwatson> how are you booting it? PXE?
[17:12] <Sp0tter> No, my friend will put in my auto cd and hit reset, then walk away while it installs.
[17:13] <Sp0tter> Its an auto installation cd with a presseed and kickstart on the iso
[17:17] <Sp0tter> i had planned to just not use auto reboot, but those last coupl steps it does after it ejects the cd adn you hit continue are crucial
[17:18] <cjwatson> you could try preseeding debian-installer/exit/halt=true
[17:18] <cjwatson> ('d-i debian-installer/exit/halt boolean true')
[17:18] <Sp0tter> wont that shut it downa fter?
[17:18] <cjwatson> that will cause the last step of the installation to be halt rather than reboot
[17:18] <Sp0tter> ah
[17:18] <Sp0tter> cool i'll try that right now
[17:19] <cjwatson> in a Kickstart file, it would be 'preseed debian-installer/exit/halt boolean true'
[17:20] <crispin> which reminds me, it might be nice to have a way of powering off a box at the end of the install (I hack it :-) )
[17:20] <cjwatson> isn't that the above?
[17:20] <crispin> no, that halts the box without powering it off
[17:20] <crispin> or maybe that is a bug ...
[17:20] <cjwatson> that depends on ACPI implementation surely
[17:21] <crispin> well, if I run the "poweroff" command instead of halt it powers off ...
[17:21] <crispin> almost like it isn't poking acpi at all
[17:21] <cjwatson> oh, ok
[17:25] <cjwatson> crispin: committed upstream (debian-installer/exit/poweroff=true)
[17:33] <Sp0tter> ok, so i still need to have the reboot option in ks
[17:34] <cjwatson> which reboot option?
[17:34] <Sp0tter> just  'reboot'   in ks.cfg
[17:34] <Sp0tter> makes it so you dont have to click that last continue
[17:35] <Sp0tter> or should i preseed that instead , if the reboot in ks overrides the halt
[17:36] <cjwatson> no, they are complementary; do both that and what I suggested
[17:36] <cjwatson> 'reboot' in ks.cfg is precisely equivalent to preseeding finish-install/reboot_in_progress so that it doesn't get shown
[17:37] <cjwatson> according to the Anaconda docs, its purpose is not so much to reboot as opposed to halt, but to avoid the press-a-key message before rebooting
[17:38] <Sp0tter> excellent
[17:38] <Sp0tter> running a final test in vm now, then testing  on a real machine, then  uploading my solution to my server place  :)
[17:50] <crispin> cjwatson: excellent, that will help me in about 2 years when we change to your next LTS version :-)
[17:51] <cjwatson> crispin: if you're modifying the image, you could always import that change - it's only a few lines of shell
[17:51] <cjwatson> http://paste.ubuntu.com/31788/
[17:57] <crispin> cjwatson: I'm not modifying any udeb - I'm in fact trying to modify as little as possible
[17:57] <crispin> I hack it by running a sed in my preseed/late_command program :-)
[18:00] <cjwatson> ah, well, I can't offer anything less hacky if you aren't modifying anything, then
[18:00] <Sp0tter> awesome, it works perfectly
[18:00] <crispin> cjwatson: thats cool, I managed to remove a huge number of hacks going from sarge -> hardy :-)
[19:08] <mdf> hi folks, question about raid support in kickstart
[19:09] <mdf> I see kickseed/handlers/raid.sh states it not supported
[19:10] <mdf> yet packages/partman/partman-md is there and looks functional
[19:13] <mdf> so is it the handler functions that need coding or is there more to it?
[20:59] <hachi> morning, this may be a bit offtopic, but in the last week nobody on #ubuntu has had a clue... I'm trying to find how you can specify the filename of the filesystem for casper. I've been reading the startup scripts in the initramfs and just can't make heads or tails of it. Do any of you know options for this?
[20:59] <tormod> hachi: what name are talking about?
[21:00] <tormod> the filesystem.squashfs?
[21:00] <hachi> filesystem.squashfs on the CD, located at /casper/filesystem.squashfs
[21:00] <hachi> I can't figure out how it knows filesystem.squashfs is the right file
[21:00] <tormod> it's in scripts/casper IIRC
[21:00] <hachi> more importantly, I want to tell it to search someplace else
[21:01] <hachi> yeah, it's not hard coded into those files
[21:02] <hachi> everything is passed around as arguments to functions
[21:02] <tormod> inside is_casper_path() ?
[21:02] <hachi> it looks like it should be using kernel options for base filenames to check, that sort of thing, but I can't find it loading the kernel option... among other things
[21:03] <tormod> it is hardcoded to be inside a casper directory on the root of a filesystem, I think
[21:04] <tormod> then see is_casper_path()
[21:05] <tormod> it pretty generously accepts all names ending in "ext2" "squashfs" "dir"
[21:12] <cjwatson> mdf: somebody needs to figure out how to transform Kickstart RAID syntax into partman-auto-raid preseeding
[21:13] <cjwatson> mdf: I tried recently and it didn't seem exactly obvious - some of the basic assumptions about how things worked were different
[21:14] <cjwatson> right, tormod's right, though it's mostly setup_unionfs that actually does the work
[21:14] <cjwatson>     for image_type in "ext2" "squashfs" "dir" ; do
[21:14] <cjwatson>         for image in "${image_directory}"/*."${image_type}"; do
[21:14] <cjwatson> ...
[21:15] <tormod> cjwatson: btw, I have some patches (rotting?) in bazaar
[21:15] <tormod> for casper
[21:15] <cjwatson> oh, yeah, I do need to do something about that. IIRC I merged some of yours recently
[21:16] <tormod> but not in bzr I guess :)
[21:16] <cjwatson> hmm, no, that was a while back
[21:16] <cjwatson> send mail to cjwatson@ubuntu.com and I'll have a look
[21:17] <tormod> mail? will https://code.edge.launchpad.net/~ubuntu-core-dev/casper/trunk/+merges do?
[21:18] <tormod> if you're working on casper, can you make a new branch, until lp:casper gets fixed?
[21:21] <cjwatson> no. it won't help because any (mergeable) new branch would have the same ghosts.
[21:21] <cjwatson> and I'm certainly not going to create an unmergeable branch.
[21:21]  * tormod hoped that advanced launchpad features would take away the need for mailing patches around and bug people on IRC :)
[21:22] <cjwatson> it's not really a Launchpad bug, it's bzr itself having serious trouble dealing with ghosts directly on the mainline
[21:22] <cjwatson> I have copies of the old arch branches and have been trying to convert them and fetch them in, but it's very fiddly, you have to get the conversion exactly right or the whole thing blows up
[21:23] <cjwatson> and so far all I've succeeded in doing is making things blow up
[21:24] <cjwatson> tormod: that +merges URL will be fine, it's just to have something in my to-do mailbox otherwise I *will* forget
[21:25] <tormod> ghosts is what you get for naming a branch casper (hint the movie...) :)
[21:25] <tormod> ok, I will send you a reminder
[21:26] <cjwatson> casper> yes, the name is explicitly intended to evoke the Friendly Ghost
[21:26] <cjwatson> since casper's job is to flit around the edges of your distro making little magic tweaks to cause it to boot as a live CD
[21:27] <tormod> I think bzr didn't the point :)
[21:27] <tormod> *get
[21:37] <Sp0tter> there is a lot of symbolism in ubuntu
[21:40] <tormod> Sp0tter: it's all the woodoo that makes it work
[21:50] <cjwatson> more that coming up with silly names is light relief from serious work :)
[21:54] <CIA-1> ubiquity: evand * r2759 ubiquity/ (debian/changelog ubiquity/components/language.py):
[21:54] <CIA-1> ubiquity: Also remove the langlevel file if it exists before we start
[21:54] <CIA-1> ubiquity: localechooser.
[22:12] <hachi> is there a way to put both 64bit and 32bit x86 casper on a single media?
[22:29] <CIA-1> oem-config: evand * r504 oem-config/ (debian/changelog lib/components/language.py):
[22:29] <CIA-1> oem-config: Also remove the langlevel file if it exists before we start
[22:29] <CIA-1> oem-config: localechooser.