[11:17] <hvn2> hi, question on boot: is the /boot/abi file necessary for successful booting ? I've been reading about abi but can't figure this out
[11:39] <infinity> hvn2: No, it's just there as a reference.
[11:46] <hvn2> inifinity: ok, thank you. I'm trying to figure out why my custom kernel 3.5.7 (for 12.04) won't boot and keeps hanging at "Uncompressing Linux... done, booting the kernel.". So far I found no solution.
[12:28] <apw> hvn2, that is very early, try adding debug and loglevel=9 to the boot
[12:28] <apw> hvn2, also does the mainline 3.5.7 
[12:28] <apw> boot for your machine
[12:29] <apw> hvn2, as infinity says the /boot/abi is not used at runtime at all
[12:30]  * apw hates on debconf questions which always appear 10s after you leave an upgrade to finish by itself
[12:31] <hvn2> apw: where should I add debug and loglevel ?
[12:32] <hvn2> apw: e.g. in the kernel or in boot.scr ?
[12:34] <apw> on the kernel command line, however you are setting that
[12:34] <apw> as it is a boot.scr i assume it is some kind of arm board
[12:35] <hvn2> apw: yes it is an armv7 board
[12:37] <hvn2> apw: I assume then I should put loglevel=9 in boot.scr ?
[12:39] <apw> and debug in whever you set the kernel command line
[12:39] <apw> that is likely there, but i don't have the same boards, and they don't all work the saem
[12:41] <hvn2> apw: do you have a suggestion for how to put debug  ?
[12:42] <apw> debug is the word you want, like loglevel it instructs the kernel to be noisier
[12:43] <hvn2> so, just put the word debug in boot.scr ?
[12:49] <apw> hvn2, put it with loglevel=9 in the kernel command line specification hwever that is done in your boot loader
[12:50] <hvn2> apw: ok
[13:12] <hvn2> apw: I put loglevel and debug in boot.scr and rebooted...it hangs again, but how do I check on the loglevel and debug now ?
[13:42] <hvn2> apw: the syslog is only started after starting the kernel, not after boot ?
[14:12] <arges_> smb: hello. i see the neutron kernel crash bug has some more comments.
[14:12] <arges> smb: I wonder if it makes sense for us to provide a machine one of their developers can access so they can setup a reproducer and then we can crash it at will and perform experiements?
[14:12] <smb> arges, Yeah, not more to work on though , yet
[14:12] <arges> and also snapshot it
[14:13] <smb> arges, Feel free to offer that to them
[14:17] <arges> smb: or would it be too much to ask them to reproduce in a VM, then tar it up so we can download the disk?
[14:19] <smb> arges, Well that might be simplifying the setup. If they can get a kexec crash they can share with us that sounded good enough. And meanwhile try to find a simpler reproducer
[14:20] <smb> If ones is found we learn more about the trigger, too
[14:20] <arges> yup
[14:20] <smb> If not, maybe still we are lucky and get a dump
[14:20] <arges> smb: so stilll 1) get a crash dump 2) get a reproducer?
[14:21] <smb> That was my thinking when proposing it. Or rather 1) get the crashdump and while waiting 2) try to get a reporducer. Not sure I was clear  with that :)
[14:23] <smb> arges, Getting a setup locally may or may not be sucessful. Ok, it could be but also we could find out that it needs a certain environment in which the host is to trigger
[14:24] <smb> Ok, we could realize that when trying to find a reproducer, too
[14:24] <arges> smb: i'll send an email with this info you can reply with clarifications
[14:27] <smb> arges, ok, wfm
[19:23] <apw> b 3
[20:39] <miseria> "nunca trates de abarcar el mundo con las dos manos, al final de tus dias, te quedaras sin manos y sin mundo" *bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
[21:11] <stgraber> so we have a regression with 3.13 on the wandboard... my box won't boot with 3.13.0-11. Last running kernel was -6, will try to figure out exactly which upload broke it now.
[21:31] <stgraber> 3.13.0-10.30 to 3.13.0-11.31 is where the regression happened
[21:32] <stgraber> hmm, that doesn't make much sense looking at what changed in 3.13.0-11.31...
[21:34] <stgraber> yeah, that actually doesn't make any sense seeing that the armhf configuration didn't change at all in that upload (just bits being moved to common)
[21:35] <stgraber> I guess we'll see if 3.13.0-12.32 magically works (in which case I'll blame cosmic rays), if not, then maybe something toolchainy changed?