[00:13] <infinity> mjrosenb: There is no armel in trusty, so those errors are entirely expected.
[00:13] <infinity> mjrosenb: If that's an armel machine, there's no sane upgrade path.
[00:13] <mjrosenb> infinity: no, that was done with multiarch
[00:13] <mjrosenb> back when multiarch seemed like the one true path.
[00:13] <infinity> mjrosenb: If it's an armhf machine with some armel multiarch action going on, you'll probably need to tear out 'dpkg -l *\:armel' before you start.
[00:14] <infinity> mjrosenb: multiarch is the one true path, just not for architectures we've dropped. :P
[00:14] <infinity> (I use it to great success with amd64/i386/armhf/arm64/ppc64el/powerpc....)
[00:15] <mjrosenb> infinity: well, I just removed the line from the multiarch file
[00:15] <infinity> Also, if that machine's running X, I hope you don't love PowerVR accelerated 3D drivers, cause PVR and TI dropped support for them long ago, and we no longer have binary blobs to ship.
[00:15] <infinity> So, trusty has no binary drivers for Pandas.
[00:15] <mjrosenb> do-release-upgrade complained about: https://gist.github.com/bd8a05405f3e4be74f18
[00:16] <mjrosenb> so as long as plymouth being broken doesn't mean I can't boot, I don't care.
[00:16] <mjrosenb> infinity: does X still work with a frame buffer of sorts?
[00:16] <infinity> Well, "apt-get -f install" and see what it does, or is grumpy about.
[00:16] <infinity> mjrosenb: I believe X still works nominally via an FB, yeah, though unity (which is 3D-only in trusty) will really not.
[00:17] <infinity> Other desktops, like xfce, probably work alright.
[00:17] <infinity> Sadly, our hands were tied on this.  It was either support a 3.5 kernel forever, or drop Panda 3D support.  We opted for the saner route. :/
[00:17] <infinity> Yay, non-free drivers.
[00:18] <mjrosenb> infinity: hooking a monitor up to the machine is like 90% a last-ditch-effort.
[00:18] <infinity> Yeah, mine ocasionally gets a monitor hooked up, but only to look at the console.  There's no X.
[00:18] <infinity> My Panda's pretty much a really crappy server.
[00:18] <mjrosenb> well, when I installed ubuntu, X came with it.
[00:18] <mjrosenb> mine is a debugging/benchmarking machine.
[00:19] <infinity> Ahh, yeah, if you used on the desktop images.
[00:19] <infinity> So, you might be happier with a fresh install.
[00:19] <mjrosenb> although about half the time, I'm actually running inside of a debian chroot that is still softfp.
[00:19] <infinity> If you have a USB hard drive hooked up to it, slapping in a 14.04 d-i image in the SD card and just installing fresh might give you a saner (and leaner) system.
[00:20] <mjrosenb> infinity: if this goes pear shaped, that'll be my first step.
[00:20]  * infinity nods.
[00:20]  * mjrosenb is very tenacious about not re-installing.
[00:21] <infinity> Yeah, I have a machine that's been upgraded since potato, I know the feeling.
[00:21] <infinity> potato, woody, hoary, (many Ubuntu releases), trusty.
[00:21] <infinity> I think.
[00:21]  * mjrosenb is somewhat sure that is from before I started using linux.
[00:21] <mjrosenb> infinity: how did the debian->ubuntu switch go?
[00:22] <infinity> Went fine back in the warty/hoary days, since sidegrading was a goal when we were starting fresh.
[00:22] <infinity> These days, I'm not sure I'd attempt it.
[00:22] <mjrosenb> at my last job, the sysadmin that set up my machine gave me a 32-bit non-pae install, and 8 gigs of ram.
[00:23] <mjrosenb> convincing debian to do a 32->64 bit transition was /fun/
[00:23] <infinity> Although, on a simple text-only serverish install, wheezy->precise would probably upgrade fine.
[00:23] <infinity> I wouldn't dare try it on a desktop with a bunch of fancy installed, though.
[00:24] <mjrosenb> right so, no plymouth -> no fancy boot gui or no plymouth -> no boot?
[00:24] <infinity> Depends on the state of the no plymouth.
[00:24] <infinity> If it's half broken, it could lead to no framebuffer consoles.
[00:24] <mjrosenb> file /sbin/plymouthd
[00:24] <mjrosenb> /sbin/plymouthd: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x868f0842a830948469aa2a0650a9d8a492703912, stripped
[00:24] <infinity> It *probably* should still boot and give you serial and SSH, however, unless it's really, really broken.
[00:25] <mjrosenb> my first experience with plymouth was sub-par.
[00:25] <infinity> DId "apt-get -f install" not shed light on what was broken?
[00:25] <mjrosenb> to say the least.
[00:26] <infinity> plymouth is somewhat overengineered, IMO, but it does do one thing better than what we had before, which is multiplexing console input at early boot, so you can reliably do things like ask for luks passwords.
[00:26] <infinity> Which is why we use it even on text consoles.
[00:27] <mjrosenb> my first experience with it was on gentoo, since I was setting up an htpc, and i wanted a pretty boot.
[00:28] <mjrosenb> and it always hung
[00:28] <mjrosenb> very quickly.
[00:28] <infinity> Yeah, I'm still not convinced it handles the simple job of "pretty boot" any better than the old attempts like usplash or splashy.
[00:28] <infinity> But the input stuff is gold, if you can be bothered to wind through the maze of how the heck it works.
[00:29] <mjrosenb> turns out, openrc was attempting to read from its stdin, which it assumed was a tty (because why would it not be a tty)
[00:29] <infinity> Derp.
[00:29] <infinity> Everyone assumes everything's a TTY still, despite this being 2014.
[00:29] <infinity> It's depressing how often I see that class of bug.
[00:29] <mjrosenb> and tried to get it to get no blocking by twiddling the terminal bits.
[00:30] <mjrosenb> turns out, stdin was being provided by plymouth, so setting it to noblock did *nothing*
[00:30] <mjrosenb> then it read from stdin, and plymouth didn't have anything for it
[00:30] <infinity> Shockingly. :)
[00:31] <mjrosenb> (it read from stdin so the user could interrupt the boot process)
[00:31] <mjrosenb> which is normally a very useful featur.
[00:31] <infinity> On the other hand, I expect this sort of learning experience from a build-your-own OS like Gentoo or Arch.
[00:31] <infinity> I'd be filing bugs like a crazy person if this happened to me on Ubuntu or Fedora.
[00:32] <mjrosenb> infinity: true.  I'm mostly used to it, but that was the first time I ever had to modify init to find out what was failing.
[00:32] <infinity> And yes, the whole "press any key to interrupt" sort of thing needs to be handled by plymouth in a plymouth world.
[00:32] <infinity> Which is both bad and good, depending on viewpoint.
[00:33] <infinity> Bad, cause it's added complexity, good, cause you can have it listen literally EVERYWHERE for that key, and serialize input, and deal with it somewhat sanely.
[00:34] <infinity> (Well, more important than the listening everywhere is the notifying everywhere, so you get output on text consoles, serial, etc, telling you that a key might need to be pressed)
[00:34] <infinity> Handy for things like filesystem check progress (and cancellation), for instance.
[00:35] <infinity> But, yeah.  Despite all the above, I'm not a big plymouth advocate.  I like what it provides, but I desperately want someone to NIH it with something less crap with similar features.
[00:35] <infinity> Sadly, I suspect that someone will be Lennart, and it will have a taint to it that I don't appreciate.
[00:36] <infinity> The taint likely being that it'll end up in the systemd binary because, hey, why shouldn't your init system have complicated framebuffer and font rendering code?
[01:09] <mjrosenb> is plymouth systemd-only yet?
[01:11] <infinity> *snort*
[01:18] <mjrosenb> infinity: ok, very different question, do you know if gcc supports TCO on arm?
[01:25] <mjrosenb> also, re: apt-get install -f, it did not shed any light on the issue
[01:25] <mjrosenb> https://gist.github.com/43ac4b97ba79207e216e
[01:25] <mjrosenb> but I'm pretty ok with that.
[01:47] <infinity> mjrosenb: Well, it looks like it fixed it up, so that works.
[01:48] <mjrosenb> yup. and it booted to some form of gui.
[02:55] <mjrosenb> infinity: gaaah :-(
[02:55] <mjrosenb> perf doesn't work.
[02:56] <mjrosenb> wait, what?
[02:56] <mjrosenb> why is my kernel still 3.2?
[02:56] <mjrosenb> 3.2.0-1452-omap4 #72-Ubuntu SMP PREEMPT Tue Aug 19 20:46:59 UTC 2014
[02:56] <mjrosenb> this *is* a new kernel.
[02:57] <infinity> mjrosenb: Oh, cause we didn't forcefully upgrade people from the TI kernel, specifically because of the 3D issue.
[02:57] <infinity> mjrosenb: apt-get install linux-generic linux-tools-generic
[02:57] <infinity> mjrosenb: SHould get you the non-TI kernel and matching perf.
[02:59] <mjrosenb> I'm kind of surprised that a 3.2 kernel still works.
[03:02] <mjrosenb> infinity: so you both display the warning that the upgrade may nuke the video, and don't upgrade the kernel so the video doesn't get nuked?
[03:12] <infinity> mjrosenb: There was a warning too?
[03:12] <infinity> mjrosenb: In that case, yes!
[03:12] <infinity> mjrosenb: It was a while ago since we took these decisions, it's all fuzzy now. :P
[03:13] <mjrosenb> infinity: just covering all of your bases :-p
[03:13] <mjrosenb> at least, there was a warning when I tried to do it through the gui.
[03:13] <mjrosenb> I didn't check when I ran do-release-upgrade.
[03:14] <infinity> mjrosenb: I think the "don't bother upgrading" thing was based on an assumption that the intersection of people who use Pandas and people who care about security updates was probably lower than the intersection of people using them as media devices/etc and people who didn't care about security.
[03:14] <infinity> mjrosenb: That, and that people using them as build servers and such were typically nerdy enough to ask/search and get the right answer to get the new kernel.
[03:14] <mjrosenb> oh, the new kernel is pulling in all sorts of new goodies.
[03:15] <mjrosenb> at least a new libc.
[03:15] <infinity> New libc?  *blink*
[03:15] <infinity> That should already have been there. :P
[03:15] <infinity> Sounds more like your upgrade only half finished.
[03:15] <infinity> Which is likely, given the error you got.
[03:15] <infinity> A dist-upgrade might not be a bad plan.
[03:15] <mjrosenb> Processing triggers for libc-bin (2.19-0ubuntu6.3) ...
[03:15] <mjrosenb> maybe.
[03:16] <infinity> Oh, no.  Triggers != new package.
[03:16] <infinity> Triggers are, well, triggers.  That's ldconfig running, in the libc case.
[03:17] <mjrosenb> yeah, I saw libc scroll by, and spoke
[03:17] <mjrosenb> then I looked at what it said.
[03:17] <mjrosenb> Setting up libunwind8 (1.1-2.2ubuntu3) ...
[03:17] <mjrosenb> that's new though.
[03:17] <infinity> unwind would be a new -tools dep.
[03:17] <infinity> Don't recall what links it, but probably perf.
[03:17] <infinity> Cause perf links in half the world.
[03:17] <infinity> Rather bloated little binary for a kernel tool.
[03:18] <mjrosenb> that being said.
[03:18] <mjrosenb> Kernel /boot/vmlinuz-3.13.0-35-generic does not match your subarchitecture
[03:18] <mjrosenb> omap4, therefore not writing it to flash.
[03:18] <mjrosenb> does not sound good.
[03:20] <infinity> Oh, Paolo, way to go.
[03:20] <infinity> I bet that's a chicken and egg issue he didn't notice with flash-kernel.
[03:20] <infinity> Basically, I assume it's looking for the DTB version of the board name, not the old version, and you don't get that until you boot with a DTB.
[03:21] <infinity> A hand-edit of /usr/share/flash-kernel/all.db (or whatever, tab complete a bit) to make the old OMAP4 entry match the new one (ie: make both Machie: types do the same thjings with the generic kernel, etc) should fix it.
[03:21] <infinity> Then if it gets overwritten in an upgrade, no big deal, cause you'll have the new Machine ID.
[03:22] <infinity> Amazed no one else has tripped on that, or cared enough to report it.
[03:24] <mjrosenb> infinity: if you point me at a bug reporter, I can file it (5 months after 14.04 was released)
[03:25] <infinity> https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+filebug
[03:27] <mjrosenb> infinity: ... I copied that, then typed in bugzilla.mozilla.org
[03:28] <mjrosenb> "type the two words" it is a picture of a house, with 119 on it.
[03:29] <mjrosenb> ok, really, what is it with recapcha giving me nothing but a single street address?
[03:30] <mjrosenb> evidently, I cannot file a bug because I cannot create an account
[03:30] <mjrosenb> since I am not a human.
[03:45] <mjrosenb> infinity: ok, I'm once again stumped.  all.db doesn't exist on the filesystem, and all directories belonging to flash-kernel don't seem to have anything that looks like a database in it
[04:13] <mjrosenb>                                 if [ `expr "$kfile" : '.*linaro.*-omap$'` -ne 0 ]; then
[04:13] <mjrosenb>                                         check_subarch "omap"
[04:13] <mjrosenb>                                 else
[04:13] <mjrosenb>                                         check_subarch "omap4"
[04:13] <mjrosenb> looks like it is /explicitly/ checking against omap and omap4.
[05:04]  * mjrosenb wonders where these people infinity said would be coming on line in a bit :-p
[05:05] <mjrosenb> ugh. looks like I need to recover my pandaboard.
[05:07] <mjrosenb> infinity mentioned that upgrading to 14.04 if ubuntu is installed on a usb disk should be pretty easy
[05:40] <mjrosenb> blast, as soon as I get to Starting kernel ...
[05:41] <mjrosenb> it drops the serial connection
[05:41]  * mjrosenb guesses he needs to configure the kernel to spew to serial
[05:56] <mjrosenb> baudrate=115200
[05:56] <mjrosenb> that is already in the kernel arguments... that does not bode well.
[05:56] <mjrosenb> err, no.
[05:56] <mjrosenb> no, bootargs is controlling uboot.
[05:59] <mjrosenb> ah, I don't know how printenv works.
[06:00] <mjrosenb> thete is no bootargs.
[06:00] <mjrosenb> that sounds bad.
[07:41] <mjrosenb> anyone up/home yet?
[10:35] <mjrosenb> is 14.04 supposed to use uEnv.txt on the pandaboard?
[11:07] <mjrosenb> argh, I really wish I knew why this is failing with an unhelpful error message.
[21:41] <mjrosenb> infinity: you back yet?
[21:41] <mjrosenb> (I think you're the only other person I've seen talk in here since I joined.)
[21:59] <infinity> mjrosenb: I'm aroundish, but pretty busy.