[00:46] <Cookiepig> hey guys
[00:47] <Cookiepig> this the channel where we ask about installing ubuntu?
[01:58] <ago> cjwatson, evand, the option creating issues in update-initramfs was "group_id=0"
[11:03] <xivulon> Have filed bug #187282 anyway, the option triggering the failure was "group_id" by the way
[11:03] <ubotu> Launchpad bug 187282 in wubi "update-initramfs -u fails with "WARNING: /boot is ro mounted." even if /boot is rw" [Medium,Confirmed] https://launchpad.net/bugs/187282
[11:15] <xivulon> evand, cjwatson, re #175772 unlike stated in the email, I think that the fix simply involves removing the line:
[11:15] <xivulon> if [ -f "$loop_file" ]; then
[11:15] <xivulon> from update-grub
[11:16]  * xivulon thinks a bug comment would be better 
[11:25] <xivulon> evand, cjwatson, ignore my yesterday emails and look at https://bugs.launchpad.net/wubi/+bug/175772/comments/6
[11:25] <ubotu> Launchpad bug 175772 in wubi "Update-grub does not set kopt correctly in loopinstallations" [Medium,In progress]
[11:26] <xivulon> was far too late yesterday...
[13:26] <xivulon> I have noticed that update grub defaults to /dev/hda1 if it cannot find a root_device.
[13:26] <xivulon> Shouldn't that be /dev/sda1 which seems to be far more common these days?
[13:37] <cjwatson> that case should be considered a bug if it ever occurs so I think it's fine to leave it as it is
[13:46] <evand> cjwatson: do you think it's inappropriate to upload a patched version of sysvinit today, or should I wait until Friday?  I've tested it and found no issues, the code also looks ok as far as I can tell.
[13:49] <evand> ick, I could've worded that better.
[13:50] <cjwatson> evand: are you aiming to get the whole of wubi into alpha 4?
[13:52] <evand> ideally
[13:52] <evand> but I wholly acknowledge it may be too late for that.
[13:53] <xivulon> that would be nice :P
[13:54] <xivulon> patch to 175772 is trivial (see last comment)
[13:54] <xivulon> patch to umountfs is a bit more invasive but should be ok
[13:56] <xivulon> for ref last comment in 151579
[14:02] <cjwatson> evand: if so, then it's appropriate; if not, it should wait
[14:03] <cjwatson> evand: if so, of course, then you have a matter of hours
[14:04] <evand> can you clarify, if what is so?
[14:04] <evand> cjwatson: ^
[14:06] <cjwatson> if you are aiming to get wubi support in alpha 4
[14:06] <evand> ok, thanks for the advice.
[15:00] <CIA-23> partman-target: evand * r694 partman-target.ubuntu/ (commit.d/clear_partitions debian/changelog):
[15:00] <CIA-23> partman-target: * Rework clear_partitions to not try to remove active mountpoints (LP:
[15:00] <CIA-23> partman-target:  #186711).
[15:03] <cjwatson> oh good, I was about to ask you about that
[15:04] <evand> I finished that yesterday, but I woke up this morning to a VM missing /boot and I'm trying to determine now if clear_partitions is the cluprit.
[17:36] <CIA-23> ubiquity: evand * r2424 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py):
[17:36] <CIA-23> ubiquity: * Add new nautilus gconf keys to the list we temporarily disable to
[17:36] <CIA-23> ubiquity:  prevent constant pop-ups.
[17:45] <CIA-23> partman-target: evand * r695 partman-target.ubuntu/debian/changelog: releasing version 52ubuntu3
[17:46] <evand> looks good as far as I can tell (I tested several different partition table configurations with it present)
[17:47] <evand> so my missing /boot was probably me canceling an install after it ran but before the grub-install component had a chance to run
[17:47] <evand> and forgetting about it
[20:25] <CIA-23> ubiquity: evand * r2425 ubiquity/ (d-i/manifest debian/changelog):
[20:25] <CIA-23> ubiquity: * Automatic update of included source packages: console-setup
[20:25] <CIA-23> ubiquity:  1.21ubuntu2, migration-assistant 0.6.0, partman-target 52ubuntu3,
[20:25] <CIA-23> ubiquity:  user-setup 1.16ubuntu3.
[20:29] <CIA-23> ubiquity: evand * r2426 ubiquity/ (aclocal.m4 configure configure.ac): Bump to 1.7.5
[20:31] <CIA-23> ubiquity: evand * r2427 ubiquity/debian/po/ (79 files): debconf-updatepo
[20:36] <CIA-23> ubiquity: evand * r2428 ubiquity/debian/changelog: releasing version 1.7.5
[20:46] <cr3> how can I seed variables from the command line?
[20:47] <evand> cr3: debconf-communicate
[20:47] <evand> echo "SET passwd/username evan" | debconf-communicate
[20:48] <cr3> evand: thanks man!
[20:48] <evand> cr3: anytime
[20:48] <cr3> evand: now lets see if my package works :)
[20:48] <evand> heh
[20:50] <cr3> evand: I'm getting: 10 hwtest-verify/plugins/exchange_prompt/secure_id doesn't exist
[20:50] <evand> is it in the templates file of your package?
[20:51] <cr3> evand: yes, but the package is not installed yet
[20:52] <cr3> evand: basically, I want to set the variable and then try dpkg installing it
[20:53] <evand> to avoid the question being asked?
[20:54] <cr3> evand: yep, and also to test that the variable is being substituted properly. this is ultimately meant to go in the preseed of a network install, so I want to test on the command line because the install takes forever :)
[20:55] <evand> ah, then I should've pointed you at debconf-set-selections instead
[20:55] <evand> it takes the same format as a preseed file
[20:56] <cr3> thanks, I'll try that
[20:56] <evand> so echo "d-i foo/bar string barish" | debconf-set-selections
[20:56] <evand> you're welcome
[20:56] <cr3> evand: that's even more perfect, I get to test the exact line from my preseed file
[21:06] <cr3> evand: worked on the command line, now to figure out why it doesn't work during the installation
[21:06] <evand> because the database is locked by the install process
[21:07] <evand> you can only modify questions as part of a component of the install (sourcing confmodule and using db_set)
[21:07] <evand> oh, perhaps I misread
[21:07] <cr3> evand: I'm not quite sure I understand
[21:08] <evand> I think I misread, you are doing this as part of a udeb and you're saying that it's not working within that context, right?
[21:08] <evand> I thought you were saying using debconf-set-selections wasn't working while the install was running.
[21:09] <cr3> evand: right, so I'm netinstalling and using a preseed which has worked well for me so far. now, I added this line to pressed a package:
[21:09] <cr3> d-i hwtest-verify/plugins/exchange_prompt/secure_id string $secure_id
[21:09] <cr3> (where $secure_id gets substituted at some point, don't worry about it :)
[21:09] <evand> haha that scared me for a moment
[21:09] <cr3> then, I install the extra packages I need with this line:
[21:10] <cr3> d-i preseed/late_command string apt-install hwtest-server-cli
[21:11] <evand> shouldn't that be pkgsel/include hwtest-server-ci?
[21:11] <evand> errm wait no
[21:12] <cr3> evand: in the sample preseed file, I see two ways: pkgsel/include and preseed/late_command. the former is used to install openssh-server in the sample and the latter to install zsh.
[21:13] <evand> is hwtest-server-cli a udeb?
[21:15] <cjwatson> pkgsel/include is preferred if you can
[21:15] <cjwatson> the latter is an example in case you need to do more complicated stuff
[21:25] <evand> cjwatson: did you get my PM from earlier today?
[22:25] <cr3> evand: no, hwtest-server-cli is not a udeb, does it need to be?
[22:26] <evand> no, I was curious as if it was a component of the install process the way you installed it would be different.
[22:32] <cr3> evand: does the install log get stored somewhere so that I can review after the installation whether the variable was indeed preseeded?
[22:32] <evand>  /var/log/installer
[22:42] <matttp> cjwatson: You around?
[22:54] <cr3> evand: I didn't find anything interesting relating to preseeding my variables in /var/log/installer, and I do have DEBCONF_DEBUG=5 in my kernel parameters
[22:58] <evand> cr3: hrm, I suppose you could copy the database out as part of late_command.  cjwatson might know of a more elegant solution than that.
[22:58] <cr3> evand: it's getting late, and even later for cjwatson. I'll try again tomorrow at a more reasonable time. thanks for all the help dude!
[22:58] <evand> yeah, I just noticed the time :)
[22:59] <evand> anytime, goodnight