[00:44] <CIA-7> debian-installer: adconrad * r1716 ubuntu/ (build/config/armel/omap4.cfg debian/changelog): Move omap4 kernels to 3.4.0-204.
[07:41] <arthurlutz> hi
[07:41] <arthurlutz> am having problems with casper on a livecd/installer generated by remastersys
[07:42] <arthurlutz> there seems to be missing /dev/urandom and /dev/shm when I reach  25adduser
[07:43] <arthurlutz> any hints or errors you can think of ?
[08:26] <ogra_> arthurlutz, nobody here touches remastersys. have a try at their bugtracker or their IRC channel
[08:28] <arthurlutz> ogra_: sure, but this seems to be a problem with casper, not remastersys
[08:28] <arthurlutz> /root/dev/ seems to not be mounted
[08:29] <ogra_> well, do you see it on the official livecd image from that ubuntu version ?
[08:29] <arthurlutz> when I do break=bottom it should ?
[08:29] <ogra_> tools like remastersysw tend to apply hacks and diffs to the build process ...
[08:30] <ogra_> err s/build/boot/
[08:30] <ogra_> no i mean if you boot a normal ubuntu live image of the release you are trying to remaster, do you see casper errors ?
[08:31] <ogra_> if not, thats definitely caused by remastersys or the process it uses to roll/modify the image
[08:31] <ogra_> (and i'm pretty sure for all released ubuntu versions we dont have such errors)
[08:33] <arthurlutz> ogra_: ok
[08:33] <arthurlutz> ogra_: thanks for the answer
[12:26] <arthurlutz> I pass break=bottom to grub and in initramfs I find something a bit strange, can you tell me if it is correct or not ?
[12:26] <arthurlutz> mount tells me that
[12:27] <arthurlutz>  /cow on /root type overlayfs
[12:27] <arthurlutz> and also
[12:27] <arthurlutz>  /cow on /root/dev type overlayfs
[12:27] <arthurlutz> and there is  nothing in /root/dev/
[13:05] <arthurlutz> anyone here with some comprehensive documentation for overlayfs ?
[15:04] <arthurlutz> when I chroot in /root
[15:05] <arthurlutz> mount says /dev on /dev type non (rw,bind)
[15:33] <arthurlutz> using debug in grub, I get "sh : 1 : qsd not found "
[15:37] <arthurlutz> and above the cmd is "blkid -o value -s UUID /qev/sr0"
[15:38] <arthurlutz> scratch the above, vim and a weird vnc keyboard did that...
[15:44] <CIA-7> ubiquity: cjwatson * r5541 trunk/ (bin/ubiquity-dm debian/changelog): merge lp:~kentb/ubuntu/quantal/ubiquity/add-custom-dm-scripts
[16:48] <arthurlutz> forcing aufs instead of overlay to see if it works better...
[19:41] <CIA-7> debian-installer: adconrad * r1717 ubuntu/ (6 files in 2 dirs): Move master kernels to 3.5.0-4.
[21:05] <stgraber> cjwatson: weird... if I believe my automated testing (that I finally ported to quantal), dual stack in d-i is busted. Though netcfg hasn't changed and the tests pass fine on precise...
[21:05]  * stgraber investigates
[21:06] <stgraber> (all the ipv4 and ipv6 tests pass individually, it's just when running in a dual-stack environment that it fails)
[21:06] <cjwatson> busybox busted maybe?
[21:06] <cjwatson> or glibc, god help us
[21:07] <stgraber> that or I messed up something in the new isc-dhcp that somehow breaks ipv6 connectivity when calling the dhclient script
[21:07] <stgraber> kind of hoping for that one already ;)
[21:08] <stgraber> busybox or glibc sounds a lot less fun to debug
[21:10] <stgraber> hmm, that's odd
[21:10] <cjwatson> ah, well, we knew the netcfg / dhcp client interface was fragile as all hell ...
[21:11] <stgraber> ~ # ls /proc/sys/net/ipv4/conf/
[21:11] <stgraber> all      default  eth0     lo       sit0
[21:11] <stgraber> ~ # ls /proc/sys/net/ipv6/conf/
[21:11] <stgraber> all      default  lo       sit0
[21:11] <cjwatson> at one point I remember having to fix one of the dhclient scripts to stop bringing the entire interface down (both families) every time it was called
[21:11] <cjwatson> smells a bit like that
[21:12] <stgraber> well, that wouldn't explain why eth0 would vanish from ipv6/conf in proc would it?
[21:12] <cjwatson> er, I forget :)
[21:38] <stgraber> cjwatson: found it
[21:38] <stgraber> addr flush triggers the bug
[21:39] <stgraber> cjwatson: http://paste.ubuntu.com/1085255/
[21:43] <cjwatson> does addr -4 flush trigger it?
[21:43] <cjwatson> since I think that's the fix I remember applying to some dhclient script
[21:44] <stgraber> -4 is safe indeed
[21:44] <cjwatson> I mean I guess we might need -6 flush occasionally ...
[21:45] <stgraber> -6 is the one breaking the world indeed...
[21:46] <stgraber> kind of surprised nobody noticed it already, it's not like I'm running a 3.5 kernel or anything fancy, I'm running the stable 12.04 kernel!
[21:48] <stgraber> reproduced on 3.5 though
[21:55] <stgraber> filed bug 1023174
[21:55] <ubot2> Launchpad bug 1023174 in linux ""ip -6 addr flush" flushes much more than just the addresses" [Undecided,New] https://launchpad.net/bugs/1023174
[21:55] <stgraber> will workaround in isc-dhcp for now
[22:09] <stgraber> cjwatson: test suite now passes with an hardcoded "-4" argument, though I'll make sure this bug is escalated to the kernel team because isc-dhcp definitely calls "ip -6 addr flush" in some ipv6 cases
[22:09] <stgraber> we apparently don't hit these in NetworkManager or netcfg but I'm guessing someone using ifupdown directly probably would
[22:18] <stgraber> isc-dhcp uploaded, will do a d-i upload a bit later to get new netboot images built (as that's what the automated testing is using)
[22:54] <stgraber> I was kind of hoping to finish that open-iscsi merge today but apparently I'll need to update hw-detect for that too, currently getting a nice d-i red screen when running with the new udeb