[14:33] <holmanb> meena: regarding https://github.com/canonical/cloud-init/pull/2165#discussion_r1184320463 - you're welcome to make that change - it would probably make more sense as a separate PR though, so it's up to you
[14:33] -ubottu:#cloud-init- Pull 2165 in canonical/cloud-init "Ephemeral Networking for FreeBSD" [Open]
[14:33] <meena0> holmanb: let's get this merged, so I can get paid
[14:34] <holmanb> and as for the PR, I'll try to get in my review today
[14:34] <holmanb> meena0: sounds good
[14:34] <meena0> thanks
[14:43] <meena0> anyway, time to rework my roadmap.
[19:31] <blackboxsw> falcojr: holmanb are you seeing tox -re integraiton-tests fail locally? I think pytest 7.3.2 (released 6/10) now does something else funky with conftest path loading. for some reason it's loading test/unittests/conftest.py  during an `integration-tests` run
[19:31] <blackboxsw> the result I see is a failure like this https://paste.ubuntu.com/p/RfCdbxtgGP/  also failing all our jenkins jobs
[19:32] <blackboxsw> we could express a dependency on "responses" in integration-tests.txt.... but that's not a real dependency in our integration tests....
[19:32] <blackboxsw> if I pin pytest=7.3.1 integration tests run fine
[19:33] <blackboxsw> I'm guessing it has something to do with https://github.com/pytest-dev/pytest/issues/10987
[19:33] -ubottu:#cloud-init- Issue 10987 in pytest-dev/pytest "`pytest_sessionstart` not run in custom test directories" [Closed]
[19:33] <meena0> how hard would it be to move cloud-init's /run to /var/run on *BSD? — on new installations
[19:35] <blackboxsw> meena0: I think there are probably quite a few unintentionally hard-coded place in cloud-init that may have needed to source global settings or the Paths object and don't.... hrm
[19:36] <blackboxsw> cloudinit/cmd/devel/logs.py for instance. ds-identify (not sure how we override that globally)
[19:36] <meena0> cloud-init is the only thing that writes to /run
[19:37] <blackboxsw> generally Paths.run_dir should be the place that gets setup globally for the top-level /run/cloud-init dir \.
[19:37] <blackboxsw> so in principal that should be it... but there are places which probably should have sources Paths and didn't
[19:39] <blackboxsw> parts of cmd.main, cloudinit/temp_utils.py and cloudinit/sources/helpers/azure.py
[19:42] <blackboxsw> but, it should be ephemeral and lost across instance reboot anyway.  Most consumers external shouldn't be using those files directly, but there's nothing saying they shouldn't either. I know of a couple of ubuntu packages that rely on seeing flat files in /run/cloud-init... but BSD-wise I think you are free to use a more appropriate directory
[19:55] <blackboxsw> I think the pytest issue also relates to the fact that we globally configure [pytest] testpaths  in our tox.ini and we don't specialize those paths down in tests/integration_tests.
[19:55] <meena> oooooooooof
[19:56] <meena> if you put it on /run in BSD it means it's in / which means it's not ephemeral
[19:57] <blackboxsw> so now pytest 7.3.2 actually honors our "tox-global" `[pytest]\ntestpaths = tests/unittests` and fails to load responses python module because our integration tests don't need it and hence don't express that dependency
[19:59] <blackboxsw> meena: per that case, I think cloud-init upstream doesn't treat those files as persistent for anything we store there.... The are used for most recent status due to last boot related to ds-identify, cloud-id detected, instance-data.json, status.json result.json details on the system.
[20:01] <blackboxsw> section 3.15 of filesystemheirarchy standard for linux https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf. Just pointing out that it's blown away per boot
[20:02] <blackboxsw> so I'd not worry about persisting that data across boot if you'd like to write it somewhere else that is ephemeral/variable for *BSD. I'd say move the old files to the new true ephemeral location if BSD has a concept.
[20:05] <meena> https://github.com/canonical/cloud-init/issues/4180
[20:05] -ubottu:#cloud-init- Issue 4180 in canonical/cloud-init "/run is not ephemeral on *BSD" [Open]
[20:05] <meena> So we don't ever read from run? only write?
[20:13] <blackboxsw> meena: certain cloud-init cmdline tools read from /run/cloud-init (cloud-init status, cloud-init query etc ).
[20:13] <blackboxsw> most of the operations are a write-once type thing.
[20:13] <meena0> aye
[20:13] <meena0> So no drama
[20:20] <blackboxsw> meena: not too much. But agreed it's slightly different behavior on *BSD if /run is not cleared per boot. one thing to note as well is ds-identify (which limits datasource detection) emits /run/cloud-init/cloud.cfg to the discovered  datasource names which cloudinit python code will then source as the filtered list of viable datasources to check via the DataSource.get_data calls.
[20:20] <blackboxsw> So, if that list is stale for some reason then cloud-init may not try to walk through all datasources to discover the right platform.
[20:21] <blackboxsw> It may be irrelevant to *BSD as I don't think you use ds-identify, but somethjing to be aware of if you are migrating that Paths.run_dir to something else
[20:21] <meena0> but ds-identify isn't run automatically?
[20:52] <blackboxsw> meena: on systemd-based systems it's automatically run at system generator timeframe https://www.freedesktop.org/software/systemd/man/systemd.generator.html on BSD I wasn't sure anything actually ran it. Do you know?
[20:53] <blackboxsw> that would have informed the review of https://github.com/canonical/cloud-init/pull/4159 I think.
[20:53] -ubottu:#cloud-init- Pull 4159 in canonical/cloud-init "BSD: remove datasource_list from cloud.cfg template" [Merged]
[20:53] <blackboxsw> as I would expect that this hardcoded datasource_list is not necessary if ds-identify is active in BSD-land somehow.
[20:55] <blackboxsw> because ds-identify pre-checks environment variables DMI information kenv etc. and should correctly limit datasource_list to only viable datasources
[21:25] <meena> We don't have such a phase in rc, and we don't have an rc script for it either
[21:26] <meena> which datasource_list wins, btw? the one in /run, or the one I /etc?
[23:44] <blackboxsw> meena: sorry got pulled away. datasource_list from ds-identify reduces the viable list from whatever was originally configured in /etc/cloud/*. If BSD had such an early RC trigger it'd save BSD a lot of time trying and rejecting the full list of all viable datasources as defined in /etc/cloud*.  Basically ds-identify reads /etc/cloud/* datasource_list, and does a quick inspection of DMI and kenv values.
[23:45] <blackboxsw> If any kenv values look like they may match then ds-identify keeps that datasource in the configured datasource_list all others which don't manifest in kenv/DMI attributes are filtered out so that the python code only calls the likely matched subset of datasource.
[23:46] <blackboxsw> if BSD images don't have a predefined shortlist in datasource_list config of /etc/cloud for a given cloud, this amounts to about 10 minutes of wait time on non-OpenStack platforms where OpenStack endpoints are retried for 10 minutes or something
[23:47] <blackboxsw> so when your 4159 PR dropped that shortlist config for datasource_list, it means it would be desireable for *BSD to trigger ds-identify in early boot before cloud-init 'init-local' RC script runs


[00:06] <mjrosenb> hey, does anyone know if the linux-omap4 images that ubuntu is asking me to install work with perf?
[12:25] <xnox> I just realised that adb supports full phone backup.
[12:26] <xnox> not sure how well that works with pushing apps & data from one phone to another though.
[12:26] <xnox> but whould be good enough to test phablet deploy.
[12:26] <xnox> on nexus4 that is.
[12:30] <XorA> xnox: it seems to work well in Titanium backup so should work well in other cases
[12:30] <xnox> hmm... note to self to checkout titanium backup
[19:30] <ogra_> infinity, hey, look, our new community starts producing fixes for libc ... https://lists.launchpad.net/ubuntu-phone/msg00637.html ...
[19:30] <ogra_> (have fun fishing them out of xda froum zips :P )
[19:45] <mosasaur> I'm still trying to play audio from inside a chroot, so far alsamixergui can control the sound volume of apps running under the android host  -- which is extremely cool by the way, since this is the first time I can increase left/right master/headphones separately -- but any apps from within the chroot are inaudible or won't even start playing.
[19:47] <ogra_> do you have /dev bindmounted ?
[19:47] <mosasaur> ogra_: yes
[19:47] <ogra_> and proc and sys too ?
[19:47] <mosasaur> yes
[19:48] <ogra_> then i would guess its a permission thing
[19:48] <mosasaur> I have chmod 777 /dev/snd
[19:49] <infinity> ogra_: Enabling debug options isn't a fix. :P
[19:49] <ogra_> hehe
[19:50] <ogra_> no, but his fix will likely end up in a similar place in a zip
[19:50] <infinity> But the bug won't be in glibc.
[19:50] <infinity> Just sayin'.
[19:50] <ogra_> tell him :)
[19:51] <ogra_> the next few months will surely be fun ...
[19:51] <infinity> Err, are our images based on quantal still? :/
[19:51] <ogra_> yes
[19:51]  * infinity notes him talking about libc-2.15.so
[19:51] <ogra_> a) we dont have the phablet packages in raring
[19:51] <ogra_> b) we need https://blueprints.launchpad.net/ubuntu/+spec/client-1303-cdimage-android-builds
[19:52] <ogra_> i gues we'll start raring images around april
[19:52] <infinity> Anyhow.  I don't see him claiming it's a libc bug either.  It's just that turning on IO_DEBUG allows libc to trap the bug he has elsewhere.
[19:54] <ogra_> haha, and there is an infinity553 in #ubuntu-touch
[19:55] <ogra_> i wonder if xnox' xchat fix would catch that
[20:11] <ogra_> xnox, how about a usb-creator -> phablet-flash spec ?
[21:23] <xnox> ogra_: sure go ahead.
[21:24] <xnox> ogra_: you can even dishout assignee to be me.
[21:24] <xnox> ogra_: not sure about xchat catching that ;-)
[21:24] <ogra_> not tonight anymore, but i'll add it over the weekend
[21:24] <xnox> kk.
[21:24] <ogra_> haha
[21:24]  * ogra_ goes to watch wok racing on tv now
[21:48] <lilstevie> ogra_, haha welcome to the world of xda/android, where if it isn't in a .zip it isn't good enough
[21:48] <ogra_> heh, yeah
[21:49] <lilstevie> it is going to make the lists painful
[21:50] <lilstevie> (the influx of android "devs)
[21:50] <ogra_> well, its seemingly our new part of the community
[21:51] <lilstevie> and I do use that term liberally
[21:51] <ogra_> so we'll have to live with it
[21:51] <ogra_> yeah, there is already a thread about overclocking and replacing the bootloago with a running mario on the list
[21:51] <ogra_> (in the same mail)
[21:52] <lilstevie> heh
[21:52] <lilstevie> not surprised in the slightest
[21:53] <ogra_> it gives a good impression of what to expect i think
[21:53] <lilstevie> yeah
[21:55] <lilstevie> it is a good window into what the modding community will be like post release too
[21:55] <lilstevie> and of what google currently deal with on their own lists
[21:56] <ogra_> yeah
[21:56] <ogra_> well, you get what you asked for i guess
[21:57] <lilstevie> heh
[21:57] <lilstevie> it is a delicate balance really
[22:00] <lilstevie> I love how the mailing list is resembling a forum at the moment
[22:27] <wookey> what's wrong with android devs? are they all clueless?
[22:28] <wookey> or all use windows? Or both :-)
[22:32] <ogra_> heh, they are young, bear with them :)
[22:32] <lilstevie> wookey, the common name for these devs is "winzip devs" cause the extent of their dev'ing is that they used winzip removed extra apks, added a few others, and then release it as their own creation
[23:19] <wookey> aha. wel I just got apt built for arm64. generating a new rootfs now...
[23:20] <wookey> an image with apt in it and working networking is suddenly a lot more useful...
[23:20] <lilstevie> :o do you have an arm64 device?
[23:20] <wookey> nope - there are none. only models
[23:20] <wookey> and I didn't run that till last week
[23:21] <wookey> you can work on an arch for 2 years without actually _running_ any native code :-)
[23:22] <lilstevie> heh
[23:22] <ogra_> he imagines an arm64 device and then builds on it :)
[23:23] <lilstevie> heh
[23:24] <stgraber> and people used to complain they had to wait years to get Linux support for thei hardware. Now they have to wait years for the hardware that Linux supports to actually exists ;)
[23:25] <ogra_> yeah :)
[23:25]  * lilstevie wants an arm64 device yesterday
[23:25] <ogra_> easy ...
[23:26] <lilstevie> lol
[23:26] <ogra_> if you want it yesterday you have to invent time traveling anyway so you can travell to wookey's house to next year, pick it up and go back to yesterday
[23:26] <lilstevie> that does sound easy
[23:26] <ogra_> yeah, totally trivial
[23:27] <lilstevie> in 20 years when I finish inventing the time travel machine I will just send it back to today
[23:27] <ogra_> http://www.amazon.com/Back-Future-Capacitor-Replica-Unlimited/dp/B001M5PTQM
[23:27] <ogra_> just needs the peripherials
[23:28] <wookey> I had to do some nsty hackery on curl. first real bodge in the whole bootstrap, but I decided I was in a hurry :-)
[23:28] <wookey> oh and nss is evil. Did I complain about that already? yuk.
[23:29] <wookey> why do we need 6 different ssl implmentations anyway?
[23:29] <wookey>  (curl supports 6 and build-deps on 3)
[23:30] <lilstevie> wookey, because 5 wasn't good enough


[00:00] <james_w> are they required to be fat32 formatted?
[00:00] <TheMuso> kirkland: For some reason I am unable to merge your branch: bzr: ERROR: Cannot lock LockDir(lp-29098832:///~vcs-imports/grub-installer/main/.bzr/branchlock): Transport operation not possible: readonly transport
[00:00] <kirkland> TheMuso: huh?
[00:00] <kirkland> TheMuso: weird
[00:00] <TheMuso> kirkland: good question.
[00:01] <james_w> TheMuso: are you trying to commit in a checkout of a http branch?
[00:01] <TheMuso> james_w: I am trying to merge a branch into a lightweight checkout.
[00:01] <evand> james_w: yeah, it looks for a vfat partition, if it doesn't find one, it gives you an option to format the entire device to create one
[00:01] <james_w> evand: it may well be a bug there, give me a few to play a bit more
[00:01] <evand> I suspect the calls to partman might be lacking certain necessary options as there's been more than one bug report about this
[00:02] <james_w> TheMuso: I suspect you have a lightweight checkout over http:// rather than bzr+ssh://
[00:02] <evand> james_w: perhaps try setting the lba flag using parted
[00:02] <kirkland> TheMuso: I was able to branch bzr branch lp:~kirkland/grub-installer/281492
[00:02] <TheMuso> james_w: I am almost certain I don't, but I will double check.
[00:02] <james_w> TheMuso: "bzr info" may help
[00:04] <xivulon_> evand, isn't proper_mountpoints supposed to be run after autopartition-loop?
[00:04] <evand> xivulon_: yes, it will be as it's in check.d
[00:05] <xivulon_> does not look like autopartition-loop has been executed at all by the time check.d is run
[00:05] <james_w> hey xivulon_, how are you/
[00:05] <xivulon_> hi james_w
[00:06] <kirkland> TheMuso: any luck?
[00:06] <TheMuso> kirkland: Seems better once I used the full URL to checkout the main branch of grub-installer and merging yours now. Very weird.
[00:07] <kirkland> TheMuso: so i've tested this patch, and it works
[00:07] <james_w> TheMuso: do you have "bzr launchpad-login" set?
[00:07] <TheMuso> kirkland: Great.
[00:07] <kirkland> TheMuso: the only thing that bothers me is that I never did figure out *where* frdisk was getting set
[00:07] <TheMuso> james_w: Yes I do, as I use it elsewhere.
[00:07] <kirkland> TheMuso: but this patch definitely "un-sets" it in the /dev/vd* case
[00:08] <TheMuso> kirkland: The best way I have tracked such things down is to use set -x on the script, and open the execution path and the script side by side, and follow them both to see what logic is used and where variables are set.
[00:08] <kirkland> TheMuso: true, that's my method too ;-)
[00:09] <xivulon_> yep it looks like autopartition-loop is not being run
[00:17] <TheMuso> kirkland: uploaded.
[00:37] <xivulon_> seems that autopartition-loop is supposed to be started by 10initial_auto, but that one exits quite early because of get_auto_disks return null
[00:37] <xivulon_> cjwatson, evand ^
[00:39] <xivulon_> /var/lib/partman/devices/ is empty
[01:30] <xivulon_> which is because in partman/init.d/parted: # Exclude devices that have mounted partitions.
[01:32] <xivulon_> well far too late, bed time
[01:47] <xivulon_> ah preseeding partman/filter_mounted does the trick...
[01:53] <xivulon_> evand please upload wubi rev 511 which corrects the above
[01:54] <xivulon_> really bed time
[04:56] <evand> ah, my mistake for not mentioning that.  It didn't immediately occur to me that it would affect you.
[04:56] <evand> Will do.
[05:15] <evand> xivulon: done, it should show up in the next CD build.
[05:22] <evand> I think it would be wise for me to start making mention of new preseed keys on<EMAIL_ADDRESS> I've made a note to remember to do that next time as part of the ubiquity release process.
[06:11] <TheMuso> cjwatson: Seems that a recent update probably to grub has solved the netboot dmraid installation alongside windows issue I was seeing.
[06:15] <evand> TheMuso: root-by-uuid or something else?
[06:15] <TheMuso> evand: Not sure.
[06:15] <TheMuso> It works, thats all I'm really concerned about now.
[06:15] <evand> :)
[08:27] <xivulon_> cjwatson, could you please apply the fix mentioned in 283520?
[08:28] <xivulon_> fyi I also found the reason of "No root file system" see ^^
[09:21] <CIA-14> grub-installer: cjwatson * r749 ubuntu/ (debian/changelog grub-installer):
[09:21] <CIA-14> grub-installer: Cope with new UUID-style groot when handling
[09:21] <CIA-14> grub-installer: grub-installer/bootdev_directory (LP: #283520).
[09:23] <CIA-14> grub-installer: cjwatson * r750 ubuntu/debian/changelog: releasing version 1.32ubuntu8
[09:24] <evand> I was hoping to have a fix for the Kubuntu issue to upload with ubiquity, but I can no longer reproduce that, so rather hold up the release I'll take care of uploading it now.
[09:24] <evand> rather than
[09:25] <evand> erm, actually
[09:25] <evand> I should probably wait for that grub-installer upload to hit the archive
[09:26] <davmor2> evand: which one on Kubuntu?
[09:26] <evand> oh good, you're here
[09:26] <davmor2> I'm doing smoke test latter I can see if I can still reproduce it.
[09:26] <evand> davmor2: can you still reproduce bug 270423
[09:26] <evand> with the latest daily-live Kubuntu CDs?
[09:27] <evand> ok
[09:27] <evand> much appreciated
[09:29] <davmor2> evand: I'll ping you after and let you know
[09:29] <cjwatson> evand: as I noted in the bug I suspect my fix might actually be wrong ...
[09:30] <cjwatson> I'm not sure what the semantics of translating UUIDs to grub4dos ought to be
[09:30] <cjwatson> if you happen to know, please take a look
[09:37] <yannickm1> cjwatson: Are you there ?
[09:38] <cjwatson> yannickm1: phone
[09:38] <yannickm1> k
[09:50] <xivulon> cjwatson, evand, did you see ^?
[09:50] <xivulon> do you want me to contact grub4dos devs?
[09:52] <xivulon> I would need to add UUID discovery to wubi too (was under the impression that UUID were not going to land in time), now grub4dos uses heuristics (find --set-root)
[09:58] <xivulon> ah 283520 is fixed already, many thanks cjwatson
[09:59] <evand> xivulon: not necesarily.  See what cjwatson said above.
[09:59]  * evand bed
[10:00] <xivulon> ah one sec have a bit of catch up to do
[10:05] <xivulon> hmm cjwatson I an not sure UUID/relative/path is supported in wubi (using "root ()/relative/path" will certainly work)
[10:06] <xivulon> even if support was added and the change goes into hardy updates we would need to ship a new grub4dos
[10:09] <xivulon> and that does not really change things much, since wubi has a first (embedded) menu.lst that loads a second menu.lst (the one edited by update-grub) using heuristic
[10:10] <xivulon> the second menu.lst does not really change the root device (that is why an empty () is used), setting root there will not help matters
[10:12] <xivulon> I can change all of that but at this stage isn't it a bit late? Also the heuristic while clearly not elegant, has worked quite well so far and I had no complaints about that. It does not suffer from the multiple disks issues
[10:13] <xivulon> admittedly far from bullet proof
[10:13] <yannickm_> cjwatson, i sent the logs and all related files to the mailing list
[10:37] <davmor2> cjwatson: is there meant to be an option in ubiquity to enable encrypted folder?
[10:51] <davmor2> evand: Seems to be working now :-/
[10:51] <davmor2> Kubuntu that is
[11:07] <cjwatson> davmor2: no, didn't make it
[11:07] <cjwatson> xivulon: ok, thanks, I'll tweak grub-installer
[11:07] <davmor2> cjwatson: Okay wonder if it was in and not showing up, that's okay then :)
[11:17] <CIA-14> grub-installer: cjwatson * r751 ubuntu/ (debian/changelog grub-installer):
[11:17] <CIA-14> grub-installer: grub4dos can't handle UUIDs, so tweak previous change to continue using
[11:17] <CIA-14> grub-installer: groot=()/ubuntu/disks in that case (LP: #283520).
[11:19] <CIA-14> grub-installer: cjwatson * r752 ubuntu/debian/changelog: releasing version 1.32ubuntu9
[11:26] <cjwatson> xivulon: ^- should sort it out
[11:27] <xivulon> cjwatson thanks (I do not think there is any need to have anything inside of () but in practice it will work)
[11:29] <xivulon> since groot=NULL -> groot=UUID -> groot=()/rel/path -> /me happy
[11:30] <cjwatson> xivulon: yes, the result of the above will be ()/rel/path
[11:30] <cjwatson> yannickm_: ok, got it, watch for a reply on the list shortly
[11:32] <xivulon> davmor2 can you please test the above once it reaches the ISO? (wubi rev511 + grub-installer 1.32ubuntu9)
[12:40] <yannickm_> cjwatson: Got you reply thanks for the help
[13:31] <cjwatson> evand: I'll take care of ubiquity, sorry for holding you up earlier with grub-installer
[13:34] <CIA-14> ubiquity: cjwatson * r2901 ubiquity/ (d-i/manifest debian/changelog):
[13:34] <CIA-14> ubiquity: Automatic update of included source packages: grub-installer
[13:34] <CIA-14> ubiquity: 1.32ubuntu8, hw-detect 1.63ubuntu4, partman-base 121ubuntu8.
[13:35] <cjwatson> or at least I will once translations download
[13:58] <evand> oh, no worries.  I held it up with Kubuntu.
[14:01] <cjwatson> translations downloading now
[14:05] <james_w> evand: hey, did you see my casper persistence assessment?
[14:06] <evand> checking now
[14:07] <james_w> I apologise in advance for the patches
[14:09] <evand> james_w: ah!  Thanks a bunch.  I'll give that a test and some more thought.
[14:09] <evand> FWIW, if you boot with break=top you can sed in changes to the casper scripts.
[14:09] <james_w> ah, cool, that will be fun
[14:55] <cjwatson> james_w: I actually thought the first hack-patch was fairly reasonable :)
[14:56] <james_w> heh :-)
[15:00] <xivulon> evand by the way you could also have used grubinst/grub4dos in the live USB creator, not that it changes much, but it's confy to stay in the grub world
[15:04] <cjwatson> CDs aren't in the grub world anyway
[15:05] <xivulon> if you extract the content of the ISO into a folder, you can load the kernel/initrd therein which will then do the rest
[15:05] <cjwatson> let's keep it as it is :)
[15:05] <xivulon> s/folder/directory/
[15:09] <persia> xivulon, One of the advantages of using syslinux over grub for USB is that one needn't worry about either the representation of the drive to grub in the booted system or calculating the UUID of the install media at media creation time.
[15:24] <xivulon> persia, not that it matters, but I don't think that either issue would be a major stumbling block, as the grub4dos bootloader (grldr) can set the root based on a file match, and you could easily get the UUID of the target partition for use in kopt
[15:26] <evand> You'd lose isolinux.
[15:26] <evand> err gfxboot
[15:26] <xivulon> correct
[15:27] <xivulon> but things such as kernel upgrades would be easier
[15:27] <evand> I think you're confused as to the purpose of this image.
[15:27] <persia> That's not ideal.  One of the things I don't like about the ubuntu-{mid,mobile} images is the lack of gfxboot.  While I'm unlikely to try to sort it for intrepid, making it definitely not work for USB is not ideal.
[15:27] <evand> It does not get updated, it's effectively a live CD.
[15:28] <persia> Well, with persistence, it could be updated, although I'd think it would be better to just do an install on a USB key for people who wanted that sort of thing.
[15:30] <xivulon> ah you'll probably need casper in the initrd though
[15:30] <xivulon> so "upgrading" to a stock initrd will not get you very far...
[16:03] <CIA-14> ubiquity: cjwatson * r2902 ubiquity/debian/ (14 files in 2 dirs): Update translations from Launchpad.
[16:33] <james_w> I've just done some break=top testing, and the first patch does indeed fix it
[16:33] <james_w> it boots, and changes are present on second boot
[16:34] <evand> fantastic!
[16:34] <evand> I'll continue setting up a test after the meeting.
[16:37] <james_w> will $PERSISTENT=1 become the default when it works?
[16:38] <evand> james_w: can you elaborate on what you mean?
[16:39] <cjwatson> we'll be setting it on USB installs if the relevant widget is selected in usb-creator
[16:40] <james_w> good
[16:40] <james_w> it would be pretty confusing otherwise :-)
[16:45] <evand> 272318 is going to be difficult to fix as the labels are what is growing the partition bar to a large size, and I'm not sure how I could fit all of that text.  Any objections to me stuffing it in a scrolledwindow?
[16:46] <cjwatson> not I
[16:46] <cjwatson> at this point, whatever gets the job done
[16:48] <evand> noted
[16:53] <CIA-14> ubiquity: cjwatson * r2903 ubiquity/ (d-i/manifest debian/changelog):
[16:53] <CIA-14> ubiquity: Automatic update of included source packages: grub-installer
[16:53] <CIA-14> ubiquity: 1.32ubuntu9.
[16:57] <CIA-14> ubiquity: cjwatson * r2904 ubiquity/debian/changelog: releasing version 1.10.6
[17:42] <charlie-tca> Something went wrong fixing the manual partition thing, I think. It now takes my system 18 minutes to boot the live-cd dated 2008-10-15
[17:57] <evand> charlie-tca: why do you suspect a fix for manual partitioning is the cause of the live CD booting slowly for you?
[17:58] <charlie-tca> It wasn't so slow yesterday.
[17:58] <charlie-tca> Could have been another change, I guess.
[18:00] <evand> I suspect so.  The installer is completely removed from the boot process, save the "Install Ubuntu" menu option.
[18:01] <charlie-tca> Okay, I'll try #ubuntu-testing then. Thanks
[18:01] <evand> no problem, sorry that I cannot offer more help than that.
[18:11] <CIA-14> casper: evand * r550 casper.trunk/ (debian/changelog scripts/casper-helpers):
[18:11] <CIA-14> casper: Skip remounting read-only in try_mount as it's unnecessary and
[18:11] <CIA-14> casper: breaks persistence. Thanks James Westby (LP: #274076).
[18:12] <evand> ^ james_w: Thanks a lot.  It worked for me as well.
[18:16] <CIA-14> casper: evand * r551 casper/debian/changelog: releasing version 1.148
[18:16] <james_w> excellent
[18:16] <james_w> I'll test again when that hits the dailies
[18:16] <evand> thanks
[18:17] <james_w> I get lots of errors on shutdown, I'm not sure whether it's to do with persistence, I need to boot again without "quiet splash"
[18:17] <james_w> I imagine it will be aufs troubles
[18:17] <evand> yikes
[18:18] <cjwatson> I wonder if things are getting unmounted in the right order
[18:20] <james_w> evand: is it easy to capture a casper log like you did in that bug?
[18:20] <evand> quite
[18:20] <cjwatson> it's saved in /var/log/casper.log
[18:20] <cjwatson> oh, you mean with set -x?
[18:20] <james_w> if possible
[18:20] <james_w> and this is on shutdown
[18:21] <cjwatson> we should do a "debugging initramfs-tools and casper" session at UDS
[18:21] <cjwatson> by "we" I mean "somebody else"
[18:22] <evand> hahaha
[18:22] <james_w> :-)
[18:23] <evand> james_w: I just ran sed -i '2i set -x' scripts/casper after break=top.
[18:24] <james_w> and that ends up in /var/log/casper.log?
[18:24] <evand> it should
[18:24] <evand> or if it dies before you escape the initramfs, /casper.log
[18:26] <james_w> I need the shutdown part though, is that on volatile storage?
[18:26] <cjwatson> depends how late you need it
[18:26] <cjwatson> the most practical approach might be to spew it to console and disable the actual reboot bit ...
[18:27] <cjwatson> (and turn off usplash so you can see it)
[18:42] <davmor2> cjwatson: I'm just trying the manual partitioning I'm getting a partman failed with exit code 141
[18:43] <evand> davmor2: what version of ubiquity?
[18:43] <charlie-tca> I got the same fail on todays cd
[18:44] <cjwatson> I'm going out for a bit, will look later
[18:45] <evand> I suspect it's the segmented_bar bug
[18:45] <davmor2> evand 1.10.5
[18:45] <evand> davmor2: if I'm correct, that problem should disappear tomorrow.
[18:45] <evand> as the fix is in 1.10.6
[18:45] <davmor2> evand would an update fix it?
[18:46] <evand> ah, duh
[18:46] <evand> yes
[18:46] <evand> well
[18:46] <evand> once 1.10.6 hits the archive
[19:57] <CIA-14> ubiquity: evand * r2905 ubiquity/ (configure configure.ac): Bump to 1.10.7
[21:03] <CIA-14> ubiquity: evand * r2906 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py):
[21:03] <CIA-14> ubiquity: Pack the table containing the partition bars in a scrolled window
[21:03] <CIA-14> ubiquity: (LP: #272318).
[22:30] <xivulon_> evand 01unmount_root create also issues, I assume I have to use ubiquity/partman-skip-umount
[22:33] <xivulon_> I meant 01unmount_busy
[22:37] <xivulon_> yep ubiquity/partman-skip-mount seems to work
[22:37] <xivulon_> but on post-inst I get a hard freeze when X starts
[22:42] <julien_> hello
[22:42] <julien_> I need help for installing ubuntu mobile edition (MID)
[22:43] <julien_> is it the right place for that?
[22:43] <cjwatson> some people here do know about it, but #ubuntu-mobile would be better I think
[22:44] <julien_> ok thanks
[22:50] <xivulon_> cjwatson is ^ correct? It will require a new
[22:50] <xivulon_> wubi release
[22:54] <cjwatson> preseeding ubiquity/partman-skip-unmount for wubi doesn't sound too bad
[22:54] <cjwatson> if you spell it right :)
[22:54] <cjwatson> I have no idea about the X freeze
[22:55] <xivulon_> on it's way...
[22:55] <xivulon_> X freeze is annoying not even alt+sysrq works
[22:58] <cilkay> cjwatson: Hi. I saw one difference between what I passed to the kernel for my preseed installation and what you suggested in your response to my question on the list. I have: append auto locale=en_CA console-setup/layoutcode=en_US You suggested console-setup/layoutcode=us Is that significant?
[22:59] <cilkay> And en_CA is not the same as en_CA.UTF-8 as far as I can tell.
[22:59] <cilkay> I want to end up with en_CA.UTF-8 for locale at the end of the installation.
[23:00] <cjwatson> cilkay: yes, console layouts are not the same as locales
[23:01] <cjwatson> console-setup/layoutcode is the same as what you would put in XkbLayout in xorg.conf
[23:01] <cjwatson> there is no XKB layout called "en_US"
[23:01] <cilkay> ok
[23:02] <cjwatson> cilkay: you can safely set locale=en_CA.UTF-8, although I think it may actually default to that anyway (the code is a bit twisty, I'd have to try it to be absolutely sure)
[23:02] <cilkay> I'm going to try another installation right now.
[23:03] <cilkay> From what I recall, I had tried setting to locale=en_CA.UTF-8 but I had gotten the prompt for locale when the system booted.
[23:03] <cilkay> It was a week ago so that might not be accurate.
[23:03] <cilkay> I'll try right now.
[23:06] <cjwatson> ok, I'm seriously not getting any further with 283861 until I have coffee
[23:06] <cjwatson> you know when you zone out, read the same thing you just read, zone out, read the same thing you just read ...?
[23:07] <cilkay> No, never happens here :)
[23:07]  * TheMuso can agree with cjwatson on that one, although sleep is usually the fix for me. I am not a fan of pumping myself with coffee.
[23:07] <cilkay> I haven't been able to preseed away the prompt for removing existing logical volumes either so I gave up on LVM and just went for regular partitions.
[23:08] <cjwatson> TheMuso: it definitely isn't good long-term
[23:08] <TheMuso> cjwatson: Indeed, which is why I just stay away. :)
[23:09] <cjwatson> cilkay: the hardy installation guide is wrong here - the correct rune is "d-i partman-lvm/device_remove_lvm boolean true"
[23:10] <cilkay> thanks
[23:11] <cilkay> I probably won't use LVM in any case because I haven't figured out how to specify a different volume group name per machine. I don't like naming them all the same thing because I've run into problems when I've had to move a physical disk from one machine to another and had a name clash on the volume group.
[23:12] <xivulon_> evand, please upload Wubi rev 512
[23:28] <cilkay> cjwatson: Just did another preseed installation taking into account your suggestions. Same problem. The keyboard mapping seems to be wrong because when I type, I see diamonds. I've pasted my configuration here: http://dpaste.com/84699/
[23:30] <cilkay> Rats! It seems ssh is not running on the freshly-installed system.
[23:32] <cilkay> That's because it wasn't installed. Doing another installation.
[23:40] <cilkay> The keyboard mapping is fine, though I have no idea why.
[23:40] <cilkay> The *only* thing I changed between the previous broken mapping and this one is that I enabled a commented out line for installing OpenSSH server
[23:41] <cilkay> I suspect that the "server" task has files for locales whereas "standard" might now.
[23:41] <cilkay> not
[23:41] <cilkay> Previously, I had:
[23:41] <cilkay> tasksel tasksel/first multiselect standard
[23:42] <cilkay> The keyboard mapping was wrong and I couldn't ssh to the box to correct it.
[23:42] <cilkay> I commented out that line and removed the comment from the following line:
[23:43] <cilkay> d-i tasksel/first multiselect OpenSSH server
[23:43] <cilkay> Now the locale is fine and all is right with the world.
[23:43] <cilkay> I think I had two problems.
[23:43] <cilkay> 1. I had set the layoutcode to en_US.
[23:44] <cilkay> 2. Locales weren't being installed.
[23:44] <cilkay> All the irrelevant bits that I had in the preseed file regarding console-setup probably had nothing to do with it.
[23:44] <cilkay> I had added those out of desperation when nothing else seemed to be working.
[23:45] <cilkay> I had the much simpler preseed file, as per the paste I have above, before and the keyboard mapping was wrong.
[23:45] <cilkay> Anyway, cjwatson thank you very much for putting me on the right track.
[23:46] <cilkay> I plan to document the whole thing once I've finished.
[23:46] <cilkay> I have a nice setup now with apt-cacher, PXE, and preseeding.
[23:47] <cilkay> I have to configure KDE with the kiosk tool and figure out how to deploy those changes.
[23:47] <cilkay> I'll probably use cfengine to handle change management.
[23:49] <cilkay> Oh, another item on the TODO list... figure out how to get all these preseeded machines authenticating against OpenLDAP or OpenLDAP/Kerberos.
[23:50] <cilkay> I'm scarred by past encounters with both so I'm a bit wary of them but I figure the third time around might go smoother.
[23:51] <cjwatson> cilkay: thoroughly bizarre - (a) locales aren't part of the server task (b) they shouldn't affect console-setup anyway!
[23:52] <cjwatson> cilkay: (neither task has them, but pkgsel is supposed to install them anyway)
[23:52] <cjwatson> cilkay: that said you ought to be putting openssh-server not OpenSSH server in tasksel/first
[23:53] <cjwatson> cilkay: usually in order to figure out what's wrong with console-setup I need /etc/default/console-setup after the broken installation
[23:53] <cilkay> Which I couldn't get to you because I didn't have sshd running.
[23:53] <cjwatson> cilkay: I'm still somewhat interested in what's causing it, even though it's fixed for you, since you aren't the first person who's had the problem and I haven't really got to the bottom of it
[23:53] <cilkay> It's easy for me to reinstall this and try to repeat it.
[23:53] <cilkay> It takes only a few minutes.
[23:54] <cilkay> I have all the packages sitting in my apt-cacher cache and with PXE booting, it's a matter of me rebooting and typing "auto" at the grub prompt.
[23:55] <cilkay> BTW, the OpenSSH bit, I found that on-line somewhere.
[23:55] <cjwatson> oh, hmm, I can't say I really support the 'auto' stuff, that's something that Phil Hands developed in Debian and I haven't taken a good look at yet
[23:55] <cilkay> No, no. That's just my GRUB boot label.
[23:55] <cilkay> I could have called it "mickey mouse" and it would still work.
[23:56] <cjwatson> it is? you have "append auto ..."
[23:56] <cilkay> Oh that part.
[23:56] <cilkay> Again, that I copied/pasted from someplace, don't recall where.
[23:56] <cilkay> Get rid of the "auto" there?
[23:57] <cjwatson> TBH it probably doesn't make any difference, we don't have that stuff in our initrd :)
[23:57] <cilkay> I was talking about the boot label.
[23:57] <cjwatson> that doesn't matter
[23:59] <cilkay> cjwatson: Isn't this wrong? ==> tasksel tasksel/first multiselect standard
[23:59] <cilkay> Note the leading tasksel.
[23:59] <cilkay> That should be "d-i", I think.
[23:59] <cilkay> That could have been why it was borked.