[11:07] <infinity> cjwatson: So, remember my "How the heck did this ever work?" comments about ubiquity and flash-kernel-installer?
[11:08] <infinity> cjwatson: The answer is "it never did", as far as I can tell.
[11:08] <infinity> cjwatson: It accidentally worked (as in, f-k-i never ran, but update-initramfs fixed it all up) because jasper writes /etc/flash-kernel.conf.  Except that appears to not be working as of very recently.
[11:13] <infinity> cjwatson: Which gets me shockingly no closer to an answer, because that's yet another bit of code that hasn't changed in forever and mysteriously stopped working, but it's a hell of a lot easier to debug at least. :P
[11:13] <infinity> cjwatson: (In P, we (or I, I suppose) should fix ubiquity to actually do bootloaders correctly for ARM, though)
[13:36] <infinity> cjwatson: How are you at partition math?
[13:41] <cjwatson> slow
[13:42] <cjwatson> I usually get there in the end
[13:44] <infinity> Heh.
[13:44] <infinity> Well, I have a sneaking suspicion post-boot-armel+omap is wrong.
[13:44] <infinity> EXT4-fs (mmcblk1p2): bad geometry: block count 1505280 exceeds size of device (1505264 blocks)
[13:44] <infinity> ^-- Is a bit of a hint on that. :P
[13:45] <infinity> We're sometimes writing our filesystem past the end of the image.
[13:51] <cjwatson> that happens to be rounding up to 735MiB
[13:51] <cjwatson> which may have something to do with it
[13:52] <cjwatson> an off-by-one (multiplied by cylinder size or something) error wouldn't surprise me
[13:53] <infinity> Yeah, an off-by-sectors/cylinders/something error seemed fairly reasonable.
[13:54] <infinity> But I don't know partitioning well enough to really be sure what the shell math in post-boot does, except make me wince.
[13:54] <cjwatson> at the moment it makes me go cross-eyed; I'm short on sleep
[13:54] <infinity> Heh.
[13:54] <cjwatson> I guess I can have another look on Monday if you haven't figured it out by then, though a plain English description of what it's *supposed* to do wouldn't hurt
[13:55] <infinity> I think what it's meant to do is actually reasonably obvious, except for the part where heads/tracks/blocks/cylinders all make my brain bleed after a bit.
[13:56] <infinity> Which is silly, it's just simple arithmetic.  I probably just need to reduce it to meaningless variables and stop pretending it relates to fictional drive geometry. :P
[13:57] <infinity> Then again, with all the sleep I haven't been getting, 8am might be the wrong time for me to care.
[13:57] <infinity> (Note that it's "late" still, not "early"...)
[17:59] <milesp> hi
[18:00] <milesp> can you guys help me with an install issue?
[20:03] <infinity> I've never been so disappointed to see a tool that does what it's supposed to.
[20:04] <infinity> (klibc's reboot correctly syncs before reboot, so I'm still stumped as to why some of the things I'm writing to / aren't getting there)
[20:04] <infinity> Unless this is subtle FS corruption brought about by the image size thing I just fixed, in which case, yay?
[20:04] <infinity> (rebuilding an image with yesterday's livefs to see)
[20:13] <cjwatson> I thought the kernel synced before reboot nowadays, never mind klibc
[20:15] <infinity> It might, but both our shutdown implementations do too.
[20:15] <infinity> So, my glroious theory that maybe my writes were skipping the FS is shot.  This new image better just magically work. :P