[00:05] <skaet> Riddell,  have start ed off the kubuntu alternates build.   They should show up on the iso tracker shortly.
[00:06]  * skaet has updated the pad to make the rebuilds include them.
[00:21] <skaet> infinity, ogra_ can you look at the bug that hggdh has flagged?
[00:21] <skaet> bug 1028664
[00:21] <ubot2> Launchpad bug 1028664 in debian-installer "keyboard does not work on quantal-server-armhf+omap4.img" [Critical,New] https://launchpad.net/bugs/1028664
[00:23] <skaet> Riddell,  ScottK,   kubuntu alternates now posted.
[00:23] <infinity> skaet: I can try to reproduce/confirm it, I probably don't have the spare cycles to spend time debugging and fixing it.
[00:24] <skaet> infinity,  confirming it would be good.    We can decide what to do tomorrow after Europe comes online.
[00:25] <skaet> slangasek, ^ FYI.
[00:26] <slangasek> hggdh: is it only the server image that's affected?
[00:26] <infinity> My guess is that Oli only tested this via serial (which is how Real Men install servers), but I'm grabbing an image to see if I get console response with a USB keyboard.
[00:28] <infinity> If it works on serial but not a USB console, though, I wouldn't call that an Alpha blocker, just an annoyance that should be fixed before final release.
[00:33]  * skaet nods
[00:39] <infinity> Well, that's cute.  I get no USB keyboard support, but I also get no serial console.
[00:39] <infinity> I wonder how this is meant to work. :P
[00:40] <slangasek> hmm
[00:40] <slangasek> this is with the all-new squashfs stuff, right?
[00:40] <slangasek> has anyone *actually* tested it interactively up to now? :P
[00:40] <infinity> Yeah, I imagine so, but I'm not sure how that should matter.
[00:41] <infinity> The "make bootable" bits should be the same.
[00:41] <infinity> Which should include sane commandlines, etc.
[00:41] <slangasek> ah, true enough
[00:42] <infinity> Well, the lack of serial console could/should be command-line issues.
[00:43] <infinity> The USB keyboard thing seems more like a "blame the kernel" deal.
[00:43] <infinity> But someone will need to fix A to debug B, perhaps. :P
[00:43] <slangasek> the kernel, or the initramfs
[00:43] <infinity> Well, the kernel, or the (lack of) kernel modules in the initrd?
[00:43] <slangasek> yes
[00:43] <infinity> That's all "kernel" to me. ;)
[00:44] <slangasek> pretty sure the bugs in the latter are the responsibility of the foundations team to fix ;)
[00:45] <infinity> Well, yes.  I wasn't referring to the team, but the bit that's not working. ;)
[00:45] <infinity> Anyhow, let me have a quick poke at this card and see why it thinks I don't deserve a serial console.
[00:46] <infinity> ... because it has a boot.scr-serial alongside boot.scr that isn't the default.  Intuitive!
[00:49] <infinity> [    3.334655] usb 1-1.3: New USB device found, idVendor=046d, idProduct=c31c
[00:49] <infinity> [    3.342926] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[00:50] <infinity> [    3.350891] usb 1-1.3: Product: USB Keyboard
[00:50] <infinity> [    3.355651] usb 1-1.3: Manufacturer: Logitech
[00:50] <infinity> Sure looks there to me...
[00:50] <slangasek> and does it work?
[00:51] <infinity> Yeah, that's harder to tell, when d-i is booted to serial.
[00:51] <infinity> No console.
[00:51]  * slangasek nods
[00:51] <slangasek> hmm, where did you see this boot.scr-serial?
[00:51]  * infinity assumes there must be a cake and eat it too option.
[00:51] <infinity> slangasek: In the vfat partition.
[00:52] <slangasek> I just downloaded the daily server image linked from the iso tracker, and I don't see that
[00:52] <slangasek> oh
[00:52] <slangasek> that wasn't a server image, sigh
[00:53]  * slangasek tries again
[01:01] <slangasek> infinity: by the by, where does the boot.scr get generated?
[01:02] <infinity> slangasek: On nusakan.  debian-cd/tools/boot/quantal/post-boot.*
[01:02] <infinity> Ish.
[01:02] <slangasek> ok. because I think it would be just peachy if we would also include a suitable source representation on the image
[01:03] <slangasek> without which it's bloody annoying if you have to ever edit the commandline for booting on a panda
[01:03] <infinity> You mean you don't like editing out the binary bits with vim before you redo it? :)
[01:03] <slangasek> I kinda don't
[01:03] <infinity> Heh.
[01:03] <infinity> Yeah, including the matching boot.script would be simple enough.
[01:03] <infinity> I can commit that right now.
[01:04] <infinity> I can commit that as soon as I get a gnome-terminal that works...
[01:05] <ogra_> infinity, slangasek, cp boot.scr-serial boot.scr .... on the first partition of the SD
[01:05] <infinity> ogra_: Yeah, we found it.
[01:05] <ogra_> oh, ok
[01:05] <ogra_> then i'm actually off to bed
[01:06] <infinity> ogra_: Does the kernel not do sane autodetection like it can on x86? :(
[01:06] <ogra_> autodetection of what ?
[01:07] <infinity> On x86, if you have a physical console attached (ie: keyboard and monitor), you get a framebuffer d-i, if you don't, it falls back to serial.
[01:07] <infinity> Which is much handier.
[01:08] <ogra_> ah, no, i have never seen that working
[01:08] <infinity> I'm entirely prepared to believe that the omap kernel doesn't give us enough info to pull that trick, but it's also possible that we could and we just don't.
[01:08] <ogra_> on omap i even get a broken installer if i dont force the framebuffer off when using serial
[01:09] <ogra_> you end up with display on framebuffer and input on serial
[01:10] <infinity> Well, that would be better than the current situation, which is no input. ;)
[01:10] <ogra_> that sounds like a kernel bug though
[01:11] <ogra_> anyway, i'll happily look into that if its not 3am ... really off to bed now
[01:17] <infinity> slangasek: Alright, future spins should have boot.script and boot.script-serial on the SD to match the compiled versions.
[01:17] <slangasek> infinity: ta :)
[01:22] <infinity> So, getting as far as installing the base system, then chrooting in and running a getty on tty1, my keyboard works.
[01:23] <infinity> Kinda wasn't expecting it to...
[01:23] <infinity> Ahh, no.  There it is.
[01:24] <infinity> It was during the hardware detection stage of d-i, the keyboard sprung into existence as an input device.
[01:24] <infinity> That seems like suboptimal timing.
[01:25] <RAOF> Yeah, the keyboard doesn't work in the initramfs. Which is kinda annoying, because it doesn't find my root device correctly, so dumps me in the initramfs...
[01:26] <infinity> RAOF: Well, in this case, it doesn't work until much after you need it to press the "make it work" key. :P
[01:26] <infinity> RAOF: Which is even worse.
[01:26] <RAOF> Hah!
[01:26] <slangasek> infinity: do you know why it's picked up so late?
[01:27] <slangasek> is it not udev-driven?
[01:27] <infinity> slangasek: I imagine the module just isn't around.
[01:27] <slangasek> is this not booting to the squashfs?
[01:28] <infinity> No, the squash is used as source media only, I think.
[01:28] <infinity> It's booting to a d-i initrd.
[01:28] <slangasek> ok
[01:28] <infinity> At least, that's what it looks like to me.
[01:28] <infinity> This is the first time I've seen this new magic. :P
[01:28] <slangasek> :)
[01:29] <infinity> If I had to guess, I'd just say the hid* stuff isn't available on boot.
[01:29] <infinity> But that requires more digging.
[01:31] <infinity> Actually, I guess just rebooting would make that easy to confirm.
[01:31] <infinity> Yeah, no /lib/modules/3.4.0-204-omap4/kernel/drivers/hid on the boot image.
[01:31] <infinity> So, it gets pulled in later via udebs.  Which is, of course, useless.
[01:32]  * slangasek nods
[01:32] <slangasek> is this initrd being generated by d-i, or on nusakan?
[01:33] <infinity> The latter, I suspect.  But that's another "not sure".
[01:33] <infinity> Thankfully, debian-cd is very sane and reasonably hackab... Oh, wait.
[01:34] <slangasek> comes from d-i
[01:34] <slangasek> via tools/boot/quantal/boot-armhf+omap4
[01:34] <slangasek> ubuntu/dists/quantal/main/installer-armhf/20101020ubuntu162/images/omap4/cdrom/
[01:34] <infinity> Ahh, kay.
[01:34] <infinity> Oh, right.  The cdrom bits.
[01:34] <infinity> Derp.
[01:34] <infinity> I knew that.
[01:34] <infinity> And I'm betting no one's dusted those off in, like... Ever.
[01:39] <infinity> So, looks like I need input-modules-$ver.udeb
[01:39] <slangasek> build/pkg-lists/cdrom/armel/omap.cfg -> build/pkg-lists/cdrom/armel/omap4.cfg?
[01:39] <infinity> I just got there. ;)
[01:39] <slangasek> ok
[01:39] <slangasek> you want to follow it through?
[01:39] <infinity> Yep.
[01:43] <infinity> netboot wanted the same treatment.
[01:43] <infinity> You know, I think I even remember someone once claiming that netboot didn't work with a USB NIC.
[01:43] <infinity> That would be why.
[01:43]  * infinity shakes his head.
[01:47] <RAOF> While we're on the subject, how can I debug why my netinst install can't find it's root on the USB device?
[01:50] <infinity> RAOF: Also armhf+omap4?
[01:50] <RAOF> Yes.
[01:50] <infinity> precise or quantal?
[01:50] <RAOF> From the quantal netinst images, circa 3 days ago or so.
[01:51] <infinity> Define "find its root".
[01:51] <infinity> The kernel boots, and then no root?
[01:51] <infinity> Or no kernel?
[01:51] <RAOF> Kernel boots, dumps me in initramfs having not found /bin/init
[01:51] <RAOF> At this point I can't really tell why it hasn't found that, because no keyboard in the initramfs ;)
[01:51] <infinity> Oh, this reminds me of another d-i bug I was going to fix.  But it shouldn't present that way...
[01:52] <infinity> Oli was telling me that flash-kernel still just doesn't work at all, because our d-i images don't have a partition table that makes flash-kernel happy.  Or something.
[01:53] <infinity> But that would present as you ending up with the installer in an infinite loop on reboot, not what you described.
[01:53] <infinity> Meh, I need to wipe one of my USB drives, so I can test both of these bugs and see WTF is going on.
[01:54] <infinity> Or go rustle up a USB stick.
[01:54] <RAOF> Or you could make it so that the keyboard works in the initramfs, and I could tell you what had actually gone wrong :)
[01:54] <infinity> RAOF: Anyhow, I'm pretty sure netboot is "known not-working", but if I can fix it in the same d-i upload with minimal effort, what the heck.
[01:55] <infinity> RAOF: You netbooted... Use a serial console?
[01:55] <RAOF> I don't *have* a serial console.
[01:56] <RAOF> netboot-fb for me.
[01:56] <infinity> I can see how that would be frustrating. ;)
[01:56] <infinity> That said, I'm not sure that dumping all the usb/hid stuff in every initramfs is the right answer.
[01:56] <infinity> Though, maybe it is for omap.  I dunno.
[01:56] <infinity> I'll ponder that later.
[01:59] <infinity> ... as he gets halfway through the install before noticing this isn't netboot.
[01:59] <infinity> La la la.
[02:01] <infinity> Reason number 34 for a local mirror:
[02:01] <infinity> root@vishnu:~# zcat /srv/mirrors.0c3.net/ubuntu-ports/dists/quantal/main/installer-armhf/current/ima
[02:01] <infinity> ges/omap4/netboot/boot.img-serial.gz > /dev/mmcblk1
[02:16] <infinity> RAOF: I'd suggest you try the new server image, but.  Oops.  No keyboard. ;)
[02:18] <micahg> kenvandine: freeze anyone?
[02:19] <kenvandine> micahg, i was fixing the ftbfs from earlier
[02:20] <micahg> kenvandine: ah, hrm, okies
[02:20] <infinity> FTBFS fixes still change the archive. :P
[02:20] <kenvandine> failed on i386
[02:22] <infinity> That's a curious failure.
[02:23] <micahg> indeed
[02:25] <infinity> Okay, bored with debugging netboot, want cookies.
[02:25] <infinity> Uploading the d-i fix for the server keyboard issue.
[02:37] <micahg> kenvandine: I was able to replicate the FTBFS in an i386 quantal chroot
[02:38] <kenvandine> i could do once
[02:38] <kenvandine> but running the tests a second time they pass
[02:38] <kenvandine> it's very odd
[02:38] <kenvandine> and they pass first time outside of a package build
[02:55] <infinity> ...
[02:55] <infinity> RAOF: So, uhm.  quantal/omap4 netboot works flawlessly for me.
[02:56] <infinity> RAOF: I'm now very confused as to why people claim it doesn't. :P
[02:56] <RAOF> infinity: Maybe I just need to flash a new image? Has it changed in the last couple of days?
[02:56]  * infinity wonders if the -fb variant is somehow broken when the -serial one works, and tries that.
[02:57] <infinity> RAOF: Well, d-i has been rebuilt, I didn't think that any of the things that were supposedly broken have been unbroken.
[02:57] <infinity> RAOF: But... It all works for me.
[02:58] <infinity> RAOF: (on serial... Testing FB now)
[02:59] <infinity> RAOF: Are you doing any funky partitioning, just just doing Guided-whole-disk?
[02:59] <infinity> RAOF: It could be that partman is doing broken things in some cases, maybe.
[03:00] <infinity> Man, 24 inches of HD aubergine is kinda jarring.
[03:00] <RAOF> The most recent attempt was guided-whole-disk, replacing the ext4 partition with a btfrs one. I've also tried a straight guided-whole-disk in the past.
[03:02] <infinity> RAOF: It's possible that between Luke's upload on the 20th and Oli's uploads yesterday, it all Just Works.
[03:02] <infinity> RAOF: But none of those address the things Oli claimed were broken, so I suspect he lied to me. :)
[03:02] <infinity> (But working is working, I won't complain)
[03:03] <infinity> Of course, someone should fix partman thinking that I want or care about a /boot partition on this thing, but that's a minor nit, if the rest works.
[03:04] <infinity> queuebot: That's a filthy lie and you know it, they're still building.
[03:05] <infinity> RAOF: So, yeah, skip the current version, cause it's obsolete in 20 minutes, but please do try a 20101020ubuntu163 netboot when it's published.
[03:05] <infinity> RAOF: I did make one change to it, so a confirmation that it's not buggered would be nice.
[03:06] <infinity> RAOF: (My 20101020ubuntu162 run will finish shortly to confirm that it worked)
[03:09] <RAOF> infinity: Oh, it doesn't need a /boot?
[03:10] <infinity> RAOF: No, not that it hurts to leave the default partitioning in (which I've done in my quick test here).
[03:10] <infinity> RAOF: Given that, by default, the kernel ends up on the SD card, a /boot makes no sense.
[03:11] <infinity> RAOF: In the case of a uboot on SD using extload to grab the kernel from the hard drive, it *might* make sense, not sure if uboot has issues with huge disks.  But we don't boot that way by default anyway.
[03:20] <RAOF> infinity: You know you've still got e2fsprogs in the precise-unapproved awaiting the pleasure of your review, right?
[03:20] <infinity> RAOF: Yeah, xnox and I talked about it in Nicaragua.  And then we took the rest of the month off.
[03:21] <infinity> RAOF: I should probably just reject it and work with him on it later.
[03:21] <infinity> There.
[03:21] <RAOF> :)
[03:21] <infinity> RAOF: In exchange, review my d-i.
[03:21] <infinity> (Ideally not the same way I just reviewed xnox's upload)
[03:22] <RAOF> Most assuredly!
[03:23] <infinity> RAOF: Actually, don't.
[03:23] <infinity> RAOF: Well, review, but don't accept.
[03:23] <infinity> RAOF: It'll just lead to a no-change upload later to rebuild against Colin's d-i-utils upload sitting there.
[03:24] <RAOF> Shall I eat some quiche until that gets done? :)
[03:24]  * infinity quickly reviews that.
[03:24] <infinity> RAOF: Real men, quiche, etc.
[03:26] <infinity> RAOF: Oh, did that mesa thing go before the TB or something, or were you feeling generous?
[03:26] <infinity> RAOF: (I'm deliberately avoiding option C, which is that you reviewed the whole thing, but if you did, wow)
[03:26] <RAOF> Went before the TB
[03:26] <infinity> Cool.
[03:26] <infinity> It looked like the right thing to do, IMO, but I sure as heck wasn't going to audit it.
[03:28] <infinity> RAOF: When 'rmadison di-utils' claims something vaguely plausible about being published on 5 arches in precise-proposed, go nuts with debian-installer.  Just didn't make sense to me to upload twice in a row.
[03:29]  * infinity thinks he might go find a cookie before the shops all close.
[03:30] <RAOF> Win
[04:00] <micahg> infinity: ^^ I think this is happy enough for proposed
[04:02] <slangasek> infinity: maya quiche?
[04:06] <infinity> RAOF: FWIW, the framebuffery netboot worked for me too.
[04:07] <slangasek> infinity: uploading to quantal-proposed?
[04:07] <slangasek> or is it already there?
[04:07] <infinity> slangasek: d-i is in quantal already.  I was referring to testing RAOF's issues with the previous version, though.
[04:08] <infinity> (Or rather, testing with the previous version, his issues were obviously with an older version)
[04:14] <slangasek> ok
[04:30] <infinity> slangasek: I you want to respin an omap4 server image, the new d-i should be ready for it.
[04:50] <infinity> RAOF: The di-utils SRU is published on all arches -- do with that information what you will. :)
[04:50] <RAOF> infinity: This is an ack on your debian-installer upload. I see armel and ppc are being slowpokes; if you notice that they've finished before me, go for it.
[04:50] <RAOF> Hah! Overlap :)
[04:50] <infinity> :P
[04:51] <infinity> So, yeah.  All done now on ftpmaster, which is all that matters to the buildds.
[04:51] <RAOF> rmadison is late, but I'll go ahead and accept.
[04:51] <infinity> rmadison is from a mirror of a mirror, it's always laggy.
[04:53] <infinity> Danke.
[05:34] <slangasek> infinity: ack, respinning - thanks
[05:39] <slangasek> hmm, crontab and pad don't seem to have been updated for the drop of preinstall images
[08:45] <ogra_> oh, we have a new arch ? :P
[08:45] <ogra_> Wed Jul 25 06:11:40 UTC 2012
[08:45] <ogra_> No live filesystem source known for armhf-omap4
[08:54]  * xnox head desk
[08:54] <xnox> who rejected e2fsprogs? infinity ?
[08:54] <ogra_> if i only could find out where that comes from
[08:55] <infinity> xnox: I did, yes.  We can chat about it tomorrow. :)
[08:55] <xnox> infinity: ok. =)
[08:55] <xnox> infinity: good night (?!)
[08:55]  * infinity nods.
[08:55] <infinity> Night indeed.
[08:55]  * xnox is not too sure. oh ok.
[08:55] <ogra_> infinity, any idea ? the nusakan copy pastes also all have armhf-omap4
[08:56] <ogra_> (on the pad)
[08:57] <infinity> I don't see it in any commandlines on the pad...
[08:58] <ogra_> it looks a bit like a cron entry that ran ... (teh mail also has no (built by ...)
[08:58] <ogra_> infinity, at the bottom of the pad
[08:58] <infinity> The copy and paste for output is correct, it just does project-arch-subarch
[08:59] <infinity> But I'm guessing someone accidentally did a run with ARCHES=armhf-omap4 and sent you your mail, that's all.
[08:59] <ogra_> then i dont get where that failed build comes from
[08:59] <infinity> Probably from vorlon re-running the server image earlier tonight.
[08:59] <ogra_> since SUDO_USER doesnt seem to be set ...
[08:59] <ogra_> which it should from a manual run
[08:59] <ogra_> (and which would trigger the mail subject to be different)
[09:00] <infinity> cdimage@nusakan:~$ echo $SUDO_USER
[09:00] <infinity> cdimage@nusakan:~$
[09:00] <infinity> It's not always set, depends on how you sudo.
[09:00] <ogra_> oh, indeed
[09:00] <ogra_> i'm indeed assuming we all use the same method :P
[09:00] <infinity> Old habits die hard.
[09:01] <ogra_> heh
[09:01] <ogra_> well, sleep well then ...
[09:01] <infinity> I still use "sudo su - user" because that was sane before "sudo -u user -i" existed.
[09:01] <infinity> It's muscle memory for old people. :P
[09:01] <ogra_> yep, i know what you mean
[09:02] <infinity> Arguably, we could/should patch shadow (or pam_env, whichever is killing it) to preserve SUDO_USER.
[09:02] <infinity> But I dunno.
[09:02] <ogra_> but if i get that right there was a server build supposed to happen after d-i was published, right ?
[09:02] <infinity> That could have weird knock-on effects I'm not thinking about.
[09:02] <infinity> ogra_: Right.  slangasek kicked it off.
[09:02] <infinity> ogra_: If that never finished, that was probably the email you got. :P
[09:02] <ogra_> the last server image is from yesterday 21:xx UTC
[09:03] <ogra_> right
[09:03] <infinity> Yeah, so feel free to spin another.
[09:03]  * ogra_ will try
[09:03] <infinity> It should fix the no keyboard issue, but I'd like confirmation.
[09:03] <infinity> Also, netboots all work great now, thanks for fixing that.
[09:04] <infinity> (Well, you and TheMuso, his fix was somewhat critical)
[09:04] <ogra_> how do they work great ? they are still unbootable after install
[09:04] <infinity> Are not.  Try one.
[09:04] <infinity> I just did both -serial and -fb last night, both rebooted fine.
[09:05] <ogra_> ?? f-k cant find /dev/mmcblk1p1 (since there is no partition)
[09:05] <ogra_> or mmcbk0p1 or so
[09:05] <infinity> There is on the cards I just wrote.
[09:05]  * ogra_ doesnt see how that would be fixed 
[09:06] <infinity> I'm not sure how netboot was doing anything with f-k at all before TheMuso's upload.
[09:06] <ogra_> it uses f-k-i udeb
[09:06] <infinity> (The answer being that it couldn't have been)
[09:06] <infinity> Yeah, but the udeb wasn't marked for that subarch. :P
[09:07] <ogra_> the images i tested yesterday definitely had lukes fix
[09:07] <ogra_> and failed miserably in f-k-i
[09:07] <infinity> Very weird.  Cause yeah, I just did both the omap4 images yesterday, and they were happy.
[09:07] <ogra_> so i really dont get how it can have worked for you
[09:07] <ogra_> f-k hardcodes /dev/mmcblk0p1
[09:07] <infinity> Maybe I'm magic.
[09:07] <ogra_> heh
[09:08] <ogra_> did you partition the mmc using partman during install ?
[09:08] <infinity> No, not unless it did so behind the scenes.
[09:08] <infinity> I only partitioned my install media.
[09:08] <ogra_> it doesnt usually
[09:08] <infinity> Err, my target media.
[09:08] <ogra_> weird
[09:09] <ogra_> well, i'll do a new test later, but i dont see how a working install can be possible
[09:10] <infinity> http://paste.ubuntu.com/1109757/
[09:10] <infinity> ^-- Looks partitiony to me.
[09:10] <ogra_> yeah
[09:10] <infinity> I'm not really sure why it was having a sad for you.
[09:10] <ogra_> where would these come from ?
[09:11]  * ogra_ doesnt get it ... i dont think we have any code for this
[09:11] <infinity> I dunno, but they must have always been there.  flash-kernel 2.0 didn't magically partition cards either, it had the same hardcoded logic.
[09:11] <ogra_> they definitely werent there yesterday
[09:12] <ogra_> and the last two weeks ... LethoThe2nd reported it to me on IRC monday last week and i'm 100% sure no d-i build had them until yesterday
[09:12] <infinity> boot/arm/generate-partitioned-filesystem
[09:13] <infinity> ^--- From the d-i netboot bits.
[09:13]  * ogra_ scratches head
[09:13] <infinity> Which does basically the same thing as debian-cd.
[09:13] <infinity> Cargo-culted code, even.
[09:13] <infinity> So, I'm puzzled as to what error was being seen. :/
[09:14] <infinity> Oh.  Unless it has the same off-by-one error that I fixed in debian-cd last year.
[09:14] <ogra_> err, wait, i tested omap
[09:14] <infinity> Which would come and go as the initrd/kernel grows and shrinks.
[09:14]  * ogra_ wonders if tehre is any difference
[09:14] <infinity> omap and omap4 use the same code here.
[09:14] <infinity> But the off-by-one thing is entirely possible.
[09:15] <infinity> I can look at that in the morning.
[09:15] <infinity> Or you can dig through debian-cd logs and find the fix and compare.
[09:15] <infinity> Whichever.
[09:15] <ogra_> yep, will do, i only do testing today anyway (and some paperwork)
[09:18] <infinity> ogra_: bzr diff -r1722..1723
[09:19] <ogra_> where, in d-i ?
[09:19] <infinity> ogra_: In debian-cd.
[09:19] <infinity> ogra_: Though that may not apply to d-i.  There's already a spare 512 there that wasn't in debian-cd.
[09:19] <infinity> So, I could be barking up the wrong tree.
[09:19] <ogra_> yeah, d-i doesnt use that
[09:19] <infinity> Maybe you should just re-test omap3 and see if it's still borked, and we'll debug from there. :P
[09:20] <infinity> (Or, if you can find an image that's broken)
[09:20] <ogra_> all d-i build logs of the last four builds show that the partitioning code is run
[09:20] <infinity> ogra_: Yeah, the code is obviously being run, the question is if it's broken subtly.
[09:20] <infinity> ogra_: Hence my guessing at the off-by-one thing.
[09:20] <infinity> ogra_: Since the debian-cd partitioning bits and the d-i ones are very similar in history.
[09:21] <ogra_> thats a weird diff btw
[09:21] <ogra_>  modified file 'tools/boot/oneiric/post-boot-armel+mx5'
[09:21] <infinity> You're welcome. ;)
[09:21] <ogra_> heh
[09:22] <infinity> I probably should have named it "MBR" instead of "LEAD_IN", but there were enough confusing variables already, adding to them was fun.
[09:22] <ogra_> i mean that bzr shows the first half of the patch for one link name and the second one for the actual file
[09:22] <infinity> ogra_: Huh?  Those are two files.
[09:22] <infinity> ogra_: Or, they were back then, if they're not now.
[09:22] <ogra_> ah, k
[09:23] <infinity> Same fix, applied twice, to two slightly different bits of code.
[09:23] <ogra_> well, oneric, old stuff ...
[09:23] <infinity> Only the omap one is relevant, I imagine.
[09:23] <ogra_> yep
[09:24] <infinity> But, like I said, there's a spare 512+ in d-i already anyway, so this could be a red herring.
[09:24] <infinity> I'd like to find an image that breaks for you, and try to reproduce.
[09:24] <ogra_> well, all images i tested didnt have any partition after dd'ing
[09:25] <ogra_> i usually re-plug the SD before i move it to the board
[09:25] <infinity> Even after pulling and re-inserting the card.
[09:25] <ogra_> yeah
[09:25] <infinity> Many/most card readers won't re-scan partitions.
[09:25] <infinity> Kay.
[09:25] <infinity> They need a media change event, which some readers also don't do properly.
[09:26] <infinity> ogra_: But if, say, 20101020ubuntu161 was broken for you, let me know, and I'll dig into the WTF of it all.
[09:26] <ogra_> http://paste.ubuntu.com/1109783/
[09:26] <infinity> ogra_: If not, then we could have a harder time finding older ones.  Unless you have one sitting around.
[09:27] <ogra_> i still have them around, but i downloaded from the /current link (still have the tab open) ... timestamp on the page is jul 24th 07:03
[09:28] <ogra_> -rw-rw-r-- 1 ogra ogra  31457280 Jul 19 15:34 boot.img-fat-fb
[09:28] <ogra_> -rw-rw-r-- 1 ogra ogra  31457280 Jul 19 15:34 boot.img-fat-fb.1
[09:28] <ogra_> -rw-rw-r-- 1 ogra ogra  31457280 Jul 24 09:03 boot.img-fat-serial
[09:28] <infinity> Oh, wait.
[09:28] <infinity> That's the fat.
[09:28] <infinity> That's not an image.
[09:28] <ogra_> all of them are omap though
[09:29] <ogra_> oh SH*T !!!
[09:29] <ogra_> indeed you are right
[09:29] <ogra_> hooray for informative naming
[09:29]  * ogra_ goes to stand in the corner for a while
[09:29] <infinity> Well, it does say "fat".  As in, "hi, I'm a filesystem". ;)
[09:29] <ogra_> yes
[09:30] <ogra_> well, we can then release it, great, saves me one release note to write :)
[09:30] <infinity> *grin*
[09:31] <ogra_> and while making a fool out of me nusakan has finished the server images
[09:31] <ogra_> great
[09:31] <infinity> So I saw.
[09:31] <infinity> So you can test those and see if you get a USB keyboard.
[09:31] <infinity> And I'll sleep, honest.
[09:31] <ogra_> will do
[09:31] <ogra_> great, sleep tight
[09:31] <infinity> If it's still buggered, reopen the bug and yell at me.
[09:31] <infinity> Or fix it. :P
[09:31] <ogra_> i'll do the latter :)
[09:32] <infinity> (But I'd like to know either way)
[09:32]  * ogra_ goes getting some coffee
[09:32]  * infinity goes to have a bedtime smoke.
[09:39] <xnox> infinity: i hope you have a smoke alarm in your bedroom
[09:53] <ogra_> better than in his bedtime at least :P
[10:00] <ogra_> k, so omap netboot is definitely a no-go ... seems the NIC driver is missing
[10:10] <ogra_> weird, omap4 as well
[10:11] <ogra_> hmm, in fact there are no USB devices at all
[10:11]  * ogra_ is confused
[10:14]  * ogra_ tries the framebuffer image instead
[10:20] <ogra_> aha, that works
[10:34] <infinity> ogra_: Hrm, I didn't remove any drivers, just added some...
[10:35] <ogra_> yeah, it seems to randomly not work
[10:35] <ogra_> i had two boots of the serial image where no usb disk was found, three where it was
[10:35] <ogra_> smells like a udev race
[10:36] <ogra_> i have a framebuffer install working atm, lets see if it gets completely through, then i'll dig more into the usb bits
[10:36] <infinity> It could be the vm.min_free_kbytes thing.
[10:36] <ogra_> though testing the normal server image first is probably more important
[10:36] <infinity> Though, I can't see that being an issue on boot, we haven't eaten the RAM yet.
[10:36] <ogra_> yep
[10:36] <ogra_> also see my last comment on that bug ...
[10:37] <ogra_> i would actually like to try that suggested kernel fix from marvin24
[10:37] <ogra_> instead of having the hack in userspace again
[10:39] <infinity> If it works, sure.
[10:39] <infinity> It's not the easiest thing to test, mind you.
[10:39] <ogra_> why ? if i can get a patched kernel ...
[10:40] <infinity> I mean it's not the easiest thing to reliably reproduce to the point where one can be sure it's fixed.
[10:41] <ogra_> running apachebench seems to trigger it reliably
[10:41] <infinity> But we'll let the kernel team comment on it.  I'll bring it up with them.
[10:41] <ogra_> i pinged paolo about it already, lets see what he says
[10:41] <infinity> In theory, the easiest test is just "do something to consume all the RAM", "do heavy reads from USB disk" and "do heavy network I/O".
[10:41] <infinity> But it's still not what I'd call "reliable".
[10:41] <ogra_> sigh, base-install seems to take ages here
[10:42] <infinity> I was installing to a USB key last night, it wasn't that awful.
[10:43]  * ogra_ does the same here 
[10:43] <infinity> Certainly nicer when netbooting, but the SD copy isn't world-endingly bad.
[10:43] <ogra_> and the stick usually gets me 24-25M/s
[10:43] <ogra_> definitely the fastest one i have
[10:43] <ogra_> this *is* netboot
[10:43] <ogra_> the framebuffer one
[10:44] <ogra_> and its not the download that was slow ... configuring the packages seems to take aeons
[10:44] <infinity> Ahh, well, netboot is still faster than the SD image.
[10:44] <infinity> Though, the SD copy isn't actually that bad.
[10:44] <ogra_> yeah, the new server is pretty fast
[10:45] <ogra_> though as you guessed, i only tested serial yesterday
[10:45] <infinity> It should be blindingly fast on x86.
[10:45] <infinity> On ARM, we trade off that live-install is faster than base-install with the fact that SD cards suck. :P
[10:45] <ogra_> and havent had a chance to test my f-k fixes in production yet
[10:46] <infinity> There still must be a way to do the x86ish auto-detect of fb versus serial.
[10:47] <ogra_> i guess thats a matter of a sane framebuffer driver
[10:47] <infinity> Maybe.  I've never looked to see what x86 is doing.
[10:47] <infinity> Well, fsvo "sane".
[10:47] <infinity> It fails when hooked up to a KVM, so most "real server admins" force the command line anyway.
[10:47] <infinity> But it's certainly a nice hack for image testing.
[10:48] <ogra_> well, likely one that doesnt create a framebuffer device if no monitor is attached instead of having some hardcoded thing
[10:48] <infinity> Plug in keyboard/monitor, get framebuffer, unplug, get serial.
[10:49] <apw> infinity, i note that linux-lowlatency binaries are in universe, i am supprised that works for the image builds?
[10:49] <infinity> omapdrm might be the sanity we're looking for, but I don't think we get a remotely sane version of that until Paolo moves to 3.5, or maybe even 3.6
[10:50] <infinity> apw: It's for an image that builds from universe, so it works fine.
[10:50] <ogra_> apw, kernels in main are only needed for images that are involved with d-i
[10:50] <infinity> apw: Pretty much all of ubuntustudio is in universe.
[10:50]  * apw adds that to his mental model, tha
[10:51] <infinity> Well, ubuntustudio does have alternates, that do involve d-i.  And we cheat and put the generic kernel on their alternates (ie: we use the ubuntu cdrom bits). :/
[10:51] <infinity> (And then we install lowlatency during the install)
[10:51] <infinity> It's hackish.
[10:52] <apw> infinity, hackish :) indeed
[10:52] <ogra_> cute
[10:53] <infinity> Anyhow, I seem to be failing at sleeping again, and we have a family^Wteam meeting in 3.5 hours.  Hrm.
[10:53] <infinity> I should try again to nap.
[10:53] <ogra_> go for it, good luck !
[10:54] <infinity> apw: Care to throw a seasoned kernel dude opinion at https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/746137/comments/16 ?
[10:54] <ubot2> Ubuntu bug 746137 in jasper-initramfs "Page allocation failure on Pandaboard and Beagle XM" [Undecided,Fix released]
[10:54] <ogra_> infinity, ppsati is on it too
[10:54] <ogra_> apw, ^^^
[10:54] <infinity> ogra_: Yeah, I know, I just wanted a gut feeling from Andy.
[10:55] <ogra_> (but additional opinions surely dont do harm :) )
[10:55] <infinity> (Besides, we want it in master too, not just ti-omap4)
[10:55] <ogra_> right, though i think omap4 is the place to test it
[10:55] <ogra_> less intrusive
[10:55] <infinity> omap4 test kernels are a good place to test it, but ultimately, committing to master and rebasing feels saner.
[10:55] <ogra_> ++
[10:55] <infinity> It's the same driver, same level of intrusive. :P
[10:56] <ogra_> it is surely a lot easier to reproduce oin the beagle
[10:56] <ogra_> though i guess booting a panda with mem=512M should do the same
[10:56] <infinity> Or 256, if it's my Beagle. :(
[10:56] <ogra_> or that
[10:56] <infinity> I should put the thing out of its misery.
[10:56]  * ogra_ uses his 256M beagles as printserver and router :)
[10:56] <infinity> And beg someone to ship me an xM.
[10:57] <infinity> I'd rather use mine as a frisbee.
[10:57] <apw> infinity, surley you can just order one
[10:57] <infinity> apw: I could, but we have a ton in London that aren't being used.
[10:57] <infinity> apw: Since we decommissioned them as buildds.
[10:57]  * ogra_ wants one that isnt revA 
[10:57] <apw> infinity, and just how much would it cost to send one from the UK to you, i suspect more than they are worth
[10:57] <infinity> And 20 bucks shipping seems saner than 150 for a new board.
[10:57] <ogra_> yeah
[10:58] <apw> heh, $20 shipping, from here to there, yeah right
[10:58] <infinity> It doesn't have to be overnight. :P
[10:58] <ogra_> someone should just bring them to UDS and give them out to the teams
[10:58] <infinity> The good ol' postal service will do it for that, or less.
[10:58] <ogra_> no costs at all :)
[10:59] <infinity> We spoiled brats and our FedEx and DHL need to occasionally remember that regular mail actually works just fine. :P
[10:59] <ogra_> haha
[11:01] <apw> ogra_, you say 'kernel fix above' but i am not seeing it (likely i am just missing it but)
[11:01] <infinity> apw: I linked to it. :P
[11:01] <ogra_> apw, comment 16
[11:01] <infinity> apw: It's a verbal patch, not a literal one.
[11:02] <ogra_> "replace GFP_ATOMIC by GFP_KERNEL in the relevant kmallocs which worked for the rt2x00 wifi driver in the ac100 armhf kernel"
[11:02] <ogra_> that driver had exactly the same prob
[11:02] <apw> hmmm they are probabally _ATOMIC so they can be performed out of the interrupt handlers handling incoming packets
[11:02]  * apw wonders what it is with us dropping every userspace package which ever configured the kernel, so that we have to configure every damn kernel 15 ways to make up for it
[11:03] <apw> the kernel has these interfaces for a reason, there is no sane default for many of these things
[11:03] <infinity> apw: In this case, the userspace hack is, well, an obvious hack.
[11:03] <apw> we only need the new hack because the old place went away
[11:03] <infinity> The old place?
[11:04] <ogra_> we dont have anything that puts the old hack in place atm
[11:04] <apw> which is my point.  keybuk was always removing things and saying hte kernel should do it right
[11:04] <ogra_> and it is and always was a hack
[11:04] <infinity> I don't mean that *how* we configure is a hack, I mean the configuration itself is a hack.
[11:04] <apw> jasper-initramfs went away
[11:04] <ogra_> right
[11:04] <infinity> IMO, if you have to configure vm.min_free_kbytes, something's gone wrong.
[11:04] <ogra_> because it was hacks and hacks only
[11:04] <apw> define a hack, the machine needs more reserve with that board, that actually might be right
[11:05] <ogra_> this probalem is widely known and not arm or panda specific at all
[11:05] <apw> infinity, by that definition the min_free_kbytes itself is a hack
[11:05] <ogra_> if you have to set min_free_kbytes *everywhere* why not use a sane default in the driver itself
[11:05] <apw> infinity, the kernel has to have a reserve and its size is a usecase/hw in the machine thing
[11:05] <infinity> apw: For a "normally-running system", it *is* a hack if you need it to function.  min_free_kbytes is more about performance tuning.
[11:05] <apw> ogra_, no this is only for one rtl device right?
[11:05] <ogra_> the kernel should know how much ram is available and be able to determine a proper value
[11:06] <ogra_> apw, smsc USB NIC
[11:06] <infinity> apw: But, meh.  If you claim it's machine-dependent, then the kernel should have sane defaults for that machine. ;)
[11:06] <apw> only if you have that device you need it.  now yes in your case all machines we care about have it
[11:06] <ogra_> and i know this driver has the same issues on x86
[11:06] <infinity> apw: But, okay, one could also make it a udev rule, if it's specific to that device.
[11:06] <infinity> apw: Which seems like a sane place for it.
[11:06] <apw> ogra_, indeed it is a terrible driver, rtl drivers always are
[11:07] <infinity> If the driver has issues on all platforms, a udev rule seems like the right answer.
[11:07] <apw> infinity, that might make some sense.  and indeed if the driver needs to be ATOMIC (and i'll let ppisati test that) then either udev or something in the kernel init for that driver makes more sense.
[11:07] <infinity> (or the driver not sucking)
[11:07]  * ogra_ thinks a fix of the driver seems like a better answer :)
[11:08] <apw> though for me removing the driver appeals too
[11:08] <ogra_> LOL
[11:08] <infinity> apw: Removing the driver is a bit of a non-starter when it's the NIC soldered to every Panda. :P
[11:08] <ogra_> tell that to the teams doing netinstall tests on pandaboards :)
[11:08] <apw> those boards all should just be put in the crusher and put out of my misery, for a start because they have any RTL kit on them
[11:08] <ogra_> though we have a wlan card on it as well :)
[11:09] <ogra_> apw, you could donate half of your salary to TI every month so they can buy more expensive NICs :)
[11:10] <ogra_> if its really causing so much misery for you that seems like a cheap solution :P
[11:10] <infinity> apw: smsc95xx is rtl, or are you confusing the two buggy drivers?
[11:10] <infinity> s/is/isn't/
[11:11]  * ogra_ yawns watching pkgsel progressing slowly
[11:11] <apw> but it sounds like a sane plan to try the _ATOMIC change and see
[11:11] <ogra_> ++
[11:12] <infinity> apw: To try to s/ATOMIC/KERNEL/ that is.
[11:12] <infinity> http://lists.metaprl.org/pipermail/cs134-labs/2002-October/000025.html
[11:12] <apw> indeed
[11:12] <infinity> ^-- That seems to imply that _KERNEL "tries harder".
[11:12] <infinity> I'm all for things trying harder. :P
[11:13] <apw> infinity, indeed _KERNEL can sleep waiting for memory to be reaped, i suspect though we cannot wait its common to be in interrupt handler pulling packets out of the receieve ring like mad
[11:16] <infinity> apw: On a slow NIC (they're 100bT over USB2, after all), I'm not sure if the practical issue of ring flooding is nearly as bad as the theoretical.
[11:17] <apw> i assume we are dropping large packets here given 'turbo' has to be enable to trigger it
[11:17] <apw> and i asusme that leads us to allocate like 16 or 32k pages not normal easily available ones
[11:18] <infinity> Well, disabling turbo "makes it go away", but I'm not sure that's actually true, or if it just makes it "vanishingly less likely to happen because you're suddenly shuffling less data".
[11:19] <ogra_> ppisati, haha, ++ to your last comment on bug 10268780 ("bad design decision")
[11:20]  * infinity reads more about what's illegal under spin_lock_irqsave(), and wonders how much one would have to trace back through smsc95xx and usbnet to decide if we're violating that.
[11:20] <ogra_> err bug 1026780 that was
[11:20] <ubot2> Launchpad bug 1026780 in flash-kernel "3.0~rc.4ubuntu4 doesn't honor bootargs from /boot/boot.script anymore" [High,New] https://launchpad.net/bugs/1026780
[11:21] <infinity> apw: I think this is mostly just teaching me the valuable lesson that having your storage and NIC on USB is dumb.
[11:21] <ogra_> well, USB 3.0 will fix that in the long term
[11:22] <infinity> ogra_: Wait, what?  f-k 3.0 is hardcoding root=?
[11:22] <infinity> ogra_: That means f-k 3.0 initramfses aren't generic.  That's completely wrong.
[11:22] <ogra_> it reads fstab and dumps a config snippet into the initrd
[11:23] <ogra_> unless you tell it not to
[11:23] <infinity> ogra_: Do we tell it not to?
[11:23] <ogra_> in which case you would need to add root= tro a package shipped source file that gets overwritten on package upgrades
[11:23] <ogra_> so no, we dont atm
[11:23] <infinity> Right, well, I've heard we can write to /boot and /etc
[11:24] <infinity> Like every other bootloader config.
[11:24] <ogra_> i want an /etc/flash-kernel/ bootscript.d
[11:24] <ogra_> that overrides the hardcoded crap
[11:24] <infinity> Personally, whoever does the work, I think that crazy needs fixing.
[11:24] <ogra_> but that will have to wait until i'm back from the QA sprint
[11:24] <infinity> And it needs fixing in Debian before squeeze too.  I wasn't aware of this misfeature. :/
[11:24] <ogra_> and additionally we need some migration love
[11:25] <infinity> I've already had long and angry arguments with people who wanted to hardcode fstab bits in initrds to support mounting /usr
[11:25] <ogra_> well, loic seems to think its sane
[11:25] <infinity> Don't really want to have the argument all over.
[11:25] <infinity> Loic's wrong. :P
[11:25] <ogra_> and having override capabilities is a nice to have
[11:25] <infinity> And I'll be happy to tell him.
[11:25] <ogra_> yeah
[11:25] <infinity> Distro-generated initrds NEED to be generic.
[11:25] <ogra_> i told him :)
[11:25] <ogra_> yeah, thats not the prob
[11:26] <ogra_> ust a simple switch in the db file ...
[11:26] <infinity> That's the obvious problem I see with hardcoding root=. :P
[11:26] <ogra_> the prob is to make it accept modified input files the package doesnt overwrite
[11:26] <infinity> You mean, like... Conffiles?
[11:26] <ogra_> switching off the hardcoding is there, using the alternative isnt
[11:26] <infinity> It's kinda like Debian 101.
[11:27]  * infinity shakes his head.
[11:27] <ogra_> do conffiles not have to live in /etc ?
[11:27] <infinity> Remind me of this bug when you're sprinting, so I can get angry about it again.
[11:27] <ogra_> i think it was explicit that they are in /usr/share
[11:27] <Laney> micahg: I'm not sure your xubuntu blacklisting had the effect you wanted
[11:27] <Laney> https://bugs.launchpad.net/ubuntu/+source/xubuntu-meta/+bug/1016925/comments/7
[11:27] <ubot2> Ubuntu bug 1016925 in xubuntu-meta "12.10 Alternate installer fails with libavformat53 unmet dependencies" [High,Fix released]
[11:27] <ogra_> so dpkg doesnt make tehm conffiles
[11:27] <ogra_> (which doesnt save you from overwriting on package upgrade')
[11:28] <infinity> ogra_: You can mark anything a conffile, but no, people shouldn't be editing stuff in /usr/share.
[11:28] <infinity> ogra_: But having both defaults and overrides isn't rocket science.  Look at initramfs-tools.
[11:28] <ogra_> well, thats the input source :)
[11:28] <ogra_> oh, indeed
[11:28] <ogra_> it wont take more than 1h to implement and even fully test but i need to find that spare hour :)
[11:29] <ogra_> (and a board that isnt occupied by install tests)
[11:29] <infinity> Like I said, remind me when you're sprinting, and I'll fix it in anger, and give Loic about 30 seconds to agree it's awesome before I NMU it.
[11:29] <ogra_> LOL !
[11:29] <ogra_> will do, probably i have time during the sprint but i doubt that
[11:30] <ogra_> and as long as it is fixed in final thats sufficient
[11:30] <infinity> Yeah, but I don't want squeeze shipping this way either.
[11:30] <ogra_> ++
[11:30] <infinity> And as the freeze plods on, exceptions get harder to get approved.
[11:30] <ogra_> if you actually NMU you could pull armadaxp and highbank in as well, i doubt NCommander forwarded anything of this
[11:31] <ogra_> saves us carrying a patch
[11:31] <infinity> I can sync it mostly wholesale, though they don't ship kernels for either one.
[11:31] <ogra_> (theoretically 80% of the changes since the sync should be pushed into debian in fact)
[11:31] <infinity> But I guess if f-k supports it, then people could install Ubuntu kernels and it would "just work".  Well, if our kernels didn't depend on packages that aren't in Debian...
[11:31] <infinity> Friggin' crda crap.
[11:32] <ogra_> yeah
[11:32] <ogra_> f-k 3.0 doesnt have any package check anymore
[11:32] <ogra_> nor subarch
[11:32] <ogra_> if you just have /lib/modules and /boot/vmlinuz-$version it will work
[11:33] <ogra_> it is a lot easier on all the checks
[11:33] <infinity> Anyhow.  NMUing probably won't be necessary.  I don't think Loic actually WANTS to own f-k anymore, he's just stuck with it cause no one else wants it.
[11:34] <infinity> So, I'm sure adding myself to uploaders and accidentally co-maintaining it will not upset him in the least.
[11:34] <infinity> I'll ask, though. :P
[11:34]  * ogra_ would take it but fears the responsibilty and misses DD upload privs
[11:34] <infinity> And file nasty RC bugs and NMU if he says no.
[11:35] <ogra_> (fearing the responsibility simply because it supports so much HW i cant even remotely test)
[11:35] <ogra_> oh finally !
[11:35] <ogra_> netinst rebooting ...
[11:36] <ogra_> so that was framebuffer netinst omap4 with working kbd ...
[11:36] <ogra_> next i'll check server
[11:37] <ogra_> tsk, the ubuntu on the plymouth text theme splash looks so lost on 1920x1080
[11:37] <ogra_> ok, all working even after reboot
[11:39] <infinity> ogra_: It was only server that was broken, netboot was fine.
[11:39] <ogra_> ah, k
[11:39] <ogra_> dd is running ... we'll see
[11:40] <infinity> Somewhere in the anals of time when omap moved to omap4, someone missed symlinking some bits, which we never cared about, cause we never used the d-i "cdrom" images until now. :P
[11:41] <infinity> Annals, even.  Though, looking at some of the ARM enablement messes that have been made, anals seems appropriate.
[11:44] <ogra_> infinity, i has keyboard on server framebuffer
[11:45] <infinity> ogra_: Eggsellent.
[11:45] <ogra_> :)
[11:46] <ogra_> hmm, but it doesnt seem to move after kbd selection
[11:47]  * ogra_ sits in front of an empty violet screen, hoping its just slow
[11:47] <ogra_> hmm, seems to be cdrom-detect
[11:49] <ogra_> it lists sda1, sda2, mmcblk0p1 and mmcblk0p2 as possible source devices ... but it only probes for installation media on sda*
[11:50] <infinity> Really?  It all Just Worked for me before.
[11:50] <infinity> I can't see how adding HID drivers would have broken it...
[11:51]  * infinity zsyncs a new image.
[11:52] <ogra_> yeah, i doubt thats related to HID
[11:53]  * ogra_ reboots 
[11:55] <ogra_> "mount: sending ioctl 5310 to a partition!"
[11:55] <ogra_> thats all i see
[11:55] <infinity> That's perfectly normal.
[11:55] <ogra_> and i was wrong, i also have sda3 4 and 5
[11:55] <ogra_> it seems to stop after sda2
[11:55] <ogra_> which i think is the partition with the former install
[11:56] <ogra_> aha, and the processlist shows a mount -t iso9660 /dev/sda3 /cdrom
[11:56] <ogra_> whcih doesnt seem to proceed
[11:57] <infinity> Is there something wonky on your USB key?
[11:57] <ogra_> i just did a netinst ...
[11:57] <infinity> Well, specifically /dev/sda3
[11:57] <ogra_> cant imagine that something is wonky with that, it booted and worked fine
[11:57] <ogra_> thats likely a virtual partition holding sda5
[11:58] <ogra_> hmpfs and indeed i cant kill the mount
[11:58]  * ogra_ zreoes the mbr and starts over
[12:00]  * infinity sloooowly writes a test image out to SD.
[12:00] <ogra_> aha, now it works
[12:00] <ogra_> looks like cdrom-detect has a bug
[12:00] <ogra_> needs to check partition type or so
[12:00] <infinity> Or your partition tables were just that messed up and weird somehow.
[12:01] <infinity> But then mount has a bug for hanging. :P
[12:01] <ogra_> well, d-i created it in the former install
[12:01] <infinity> (Well, it does anyway, clearly)
[12:02] <ogra_> i just picked guided partitioning, nothing fancy
[12:02] <ogra_> oh, wait
[12:02] <ogra_> iirc we create an ext2 /boot partition (for whatever reason) ...
[12:03] <ogra_> might be that we dont have ext2 support or so
[12:03] <infinity> We do.
[12:03] <ogra_> not in my cat /proc/filesystems here
[12:03] <ogra_> oh, wait
[12:04] <ogra_> its there, just not listed near the other ext* ones
[12:04] <ogra_> k, so its not that, sad, that would have been easy
[12:05] <infinity> Well, it's reproducible. :/
[12:05] <infinity> I also have a default install on my USB key, and have a hanging mount -t iso9660
[12:05] <ogra_> ah, see, loic answered on the bug :)
[12:05] <ogra_> i *think* we can preseed the filesystem type for cdrom-detect
[12:06] <ogra_> would be an easy workaround if its the iso9660 bit thats broken
[12:06]  * ogra_ crosses fingers that his flash-kernel fix works
[12:06] <infinity> Yeah, but what the heck is it doing? :/
[12:07] <ogra_> well, what kind of partition is sda3 ?
[12:07] <ogra_> hardcoding root= in initrd is good because it is consistently broken according to his comment :P
[12:08] <infinity> Yeah, I read his comment.
[12:08] <infinity> We'll still want to fix it. :P
[12:08] <infinity> Anyhow.
[12:08] <infinity> sda3 is the Extended container, as you guessed.
[12:08] <infinity> But you'd think this same thing would happen on x86.
[12:08]  * ogra_ cries 
[12:08] <micahg> laney: no, it didn't and I'm not sure why
[12:08] <infinity> Unless mount is fundamentally broken on ARM.
[12:08] <ogra_> f-k failed it seems
[12:08] <infinity> ogra_: What did it fail to do?
[12:09] <infinity> ogra_: It worked for me last night, and it hasn't changed since, has it?
[12:09] <Laney> micahg: Is that kind of blacklisting supposed to work?
[12:09] <ogra_> did you test server or netinst ?
[12:09] <infinity> server
[12:09] <infinity> Well, both.
[12:09] <ogra_> live-installer calls update-initramfs before f-k is configured shich makes the world explode
[12:09] <infinity> But I did server serial once through.  I think.
[12:09] <ogra_> *which
[12:10] <micahg> laney: that's how I understood blacklisting, but I could be wrong
[12:10] <ogra_> i added a live-installer script that diverts u-m until f-k-i runs
[12:10] <infinity> Maybe I didn't finish server.
[12:10]  * micahg checks the docs
[12:11] <ogra_> hmm, and that script isnt there #
[12:12] <infinity> ogra_: I like how your last upload was just a changelog. :P
[12:12] <ogra_> err, huh ?
[12:12] <infinity> http://launchpadlibrarian.net/111061999/flash-kernel_3.0~rc.4ubuntu10_3.0~rc.4ubuntu11.diff.gz
[12:13] <infinity> Oh, diff doesn't show mode changes, if that was all it was.
[12:13] <ogra_> sigh !
[12:13] <ogra_> well, still, you are right it seems
[12:13] <infinity> Still counting on +x to persist on unpack is still sketchy, you should do that in debian/rules when you install the file.
[12:14] <Laney> micahg: I see this in the manpage: "It is not intended for the purpose of working around buggy pack‐ age relationships, and attempts to do so will not work because apt has no way to know about blacklist entries in seeds.
[12:14] <Laney> "
[12:15] <ogra_> infinity, well, flash-kernel isnt installed in the environment so the file isnt there
[12:15] <Laney> that is about "!" entries though, not about the blacklist file
[12:15] <micahg> laney: ah, it's just for the -meta...
[12:16] <infinity> ogra_: Did you mean to have it in f-k-i, not f-k?
[12:16] <ogra_> the prob is that i cant install it manually either
[12:16] <ogra_> the broken update-initramfs kept the handle on apt-install
[12:16] <ogra_> so apt-install refuses to do anything
[12:16] <micahg> it's too bad that the ubuntu-sso-client-gtk drop was only half completed...
[12:17] <infinity> ogra_: Oh, it is in f-k-i.
[12:17] <ogra_> yeah
[12:17] <infinity> But yeah, f-k-i is only installed on-demand.
[12:17] <Laney> this is fallout from that?
[12:17] <infinity> All bootloader installers are.
[12:17] <ogra_> right and only at the end
[12:17] <infinity> Exactly.
[12:18] <ogra_> i doubt colin would be happy with me putting the file into live-installer itself though
[12:18] <infinity> ogra_: What are you actually trying to do here?
[12:18] <infinity> ogra_: Just avoid f-k running before it's configured?
[12:18] <ogra_> so i guess i need a f-k-prereq udeb that is always installed or some such
[12:18] <ogra_> i try to make update-initramfs a no-op
[12:19] <infinity> ogra_: Okay, but why?
[12:19] <ogra_> so it doesnt run before f-k is ready to handle it
[12:19] <ogra_> because f-k-i installs mkimage
[12:19] <infinity> ogra_: Ultimately, this isn't about initramfs-update, but about f-k, correct?
[12:19] <ogra_> and without mkimage in place update-initramfs fails
[12:19] <infinity> ogra_: As in, update-initramfs will trigger f-k, which fails?
[12:19] <ogra_> it is about ordering of the bits
[12:19] <ogra_> right
[12:20] <ogra_> f-k is already in 7target
[12:20] <ogra_>  /target
[12:20] <infinity> Kay, we used to work around that by having f-k exit 0 if it wasn't configured yet.
[12:20] <ogra_> but f-k-i sdidnt run and installed mkimage yet
[12:20] <infinity> Can we not just do the same thing we used to?
[12:21] <ogra_> we probably could by putting a flag in place or so but thats ugly
[12:21] <ogra_> in the past we checked for /etc/flash-kernel.cof
[12:21] <ogra_> *conf
[12:21] <ogra_> thats gone with 3.0 ... as any other runtime configuration is
[12:22] <infinity> Oh, right.  Thanks Loic. :/
[12:22] <infinity> So, what's there to "configure"?
[12:22] <infinity> You just mean that the deps aren't there.
[12:22] <ogra_> apt-install u-boot-tools
[12:22] <ogra_> or redboot-tools ... or $bootloader-tools
[12:22] <infinity> ogra_: Isn't the solution, then, to have u-boot-tools in the live image?
[12:22] <ogra_> seeding it ?
[12:23] <ogra_> we cant realyl do that subarch based
[12:23] <ogra_> which means you end up with u-boot-tools on every arm image
[12:23] <infinity> Erm.
[12:23] <infinity> It's a live image.
[12:23] <infinity> Made by livecd-rootfs, I assume.
[12:23] <infinity> Which knows about subarches.
[12:23] <ogra_> it is a d-i image
[12:23] <ogra_> using a squashfs
[12:23] <infinity> What creates it?
[12:24] <ogra_> instead of running debootstrap in base install
[12:24] <ogra_> live-build indeed
[12:24] <ogra_> but its essentially just debootstrap squashed up
[12:24] <ogra_> and i dont thinnk there is any removal of packages happening in the whole process
[12:24] <ogra_> yet
[12:24] <infinity> We don't want removal, we want addition.
[12:25] <ogra_> we want removal on subarches the dont use u-boot
[12:25] <ogra_> *that
[12:25] <infinity> No, we want to not add it. :P
[12:25] <ogra_> but yiu cant seed it on a per subarch base
[12:26] <ogra_> do you wnat to hardcode it in livecd-rootfs ?
[12:26] <infinity> Dude, we do this all the time.
[12:26] <ogra_> *want
[12:26] <infinity> Yes.
[12:26] <ogra_> ah, k
[12:26] <infinity> Your image already has other bits in it, I'm sure.
[12:26] <ogra_> that doesnt really sound like a proper solution, but it will make it work indeed
[12:26] <infinity> Actually, let me find a livefs log for this.
[12:27] <ogra_> since f-k is still broken
[12:27] <ogra_> in context with live-installer
[12:27] <ogra_> i think the diversion is the better way, but hard to implement without touching live-installer itself
[12:28] <infinity> It's only broken if the target doesn't have the right bits.
[12:28] <infinity> So, the target needs to have the right bits.
[12:28] <ogra_> right, but by design the right bits can only come in at the end
[12:28] <infinity> ...
[12:28] <ogra_> yes, which is why we have f-k-i
[12:28] <infinity> Or, they can be there the whole time.
[12:29] <ogra_> one way would be to split f-k-i into two parts
[12:29] <infinity> But okay, the other possible solution is to make live-installer divert things wholesale, and undivert before the final boot-method setup.
[12:29] <ogra_> having the one that runs the apt-install $bootloader_tools at the beginning and the actual end-configuration at the end
[12:29] <infinity> Which isn't entirely unreasonable.
[12:30] <infinity> ubiquity already does this.
[12:30] <ogra_> yep
[12:30] <ogra_> thats why colin suggested a diversion to me yesterday
[12:30] <infinity> Sure, but ubiquity does it for everyone, to avoid multiple update-initramfs calls.
[12:30] <ogra_> right
[12:30] <infinity> I don't see why that should belong to flash-kernel.
[12:31] <infinity> Assuming you can get the divert/undivert timing sane so it doesn't break anything.
[12:31] <ogra_> because it behaves different from other bootloaders due to supporting multiple subarches
[12:31] <ogra_> which means different tools packages
[12:31] <ogra_> unlike any other bootloader
[12:32] <ogra_> so technically it should ship the fix itself ... for the breakage it causes
[12:32] <infinity> Yes, but I'm saying the "fix" is also an optimisation.
[12:32] <ogra_> yes
[12:32] <infinity> If you don't think of it as having anything to do with flash-kernel. :P
[12:33] <ogra_> right, but f-k is the only thing being broken due to it
[12:34] <ogra_> anyway, for now lets "seed" it from live-build so we can get A3 out ... and discuss it with colin once he's back
[12:34] <ogra_> i dot want to hack up live-installer without him being around
[12:34] <infinity> Anyhow.
[12:34] <infinity> Yeah, right now, that subarch stuff in livecd-rootfs is still being respected for -server builds.
[12:35] <infinity> So, just adding u-boot-tools to the list for omap* would fix you up.
[12:35] <infinity> Which I'm doing right now.
[12:35] <ogra_> ah, k, i was doing the same :)
[12:35]  * ogra_ holds back
[12:35] <infinity> Also.. Is ti-omap4-ppa still a thing?
[12:35] <ogra_> and let me revert the f-k stuff at the same time since its useless
[12:36] <infinity> Didn't we kill that?
[12:36] <ogra_> we did
[12:36] <ogra_> remove it please
[12:36] <ogra_> i was planning a cleanup run after FF
[12:36] <ogra_> ricardo actually sounded yesterday as if he had a breakthrough with the PVR mess btw
[12:40] <ogra_> f-k uploaded
[12:40] <infinity> And livecd-rootfs.
[12:41] <infinity> ogra_: f-k was just a revert to ubuntu9?
[12:41] <ogra_> yes
[12:41] <infinity> Seems sane.
[12:42] <ogra_> where is queuebot btw
[12:42] <ogra_> stgraber, ^^^
[12:43] <infinity> They're not in the queue.
[12:43] <ogra_> (or does it currently only watch precise)
[12:43] <ogra_> no but there were other uploads
[12:43] <infinity> It only watches unapproved/new
[12:43] <infinity> quantal-* gets accepted, we're not frozen.
[12:44] <ogra_> ah
[12:44] <ogra_> i thought we are in a theoretical freeze :)
[12:44] <infinity> A soft freeze, yeah.  Not one with technology to back it up. :)
[12:44] <ogra_> k
[12:44] <infinity> Just social pressure.
[12:44] <infinity> And ridicule.
[12:45] <ogra_> heh
[12:45]  * ogra_ refrains from commenting :)
[12:46]  * ogra_ grumbles 
[12:47] <infinity> Hrm?
[12:47] <ogra_> so the pad tells me i need to reconnect and clicking the button gets me to a 404
[12:47] <ogra_> yay userfriendlyness
[12:47] <infinity> Oh, yeah.  It's special.
[12:47] <infinity> livecd-rootfs built.
[12:50] <infinity> And f-k built.
[12:50] <ogra_> great
[12:50] <ogra_> added info to the pad
[12:51] <infinity> Publisher doesn't look horribly upset about life, so you should be able to respin again in ~30m, if you feel the urge.
[12:51]  * ogra_ wonders how we can improve the netboot situation ... there must be a way to name the vfat stuff more descriptive so people dont fall into that trap
[12:52] <ogra_> intrestingly these files arent even in the MANIFEST
[12:52] <infinity> -fat-partition or something, maybe.  But it's been named the way it is for so long, I'd rather not break anyone who relies on the names in scripts.
[12:53] <ogra_> well, alternatively putting a  README in place (generated from the MANIFEST entries) might help
[12:53] <infinity> Or, people can learn, like you did. ;)
[12:54] <ogra_> learning ?!?
[12:54] <ogra_> sigh ... thats hard
[12:54] <infinity> Making the MANIFEST more descriptive would probably do it, though.
[12:54] <ogra_> it is very descriptive
[12:54] <infinity> Including adding some of the missing files.
[12:54] <ogra_> just doent have any entry for any of the fat files
[12:54] <ogra_> right
[12:55] <ogra_> so who drives the isotracker atm ?
[12:55] <ogra_> wouldbe good to re-enable netinst again so we can log results
[12:55] <infinity> You're in the right team to do that, aren't you?
[12:55] <infinity> Or maybe it's locked down to release now.
[12:56] <ogra_> oh, they are enabled
[12:56] <ogra_> i asked yesterday morning to drop them, seems that didnt happen, so nothing to revert :)
[12:56] <infinity> I don't see any...
[12:56] <ogra_> http://iso.qa.ubuntu.com/qatracker/milestones/226/builds
[12:56] <infinity> Because I only had "tested" clicked..
[12:57] <infinity> *sigh*
[12:57] <ogra_> heh
[12:57] <infinity> And yay, you have test results to log!
[12:57] <ogra_> we should lock stgraber and mpt into a room for 1h or so  next UDS
[12:58] <infinity> But I kinda like stgraber...
[12:58] <ogra_> LOL !
[12:58] <ogra_> yeah, might be a somewhat mean plan
[12:59]  * ogra_ isnt sure what to make out of the USB randomly not working bit from the netboot install
[12:59]  * infinity wonders why netboot i386 has a ubiquity bug attached to it.
[12:59] <ogra_> i cant even file a bug without at least having a log or something from when it shows up
[13:00] <infinity> I did two installs last night and didn't see that.  I guess we'll have to see how reproducible it is.
[13:00] <ogra_> right
[13:00]  * ogra_ sets his netboot test to passed for now 
[13:01] <stgraber> ...
[13:06] <ogra_> infinity, bug 1028905 in case you want to add something
[13:06] <ubot2> Launchpad bug 1028905 in cdrom-detect "cdrom-detect in quantal omap4 hangs trying to look for install media on an extended partition" [Undecided,New] https://launchpad.net/bugs/1028905
[13:08] <infinity> ogra_: Nope, but I'll me too it.
[13:13]  * ogra_ notices the time and thinnks abut breakfast
[13:20] <infinity> ogra_: Publisher's done, you can re-spin server if you want.
[13:22] <Daviey> ogra_: What is the state of arm server images?
[13:23] <infinity> Daviey: netboot is good, the fancy new d-i/live hybrid thingee needs a respin, but then should be good.
[13:24] <Daviey> infinity: thanks
[13:25] <Laney> micahg: so, can we revert your change and release note it?
[13:48] <ogra_> ubuntu arm server rebuild running
[13:53] <micahg> laney: revert which change?
[13:54] <Laney> the blacklist
[13:56]  * infinity sets an alarm for 34m from now and goes to lie down.
[13:59] <Laney> oh, hang on, it's not that is it
[13:59] <micahg> laney: ah, I think I should've used ! instead of the blacklist file for what I wanted...
[14:00] <Laney> want to consult someone who knows? We can then try again …
[14:01] <micahg> who's the backup seed expert?
[14:01] <ogra_> backup seed ?
[14:01]  * ogra_ wasnt aware we had such a thing
[14:01] <micahg> no, seed expert :)
[14:01] <ogra_> well, whats your issue ?
[14:02] <micahg> as in cjwatson isn't around :)
[14:02] <ogra_> everyone whjo ever uploaded -meta should also be able to at least roughly understand seeds :)
[14:02] <micahg> I need to stop ubuntu-sso-client-qt and gstreamer0.10-ffmpeg from being pulled into xubuntu
[14:02] <micahg> ogra_: I understand that part :)
[14:02] <micahg> I added them to the blacklist file, but germinate still pulls them in
[14:03] <ogra_> right, i think ! isnt so wrong :)
[14:03] <micahg> I'm thinking to add them to ! entries in the ship sseeds
[14:03] <ogra_> though why are they there in the first place ?
[14:03] <Laney> recommends of webkit
[14:03] <ogra_> any dep that pulls them in ?
[14:03] <ogra_> ah
[14:03] <micahg> ogra_: well, the gstreamer thing is fixed in -proposed, but won't get in in time
[14:03] <ogra_> i'm not sure you can override recommends of packages through seeds
[14:04] <micahg> ubuntu-sso-client was a partial transition that really shouldn't have been done before alpha3
[14:05] <micahg> the only other thing I can think of is temporarily adding a conflicts through the xubuntu-default-settings package or something
[14:05] <Laney> why isn't gst a problem for other universe flavours too?
[14:05] <micahg> laney: it is, but no one seems to have cared enough
[14:05] <Laney> hmm
[14:05] <micahg> it's on the technical overview
[14:05] <Laney> I mean that it pulls in libavcodec53 which is !ed out in the seeds
[14:06] <micahg> hrm, no idea
[14:07] <Laney> ah, only {l,x}ubuntu have it
[14:08] <Laney> no, seeded-in-ubuntu lies
[14:08] <micahg> kubuntu seems to have it also
[14:09] <ScottK> Which "it"?
[14:10] <ogra_> that
[14:10] <ogra_> :)
[14:10] <micahg> a block on libavcodec
[14:11] <Laney> libwebkitgtk-3.0-0 recommends gstreamer0.10-ffmpeg depends libavcodec53 which is blocked
[14:11] <micahg> right, so if I conflict something on gstreamer0.10-ffmpeg, that would temporarily fix it
[14:12] <micahg> or find more hamsters for the arm* builds
[14:12] <Laney> and make everyone remove it ...
[14:13] <micahg> well, idk if it's an issue for an alpha release anyways
[14:13] <micahg> assuming others don't have the tasksel issue
[14:17] <hggdh> infinity: (since you fixed it) will the server armhf-omap4 be rebuilt?
[14:17] <Laney> it just was
[14:18]  * micahg wonders if hggdh is ignoring queuebot
[14:19] <ogra_> hggdh, i'm just done with it, feel free to zsync
[14:19] <ogra_> (praying that fixes the flash-kernel issues now)
[14:19] <hggdh> micahg: duh, read the download link wrong.
[14:19]  * hggdh really needs some coffee
[14:20] <hggdh> ogra_: syncing and testing
[14:20] <ogra_> great, me too :)
[14:20] <blitzkrieg3> can I get a sponsor for bug 873027?
[14:20] <ubot2> Launchpad bug 873027 in unity-2d "DBUS_STARTER_ADDRESS and DBUS_STARTER_BUS_TYPE aren't always unset from environment making gedit and possibly others fail to start" [High,In progress] https://launchpad.net/bugs/873027
[14:21] <blitzkrieg3> into precise
[14:21] <blitzkrieg3> s/precise/oneiric/
[14:21] <hggdh> ogra_: just to be sure, it is the 25.3  image, correct?
[14:22] <ogra_> hggdh, yep
[14:22] <hggdh> roj
[14:24] <stgraber> blitzkrieg3: you might have more luck in #ubuntu-devel. Also, you may want to subscribe ubuntu-sponsors so that the bug shows up on the sponsoring report.
[14:24] <blitzkrieg3> stgraber: okay, thanks
[14:24] <ogra_> probably even better in #ubuntu-desktop
[14:28] <ogra_> bah
[14:28]  * ogra_ hits bug 1028905 again
[14:28] <ubot2> Launchpad bug 1028905 in cdrom-detect "cdrom-detect in quantal omap4 hangs trying to look for install media on an extended partition" [High,Confirmed] https://launchpad.net/bugs/1028905
[14:29]  * ogra_ zeroes the target and tries again
[14:39] <ogra_> grrr
[14:39] <ogra_> zeroing the target partition while it is mounted leaves the partition table in place
[14:39] <ogra_> err target device
[14:40] <ogra_> nasty bug that is ...
[14:41] <stgraber> ogra_: you usually need to ask the kernel to re-read the partition table after zeroing (hdparm -z) but that's only possible if the block device isn't in use.
[14:42] <ogra_> stgraber, yeah, well, i just zeroed it in my desktop , had to kill the installer anyway
[14:43] <ogra_> i really wonder why nobody else runs into this bug though
[14:43] <ogra_> i would assume many people use a target device multiple times without seeing the hang
[14:43] <hggdh> ogra_: is this related to the "unable to find /main/debian-installer/..."?
[14:44] <ogra_> err, no ?
[14:44] <ogra_> where do you see that ?
[14:45] <ogra_> the only two bugs with server i'm currently aware of are flash-kernel (seemingly) breaking apt-setup and the one above
[14:46] <hggdh> ogra_: on the armhf-omap4 server install -- installation fails because it cannot find any of the Packages or Packages.gz files
[14:46]  * hggdh goes dd-ing the SD again
[14:47] <ogra_> hggdh, scroll up in the log, thats not thae cause ... there is likely an update-initramfs run failing above
[14:47] <ogra_> and apt-install/in-target are blocked through that so apt-setup cant finish
[14:47] <ogra_> the last upload of livecd-rootfs and flash-kernel should have fixed that though
[14:53] <hggdh> ogra_: nope, no visible failure relating to initram
[14:54] <ogra_> i see "/dev/mmcblk0p1 is not a block device"
[14:54] <ogra_> which is the actual error ... since /dev isnt bind mounted during teh live-installer run
[14:55] <hggdh> ogra_: not here... but the additional storage I am using had a 12.04 install image
[14:56] <hggdh> here dev/mmcb* mounts OK (seemingly)
[14:56] <ogra_> can you put your syslog somewhere ?
[14:56] <hggdh> ogra_: I will try again and save it. Now both disks (SD and memstick) are already destroyed
[14:57] <ogra_> k
[14:57] <hggdh> on marvelous, now I do not have the super key anymore
[14:57]  * hggdh will try a reboot
[14:58]  * ogra_ hands hggdh a super key from a spare kbd he has around
[15:09] <skaet> ogra_, did the last rebuild take care of bug [13] from the pad?
[15:10] <ogra_> skaet, yes, and shoed another bug
[15:10] <ogra_> *showed
[15:10] <skaet> backscroll indicates it may have but.... want to make sure.
[15:10] <ogra_> but i'm waiting for hggdh's syslog to see we have the same issue
[15:11] <ogra_> the new live-installer code unconditionally runs an update-initramfs ... thats fine on all arches that dont use flash-kernel ...
[15:11] <ogra_> but f-k expects some pre-setup to have happened before it can even run the first time
[15:12] <ogra_> and that setup is usually the very last step on the installation ...
[15:13] <ogra_> which doesnt really help when tring to use these bits before
[15:13] <hggdh> ogra_: starting a new install
[15:13] <ogra_> great
[15:13]  * ogra_ has a super ugly hackist workaround but that should at least make A3 possible
[15:14] <hggdh> ogra_: is it expected that the d-i should start straight into the language screen?
[15:14] <ogra_> yep
[15:15] <ogra_> we dont have the shiny grub menu stuff or isolinux on arm
[15:17] <hggdh> ogra_: it went past the error now. I reformatted the memory stick (taking out the 12.04 install media there), and reimaged the SD
[15:17] <ogra_> oh
[15:17] <ogra_> weird
[15:18] <hggdh> different issue now, though, it did not recognise the memorey stick, so rebooting and retrying
[15:18] <ogra_> hggdh, thats bug 1028905
[15:18] <ubot2> Launchpad bug 1028905 in cdrom-detect "cdrom-detect in quantal omap4 hangs trying to look for install media on an extended partition" [High,Confirmed] https://launchpad.net/bugs/1028905
[15:18] <ogra_> zero the device
[15:19] <hggdh> but it did not hang, it kept on, just telling me I would not be able to repartition the SD
[15:19] <ogra_> weird
[15:19] <ogra_> you seem to have very intresting issues over there
[15:20] <ogra_> here is only fails after live-installer has run ... and i think infinity saw the same
[15:22] <hggdh> ogra_: not really, I do not match the bug -- I have no extended partition
[15:23] <hggdh> (I had two partitions before, but I reformatted the memstick to one single, ext4)
[15:23] <ogra_> ah, well, might be the same bug in a different manifestation ... pleas file a bug with syslog etc
[15:23] <hggdh> ogra_: against d-i?
[15:24] <ogra_> it isnt clear yet why cdrom-detect fails at all, might be a kernel issue or mount
[15:24] <ogra_> hggdh, for now, i'll re-assign then to the right package
[15:24] <hggdh> ogra_: OK.
[15:25] <hggdh> ah, I see why it did not get sda -- unsupported optional features (248)
[15:25] <ogra_> hmm, that shouldnt be fatal though
[15:27] <hggdh> it is not fatal, installation seems to be able to proceed -- I only do not have the option to install on sda
[15:29] <ogra_> very strange
[15:33] <ogra_> skaet, so i have one very hackish and ugly solution to the arm server problem, but i dont really want to upload it until someone like slangasek, cjwatson or infinity have taken a look and nodded it off ... it would give us A3 but i would revert it asap after that again
[15:33]  * ogra_ points at http://paste.ubuntu.com/1110307/
[15:35] <skaet> ogra_,  upload it to -proposed, and we don't copy it over to -release if they don't sign off on it?
[15:35]  * skaet figures that way its building while we're waiting for review....
[15:36] <Laney> this kubuntu alternate test install is taking some time ...
[15:36] <Laney> but i confirmed that xubuntu alternate is hosed
[15:37]  * Laney feeds hamsters to webkit
[15:38]  * micahg is going to cry, the armel webkit build restarted, so no chance of a copy to release at this point
[15:38] <ogra_> skaet, it builds in a few seconds, publisher will be the bigger concern :)
[15:38] <micahg> unless we just copy once the other archs finish
[15:38] <Laney> it restarted?!
[15:38] <micahg> yeah, the panda farm has had some weird issues as of late
[15:39] <Laney> woe
[15:39] <ogra_> pfft, armel, we really should finally drop that
[15:39] <Laney> i knew it was having problems at chroot setup time, but not at others
[15:39] <ogra_> as long as armhf builds i wouldnt worry to much
[15:39] <micahg> I had a build over the weekend that infinity had to start several times, upload was fri, finshed mon night
[15:40] <stgraber> ogra_: is something removing that file afterwards?
[15:40] <ogra_> stgraber, no, else f-k would never work
[15:40] <Laney> what happens to the copy if all builds aren't finished though?
[15:40] <Laney> does it work?
[15:40] <ogra_> it needs to stay in place
[15:41] <ogra_> 8until f-k -0ubuntu14 lands and a proper fix comes around)
[15:41] <micahg> well, we can kill the one in -proposed and restart it in the release pocket I think
[15:41] <stgraber> Laney: if only it'd ;) IIRC it copies the source + any built binaries
[15:41] <stgraber> Laney: then the remaining binaries are built in -proposed but can't be copied to -release and you can't get them to build in -release as they already exist in -proposed
[15:41] <stgraber> Laney: tldr, don't do that ;)
[15:42] <Laney> sigh
[15:42] <Laney> it'll still be rather late anyway
[15:43] <micahg> I was going to ask, when's the cutoff for respins?  armhf is 8-11 hours away still
[15:43] <Laney> I suppose not everything has to release at the same time
[15:43] <Laney> skaet: ?
[15:43] <ogra_> surely not the flavours
[15:43] <ogra_> and we had milestones in the past wehere the DVDs were a week late
[15:43] <micahg> well, just means the freeze shouldn't be lifted until everyone releases though
[15:44] <ogra_> which freeze ?
[15:44] <Laney> sigh, I didn't make the disk image big enough so kubuntu failed for that
[15:44] <ogra_> :)
[15:44] <micahg> alpha 3 :)
[15:44] <ogra_> we dont have freezes :P
[15:44] <stgraber> ...
[15:44] <micahg> we still have freezes :)
[15:44] <ogra_> we have self inflicted social feet calming :P
[15:46] <ogra_> (technically quantal isnt frozen ... its just nobody uploading)
[15:46] <micahg> it's a soft freeze, but we expect people to respect it
[15:46] <Laney> just because we don't have launchpad enforcing it doesn't mean that there isn't a freeze
[15:46] <ogra_> asdk rick, we dont have freezes :P
[15:46] <ogra_> *ask even
[15:47] <micahg> ogra_: that plan is something for the future, as I recall, the consensus was that Ubuntu would like to head in that direction, but isn't ready yet
[15:47] <Laney> indeed
[15:47] <Laney> for the current policy see devel-announce
[15:47]  * ogra_ didnt really plan to discuss that now ... i was just trying to be funny and obviously failed ... 
[15:47] <Laney> heh
[15:48]  * micahg hands ogra_ a whoopie cushion
[15:48] <ogra_> heh
[15:49] <skaet> Laney,  what's ready for A3 goes out as A3.   For full respins,  we're pretty much past it right now, unless its a true kitten killer (aka linux kernel bug we can't work around).   For selective images,  like armhf, we'll respin up for a bit yet.
[15:49] <Laney> I'm just wondering if xubuntu can do theirs later and still call it A3.
[15:49] <Laney> also, what that means for the freeze and turning the dailies back on
[15:50] <skaet> Once we announce, we swap where the output is directed
[15:50] <skaet> so,  it will go to the dailies
[15:50] <skaet> unless we hold up all the dailies...
[15:50] <Laney> so that's a no then
[15:50] <skaet> yup.
[15:51] <Laney> poor xubuntu :(
[15:51] <ogra_> skaet, oh, and wrt netboot arm i seemingly was mislead, the images are fine (omap4 at least, which i tested) and can be released
[15:51] <ogra_> so that saves me some paperwork :)
[15:52] <skaet> Laney,  they've got the dailies and can point folks at that image -  if the dailies are tested, we can probably look at manually copying it over to the A3 publishing directory, so it stays around.
[15:52] <skaet> ogra_, :)  ack
[15:52] <Laney> ok
[15:53] <skaet> Laney, micahg,  what's the timing on all the pieces landing for it?
[15:54] <Laney> day or so
[15:54] <micahg> skaet: can probably get the new images built before the freeze to be lifted
[15:54] <Laney> + spin + validation
[15:55] <micahg> hrm, I can just do a hack right now so we can respin the images now and not wait...it's not ideal, but should fix the issues
[15:55] <Laney> not the Conflicts ...
[15:55] <micahg> hrm, no, that will break existing users
[15:55]  * micahg thinks harder
[15:57] <skaet> slangasek, can you give ogra_'s hack a review, and see if we can live with it for A3? http://paste.ubuntu.com/1110307/
[15:57] <slangasek> ogra_: please put your flag file under /var/lib, not /usr/share, at least
[15:57] <ogra_> slangasek, ok, no prob
[15:57] <slangasek> ogra_: and of course, this only ensures tha the package must have been configured *once* before being called... is that sufficient?
[15:57] <ogra_> the next upload would remove it from apostinst snippet anyway
[15:57] <slangasek> is there a bug # for this?
[15:58] <ogra_> for d-i it is
[15:58] <slangasek> the next upload needs to remove the file too :)
[15:58] <ogra_> and no, there isnt a bug, we always immediately worked out a fix the last two days
[15:58] <ogra_> yes, i meant removing the file :)
[15:58]  * skaet would like the bug number for the pad, since this needs to be tracked to make sure we back it out.
[15:58] <ogra_> but i should probably file one now :)
[15:58] <ogra_> just not sure against what
[15:59] <ogra_> effectively the breakage is caused by console-setup running update intramfs
[15:59] <ogra_> but live-installer calls it ...
[15:59] <ogra_> and flash-kernel breaks it
[16:00] <ogra_> can someone reject my proposed upload so i can re-upload with a change to /var
[16:01] <micahg> ogra_: it's auto-accepted when not frozen
[16:01] <ogra_> hey, you just taught me we are frozen :P
[16:01] <ogra_> *g*
[16:01] <micahg> we are, it's just not enforced by launchpad :)
[16:01] <ogra_> ok, i'll bump the versio then
[16:01] <jibel_> stgraber, bug 1028972 on ltsp, not a3 critical
[16:01] <ubot2> Launchpad bug 1028972 in ltsp "Empty session menu in ltsp client" [High,New] https://launchpad.net/bugs/1028972
[16:03] <stgraber> jibel_: oh right, yeah, I saw that one, can't think of how it'd be LTSP's fault, probably a bug in indicator-session or in unity-2d
[16:04] <ogra_> uploaded
[16:05] <stgraber> jibel_: marked the ltsp task invalid and commented with some more information on what LTSP does so they have a chance to reproduce it easily
[16:06] <jibel_> stgraber, ok I added ltsp because I cannot reproduce in another environment
[16:08] <hggdh> ogra_: bug 1028983
[16:08] <ubot2> Launchpad bug 1028983 in partman-base "armhf-omap4: a disk formatted with ext4 fails to mount with partman" [Medium,New] https://launchpad.net/bugs/1028983
[16:08] <ogra_> thx
[16:10] <ogra_> YIPPIE !
[16:10] <ogra_> applying the fix manually makes me get through
[16:16] <stgraber> jibel_: testing a simple testcase for it now
[16:19] <ogra_> hggdh, dont forget the syslog :)
[16:24] <stgraber> jibel_: hmm, that's really odd, using Xephyr with the same configuration as LTSP I can't reproduce it anymore... wondering if it's something to do with the graphic card being used
[16:24]  * ogra_ reboots his panda and crosses fingers
[16:25] <ogra_> oh, thats odd
[16:25] <ogra_> seems there is another ordering problem with live-installer
[16:26] <ogra_> i had the reboot system message .... after confirming it runs "remove-live-packages" now instead of doing the reboot
[16:27] <ogra_> ah, now it reboots
[16:28] <ogra_> yippie... a prompt
[16:28] <ogra_> phew
[16:32] <hggdh> ogra_: the syslog should be there
[16:33] <ogra_> i dont see it on the website
[16:47] <hggdh> ogra_: yeah, LP surprised me, and did not add it in when I filled in the bug. It is now there
[16:47] <ogra_> yup, i see it but i cant see any error in it
[16:48] <ogra_> Jul 25 15:20:34 kernel: [  210.396301] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[16:48] <ogra_> it even mounts it properly
[16:48] <ogra_> i guess thats something for dr. watson :)
[16:49] <hggdh> it does indeed. Go figure :-(
[17:07] <stgraber> skaet: ltsp-live is busted on Edubuntu, preparing a fix now, will need a respin
[17:07] <stgraber> Laney: ^
[17:08] <stgraber> balloons: do you know android-lee? he marked these tests as passed yesterday, but the code is completely broken and there's absolutely no way he'd have been able to test that
[17:09] <balloons> stgraber, I do know android-lee.. jibel has found something similar in the past
[17:09] <balloons> I'll have a chat with him again
[17:09] <stgraber> balloons: can you talk to him? because if that happens again I'll have to disable his account (at least for the images where I'm the product manager)
[17:10] <stgraber> it looks to me like he's just marking them as pass without even testing, and that's by far worse than not having test results
[17:10] <hggdh> ogra_: I am reinstalling it again; I can bypass the loop by removing the memory stick and re-inserting it. I want to be sure I can repeat the install (i.e., this is the single issue left)
[17:10] <ogra_> ok
[17:11] <balloons> stgraber, yes.. do let me know when it happens
[17:12] <balloons> I understand the situation is he has access to a large number of machines, which is why he's able to test so much.. However, if his results are incorrect because he's testing improperly (or not at all) that's not helping
[17:16] <jibel> balloons, he never reports a failure, which to me seems unlikely if he is really testing, and adds no value to his testing
[17:17] <balloons> https://bugs.launchpad.net/~android-lee -- indeed so it appears
[17:18] <jibel> 927 results without a single failure. stop all dev we have the perfect release.
[17:20] <balloons> jibel, heh.. I have been talking to him, because my guess is that he is testing improperly since I wasn't seeing many bugs (when I found some in the same images).. This is concerning however that he's never reported any!?, and that we have confirmation of success when it clearly was impossible
[17:21] <balloons> I'll keep you and stgraber informed..
[17:21] <hggdh> ogra_: is this known? http://pastebin.com/uzB8xkBS
[17:29] <hggdh> ogra_: I just retagged the test as failed. I cannot repeat the install
[17:30]  * hggdh is off for lunch
[17:30] <stgraber> skaet: uploading edubuntu-netboot directly to the release pocket. I'll kick the Edubuntu rebuild (will update the pad in a sec)
[17:33] <stgraber> uploaded
[17:34] <skaet> stgraber,  ack
[17:34] <skaet> Laney,  slangasek,  ^ FYI
[17:44] <ogra_> hggdh, whats known ? your paste seems to be a bunch of encoded stuff
[17:46] <ogra_> skaet, can flash-kernel be moved over to the release pocket so that we can re-roll arm server ?
[17:47] <skaet> ogra_,  ok.   can you do the move?
[17:47] <ogra_> i'm not an archive admin
[17:48] <skaet> slangasek, ^ you around,  or should I go experiment.
[17:49]  * skaet goes to start experimenting.
[17:50] <stgraber> ogra_: you don't need to be an AA for that btw :)
[17:50] <micahg> ogra_: you can do the copy, just not the deletion in -proposed
[17:50] <ogra_> where is the doc ?
[17:50]  * ogra_ didnt know 
[17:51] <shadeslayer> so if someone can help out *just* a little bit, I might have EFI booting from a USB stick working in time for alpha 3
[17:51] <micahg> ogra_: it's generally not a good idea for most people to do this type of copying, but in this case, it doesn't make a difference
[17:51] <shadeslayer> I was wondering why init looks for /dev/sr0
[17:52]  * micahg wonders if sru-release -r will DTRT
[17:52] <ogra_> micahg, right, my question is rather "how ?" :)  i didnt even know thats possible for non AAs
[17:52] <shadeslayer> because I get to grub, I can boot stuff, but init fails while looking for /dev/sr0
[17:52] <stgraber> lp-shell production devel
[17:52] <stgraber> archive=lp.distributions['ubuntu'].archives[0]
[17:52] <stgraber> archive.copyPackage(from_archive=archive, include_binaries=True, source_name="flash-kernel", to_pocket="release", to_series="quantal", version="VERSION")
[17:52] <stgraber> ogra_: ^
[17:53] <stgraber> ogra_: just replace VERSION and that should work fine
[17:53]  * ogra_ installs lptools
[17:56]  * micahg still thinks sru-release -r would be simpler if we knew it to work
[17:57] <ogra_> hmm, https://launchpad.net/ubuntu/+source/flash-kernel/3.0~rc.4ubuntu14 still says proposed
[17:57] <micahg> ogra_: it worked
[17:57] <micahg> that might take a publisher cycle to update
[17:57] <stgraber> ogra_: copyPackage is async, can take a few seconds for LP to update, then it'll appear for both quantal and quantal-proposed until an AA cleans up -proposed
[17:58] <ogra_> great
[17:58] <micahg> :q
[17:58] <stgraber> ogra_: quantal-changes and your mailbox are usual good indicators to whether the copy worked ;)
[17:58] <ogra_> oh, ah
[17:58] <ogra_> heh
[17:59] <ogra_> my mail is async, it takes a while to arrive :P
[18:02]  * skaet comes back to the channel after digging in some docs, sees its been handled :)
[18:03] <ogra_> skaet, so after the next publisher run arm server is good to go
[18:04] <skaet> ogra_ ok,   I'll kick it off.
[18:04] <skaet> (when i see all the bits in the right place)
[18:04] <ogra_> awesome ! :)
[18:11] <skaet> ogra_,  what was the bug number for flash-kernel?
[18:12]  * skaet wanting to get the pad updated so we don't forget this needs to be backed out.
[18:13] <stgraber> skaet: ltsp's failing post-install on Edubuntu, checking if I can fix that in edubuntu-netboot, so no rebuilt yet please (I updated the pad)
[18:14] <skaet> stgraber,  yup.  seen the updates.     will only do an arm server rebuild.
[18:14] <skaet> (and thanks for putting the updates in!  :) )
[18:14] <highvoltage> stgraber: ok
[18:15] <highvoltage> (oops, stgraber was telling that to skaet, I have 'edubuntu' highlighted and sometimes that confuses me)
[18:18] <utlemming> stgraber: can you kindly add http://cloud-images.ubuntu.com/quantal/20120725 to the tracker?
[18:19] <stgraber> utlemming: sure
[18:19] <utlemming> stgraber: thank you kindly
[18:20] <stgraber> Can't find: eu-west-1-amd64-hvm
[18:20] <stgraber> utlemming: ^ is that a new one?
[18:21] <utlemming> stgraber: yes sir, brand new
[18:21] <stgraber> ok, so I guess it needs some setting up on the tracker before I can publish that one
[18:21] <utlemming> hvm was added to eu-west ~3 weeks ago
[18:24] <stgraber> ok, pushing again, should only be adding the missing entry
[18:27] <stgraber> infinity: https://code.launchpad.net/~stgraber/ubuntu-archive-tools/add-eu-west-hvm/+merge/116721
[18:51] <skaet> ogra_ have kicked off the arm server build for armhf+omap4
[19:09] <hggdh> ogra_: sorry, gave you the wrong link. Here it is, installation fails on configure the package manager: http://paste.ubuntu.com/1110679/
[19:27] <ogra_> hggdh, no, its the bug thats fixed with the new images (hopefully) ... see line 825 and 826
[19:28] <ogra_> everything below is fallout of in-target not properly returning
[19:28] <Laney> that ^ is the fix for [18]?
[19:28] <hggdh> ogra_: I thought it might be, but the bug is sort of short in details, and I wanted to be sure
[19:29] <stgraber> skaet: found a couple more bugs in Edubuntu LTSP. Uploading a new edubuntu-live now fixing these. Will be ready for a respin after that one.
[19:29] <stgraber> (apparently somebody synced ldm from Debian at some point during alpha-2 and alpha-3 breaking Edubuntu in a very subtile way ;))
[19:29] <ogra_> Laney, heh, someone only copied the last changelog entry :)
[19:29] <ogra_> the actual fix is the one before
[19:29] <skaet> stgraber,  ok.
[19:30] <Laney> please to be updating :-)
[19:30] <ogra_> err ... s/fix/horrible horrible hack/
[19:30] <hggdh> OK, burning the new image
[19:30] <skaet> ogra_, hggdh,  you've spotted that the image has posted....
[19:30] <skaet> :)
[19:30] <skaet> yup.
[19:31] <skaet> ogra_,  what did the bug number for it end up being?
[19:31] <hggdh> skaet: heh
[19:33]  * skaet --> get some lunch,  biab
[19:40] <ogra_> skaet, bug 1029083
[19:40] <ubot2> Launchpad bug 1029083 in flash-kernel "ordering issue when flash-kenrel is used with live installer" [High,Triaged] https://launchpad.net/bugs/1029083
[19:40] <ogra_> i'm not sure it wont turn into a live-installer bug though
[19:41] <slangasek> I think it's a facet of a general issue
[19:41]  * slangasek reads the bug
[19:41] <ogra_> the missing /dev bindmount is definitely something going wrong in there
[19:41] <slangasek> ah
[19:42] <slangasek> what's the failure mode?
[19:43] <ogra_> mode ?
[19:45] <ogra_> run-parts in update-initramfs fails which makes post-base-installer.d/25live-installer-console-setup fail ... which in turn makes in-target not return properly (?!?) ... the next in-target call makes the world explode
[19:46] <ogra_> thats also the reason why hggdh sees the error during apt-setup and not during live-installer
[19:47] <slangasek> hmm, interesting
[19:47] <ogra_> looks like at least three bugs
[19:48] <ogra_> missing /dev bindmount, in-target not returning, flash-kernel running even though its unconfigured
[19:48] <slangasek> and 25live-installer-console-setup only calls update-initramfs?
[19:48] <ogra_> i think so
[19:48] <slangasek> you might want to compare with /etc/kernel/postinst.d/zz-update-grub
[19:49] <ogra_> grub has a config it can check for etc
[19:49] <slangasek> except that's a *kernel* hook, and you're talking about an initramfs hook
[19:49] <slangasek> ah
[19:49] <slangasek> so fixing the lack of config for flash-kernel would fix this too? ;)
[19:49] <ogra_> flash-kernel currently doesnt leave any trace of being configured
[19:49]  * slangasek nods
[19:50] <ogra_> right, see bug 1026780 thats related
[19:50] <ubot2> Launchpad bug 1026780 in flash-kernel "3.0~rc.4ubuntu4 doesn't honor bootargs from /boot/boot.script anymore" [High,New] https://launchpad.net/bugs/1026780
[19:50] <ogra_> once we have the config dir we can check it for content and know there is a default config
[19:51] <slangasek> ogra_: how does flash-kernel know what device to install to?
[19:51] <ogra_> it has a database
[19:51] <ogra_> based on the output of /proc/cpuinfo
[19:51] <slangasek> ...
[19:52] <ogra_> namely the Hardware: field
[19:52] <ogra_> it is tricky to find a generic way to get HW info if you dont have a dim ;)
[19:52] <ogra_> *dmi
[19:53] <slangasek> I would've thought this would be configurable
[19:53] <ogra_> i think debian once picked the smallest denominator and that stuck
[19:54] <ogra_> all configuration is done in the DB
[19:54] <ogra_> which is just a textfile
[19:55] <slangasek> ok, so I think a stamp file in /var/lib may actually be appropriate even in the long term
[19:55] <slangasek> there may be other bugs that also need fixing
[19:55] <ogra_> well, we will need a bootscript.d (or something similar)
[19:56] <slangasek> for boot params?
[19:56] <ogra_> we cant ship something that always reverts user configs on package updates
[19:56] <ogra_> yeah
[19:56] <slangasek> right
[19:56] <ogra_> and if thats there we can easily have a check if the default bootconfig was copied in place
[19:56] <ogra_> that will make the /var stuff obsolete
[19:57] <hggdh>  ogra_: just to add insult to injury, my new install stopped at the beginning, with a kernel oosp on slow-path
[19:57] <slangasek> so I think the right way of this would be to have a single /etc/default/flash-kernel file with your boot option information; and this file is generated at package install time; so if the file exists you know it's configured
[19:57] <ogra_> hggdh, ouch !
[19:58] <slangasek> but the /var/lib/ stamp file is definitely an ok interim solution
[19:58] <ogra_> ok
[19:59] <ogra_> hggdh, thats a bit odd, given the image is pretty identical to the last one
[19:59] <ogra_> only the flash-kernel package should have changed
[20:00] <hggdh> ogra_: I retried, taking out the memory stick (the to-be /dev/sda). I did not see the oops, and installation is going on
[20:01] <ogra_> weird ... but i was suspecting USB issues ... i had one today too that went away after i powered off the board once ... same image worked fine the next try
[20:02] <hggdh> matches a bit of what I am seeing -- not always being able to reproduce
[20:02] <ogra_> as long as the kernel slightly works i wont complain though i rather see paolo invest his time in the 3.5 port than spending to much on the current kernel we will likely not ship
[20:03] <ogra_> though it should be tracked down indeed
[20:04] <ogra_> it might be related to bug 746137  which shows up again after we switched the image type
[20:04] <ubot2> Launchpad bug 746137 in jasper-initramfs "Page allocation failure on Pandaboard and Beagle XM" [Undecided,Fix released] https://launchpad.net/bugs/746137
[20:05] <ogra_> (preinstaled had a tool where we coudl easily dump sysctl.d bits in that were applied during resize ... thats gone so the issue is back)
[20:05] <ogra_> i have seen this bug with various NICs and wlan cards and also have seen it affecting USB stability in general before (not on a panda yet though)
[20:07] <Laney> ogra_: could that cause the machine to crash?
[20:07] <Laney> I've been seeing my panda going away every couple of days and kern.log is filled with that kind of stuff
[20:07] <Laney> -rw-r----- 1 syslog adm 2.4G Jul 25 20:54 kern.log
[20:07] <Laney> ...
[20:07] <ogra_> Laney, it can eat your ram
[20:10] <ogra_> yay, the germinate fix is in
[20:11] <Laney> I set vm.min_free_kbytes. We'll see...
[20:11] <ogra_> good luck :)
[20:12] <hggdh> ogra_: update_initramfs still barfs
[20:15] <ogra_> barfs as in "kills the install" ? or barfs as in "makes some log noise" ?
[20:17] <hggdh> prints out "installation will most likely be broken" and keeps on. But it seems it lost the network
[20:17] <ogra_> these seem unrelated
[20:18] <ogra_> i would blame USB for the network :)
[20:18] <ogra_> as long as it moves on, dont worry
[20:18] <hggdh> what me worry?
[20:19] <ogra_> lol
[20:19] <ogra_> this update-initramfs run is totally bogus anyway
[20:20] <ogra_> the actual initramfs you will use will be created at the bootloader setup time
[20:22] <ogra_> (and that one will be usable, i promise) :)
[20:22] <hggdh> if I reach that point, you mean ;-)
[20:23] <ogra_> i suppose you will ... i reached it with my last test install when making flash-kernel just exit 0 at the top
[20:24]  * ogra_ finds it funny how update-initramfs runs three times in a row ... always with the message "deferring update (trigger activated)"
[20:25] <ogra_> but still building a new initrd indeed
[20:25] <hggdh> uh-ho. sequence of tcp_recvmsg errors in the log
[20:25] <hggdh> recvmsg bug: copied yadda yadda
[20:25] <ogra_> that smells very much like 746137
[20:26] <hggdh> darn!
[20:26] <hggdh> OK. if nothing else works, power it off, count to 10, power it on again
[20:26] <ogra_> no promises ... just guessing here :)
[20:26] <ogra_> if you prefer to find a new bug ...
[20:28] <hggdh> I will be more than happy hitting a known bug, thank you
[20:33] <hggdh> now I deleted the partition for /dev/sda, no lockups on start (so far)
[20:54] <stgraber> skaet, Laney, slangasek: starting the Edubuntu respin now
[20:54] <skaet> stgraber, ack
[20:55] <slangasek> stgraber: ack
[20:55] <Laney> gogogo
[20:57] <infinity> ogra_: I haven't read all of backscroll, but saw the pastebinned f-k "fix".  I assume you've sorted out by now why it'd bad?
[20:58] <infinity> ogra_: s/it'd/it's/
[20:58] <infinity> ogra_: Oh, no, you uploaded it. :/
[20:58] <infinity> ogra_: So, that just broke every upgrade and every system not installed with f-k-i.
[21:02] <slangasek> oh, that was being done in the flash-kernel-*installer* postinst?  sigh
[21:02] <slangasek> sorry, reading fail
[21:02] <infinity> slangasek: If it was in the f-k postinst, it still wouldn't DTRT, since f-k is installed during the livefs build.
[21:03] <slangasek> ah
[21:03] <infinity> (But yeah, in this case, it was f-k-i)
[21:03] <infinity> I'm trying to sort out what problem he was trying to solve with this.
[21:05] <slangasek> infinity: flash-kernel being called via update-initramfs before it's usable
[21:06] <infinity> slangasek: I guess installing u-boot-tools was determined to not be sufficient somehow, then?  *sigh*
[21:06] <slangasek> I only know what scrollback and the bug report say
[21:06] <slangasek> u-boot-tools was not mentioned
[21:06] <slangasek> there was some issue with /dev not being bind-mounted, though
[21:12] <infinity> slangasek: Hrm.  Well, it looks like it's only the /dev mount missing that's the issue, from the log, unless I'm missing something critical.
[21:13] <slangasek> infinity: see any obvious root cause?
[21:13] <infinity> slangasek: But the better and saner answer is probably violently diverting update-initramfs in live-installer.
[21:16] <blahdeblah> Hi.  Can anyone tell me why http://changelogs.ubuntu.com/meta-release-lts doesn't list precise as an LTS?
[21:18] <slangasek> blahdeblah: so that users aren't automatically upgraded from lucid to precise until 12.04.1 comes out
[21:18] <stgraber> blahdeblah: my guess is that this is the file being checked by the upgrader and we don't allow upgrades until the point release
[21:18] <blahdeblah> So that is intended behaviour?
[21:18] <stgraber> yes
[21:19] <stgraber> 12.04.1 will appear on there when the point release is released, on the 23rd of August
[21:19] <jbicha> blahdeblah: I think you can run update-manager -d if you want to upgrade 10.04 to 12.04 before .1 is released
[21:19] <blahdeblah> Cool - thanks for the help folks.
[21:22] <hggdh> OK, finally, a working install of server on a pandaboard
[21:22] <infinity> As in, a respin with ogra's hack worked for you?
[21:24] <hggdh> no, it did not. What seems to work (still to confirm) is to have /dev/sda with an empty partition table (so ogra_'s hack does not seem to fully work)
[21:24] <infinity> Well, ogra's hack didn't relate to partition tables at all.
[21:24] <infinity> Two entirely different bugs.
[21:25] <hggdh> but I had a truckload of different errors
[21:25] <hggdh> sorry, ogra's original bypass
[21:26] <hggdh> as in bug 1028905
[21:26] <ubot2> Launchpad bug 1028905 in cdrom-detect "cdrom-detect in quantal omap4 hangs trying to look for install media on an extended partition" [High,Confirmed] https://launchpad.net/bugs/1028905
[21:26] <infinity> Maybe the solution to the bootloader issue is just to not install flask-kernel in the livefs at all, and let f-k-i do its job...
[21:27] <infinity> flash-kernel, even.
[21:27] <infinity> Would need icky special-casing just for server. :/
[21:43] <ogra_> infinity, nah, lets just implement bootscript.d or as slangasek suggested use /etc/default/flash-kernel
[21:44] <ogra_> then we can have a check if its configured and make it gracefully exit
[21:44] <slangasek> neither of which actually seem to solve the problem
[21:44] <infinity> ogra_: It's not being "configured" in the first place, though.
[21:44] <slangasek> if flash-kernel is installed in the livefs, *everything* that would indicate configuration is there too
[21:44] <infinity> ogra_: It's configured from the point it's installed, you're pretending it's not because something else on the system is broken.
[21:46] <ogra_> how about making live-installer simply divert update-initramfs and remove that diversion at the end is recreating the initrd actually necessary in that step ?
[21:48] <ogra_> i really cant see a reason for running it at that point of the install
[21:48] <infinity> It's just a postinst from a package it's installing in /target
[21:48] <infinity> Not a deliberate call to update-initramfs.
[21:48] <ogra_> it is called three times here
[21:50] <slangasek> it's necessary to ensure you've generated an up-to-date initramfs before the end of the install; it is not necessary to generate one at each package install along the way
[21:50] <ogra_> but yeah, its a postinst trigger that runs it
[21:50] <slangasek> *however*, it's *also* necessary to ensure there's an up-to-date initramfs before you do things like calling the kernel package hooks on x86
[21:50] <slangasek> since that's where grub.cfg gets generated
[21:51] <slangasek> and this is not at all congruent with what flash-kernel does
[21:51] <infinity> Well, flash-kernel is a bit weird with good reason.
[21:51] <ogra_> no, definitely not
[21:52] <slangasek> flash-kernel is "when a new initramfs is generated, call flash-kernel so it gets written to the right disk."  grub is "when a new kernel is installed, update the grub config".
[21:52] <slangasek> see, they're so different they don't even agree on whether end-sentence punctuation belongs inside the quotes or outside
[21:52] <ogra_> *grin*
[21:53] <slangasek> so aside from this one bug of /dev not being correctly bind-mounted, everything else is probably just an optimization
[21:53] <slangasek> and for now we should probably focus on fixing the /dev bind mount rather than further hackery on live-install or flash-kernel
[21:54] <ogra_> well, flash-kernel needs changes in any case, but for that bug fixing the bindmount will suffice
[21:56] <infinity> (And please revert the previous two f-k revisions)
[21:56] <ogra_> hmm, the tracker isnt up to date it seems
[21:56] <ogra_> infinity, with sugar and kisses
[21:56] <infinity> Thankfully, with only f-k-i dropping that file places, I guess we don't need to worry about cleaning the unowned file up on upgrade.
[21:56] <infinity> Cause, like, 3 people have it.
[21:57] <ogra_> oh, and it also still says preinstalled on the tracker, hmm
[21:58] <stgraber> sounds like a case where nobody created the non-preinstalled variant on the tracker, so it doesn't auto-publish there
[21:59] <ogra_> well, intrestingly enough the build number has been updated up to 20120725.1
[21:59] <ogra_> (last preinstalled was in june)
[22:00] <stgraber> hmm, either post-qa on nusakan needs some tweaking or somebody updated it manually ;)
[22:01] <ogra_> someone did ... but i cant remember who
[22:01]  * ogra_ checks irclogs
[22:02] <stgraber> ogra_: oh, I see... someone renamed the product on the tracker but didn't hack post-qa, so post-qa has no clue where to post the new build
[22:03] <ogra_> ah, k
[22:04] <stgraber> ogra_: hmm "Added build (20120725.4) with ID: 19500" so it auto-posted fine, and I see 20120725.4 on the tracker at the moment... what are you looking at ? :)
[22:04] <ogra_> stgraber, right, it showed up right now
[22:04] <ogra_> http://iso.qa.ubuntu.com/qatracker/milestones/226/builds/19500/testcases
[22:04] <ogra_> that still says preinstall
[22:05] <ogra_> (minor thing indeed)
[22:05]  * ogra_ adds his result and finally calls it a day
[22:06] <stgraber> yeah, balloons or someone else will have to deal with the testcases. We probably want to keep the preinstall testcases for < quantal (so history is consistent) and then have a regular set of server testcases for >= quanal
[22:38] <skaet> ogra_,  are you trying to do the f-k reverts  and the /dev bind mount, today/early tomorrow.  or are we giving up on the arm server for A3?
[22:39]  * skaet can't quite figure plan from backscroll...