=== jkridner_ is now known as jkridner
=== Ursinha` is now known as Ursinha
=== Ursinha is now known as Guest90314
[07:10] <janimo> lilstevie, does rooting always mean 1) downgrading to a firmware that has a vulnerability if the firmware is newer + 2) applying an old root method?
[07:12] <twb> janimo: on what hardware?
[07:12] <janimo> twb, I am interested in tf101g
[07:13] <janimo> but for devices with no unlocked bootloader I guess the same generic methdos should apply?
[07:14] <twb> g is the "prime" one?
[07:16] <infinity> No, prime is tf201.
[07:18] <janimo> the asus site docs say theupdater cannot to downgrades so  am not sure how the old root tricks fooled it into it
[07:19] <janimo> anyway I was a fool to upgrade to ICS before making sure rooting requires a specific version of the firmware present
[07:20] <twb> I deliberately bought the one with a known SBK
[07:30] <janimo> twb, I bought the only model still on stock, but before making sure it should be rootable :(. I vaguely remembered all transformers are unlocked or rootable now
[07:34] <twb> newer ones allegedly are if you ring up asus and ask for the key
[07:34] <twb> In return for which they refuse all warranties for that particular S/N
[08:16] <janimo> twb, hmm, you mean I could ring up asus and ask for a secure boot key? Or what key do you mean? I would happily do that if realistic
[08:17] <janimo> altough I am not sure tf101g qualifies as new enough, it is still last year's model
[08:18] <twb> janimo: that was on the primes, I heard
[08:18] <twb> Where "ring up" means some wanktacular web form, I assume
[08:18] <janimo> yeah, I eard primes are ulockable indeed
[08:19] <janimo> btw the xda and various other web resources related to rooting are the most disorganized fountains of knowledge I ave ever seen
[08:20] <janimo> it is relatively little possible information to be conveyed spread across numerous threads and lots of participants
[08:23] <twb> Well they are web fora
[08:24] <twb> i.e. fugly HTML usenet for people who are too stupid to configure a newsreader
[08:56] <Daviey> twb: 'fora'?  Shame, you are one of them.
[09:01] <twb> My high school did not offer latin, sorry
[09:02] <twb> https://en.wiktionary.org/wiki/forum#Noun
[09:03] <twb> fowler (1e) makes no comment.
[09:03] <twb> Nor does Strunk & White (unsurprisingly, it being quite short)
[09:07] <twb> Heh, I just noticed the "usage notes" on that URL come from fowler 2e, that travesty
[09:32] <ogra_> rbasak, hmm, where is that binary header you mention in the review ? the merge page doesnt show anything like that
[09:32] <ogra_> oh, i'm blind, ignore me
[09:32] <rbasak> ogra_: np. I'm just doing highbank now. Could you hold off on a merge please?
[09:33] <rbasak> ogra_: I'm basing my patch on dannf's.
[09:33] <ogra_> sure, i'll fix the header during merge though, no need to wait for the US to get up :)
[09:34]  * ogra_ wonders why no image has the new flash-kernel, but they all still build 
[09:34] <ogra_> looks like we have a to loose dependency chain here, they should fail without it
[10:22] <janimo> ogra_, is flash-kernel getting unified with the debian one this cycle?
[10:23] <ogra_> janimo, well, as much as we can at least, depends if we get highbank and armadaxp into debian in time :)
[10:23] <ogra_> for all the other arches yes though
[10:23] <janimo> sounds good
[10:23] <janimo> ogra_, what about the jasper/liveCd stuff, is that migration started?
[10:23] <ogra_> your hack for updating the bootkloader has to go elsewhere too
[10:24] <ogra_> no, but we plan to do this switch too this cycle
[10:40] <NCommander> ogra_: is the hardware database for the new f-k uploaded yet? (I'm not sure which package its in)
[10:41] <ogra_> it is in f-k itself
[10:41] <ogra_> infinity wanted to split it out into an arch all package though
[10:42] <ogra_> NCommander, dannf has done an armadaxp  patch and rbasak works on highbank
[10:42] <ogra_> so dont worry, its all taken care of
[10:42] <NCommander> ogra_: wait, I thought the entire point of this was so f-k could be synced, yet the HW database is in the new package?!
[10:43] <ogra_> first step: sync and make sure all images work again (preferably by not changing flash-kernel but by adapting other packages to match the new world order)
[10:44] <ogra_> next step: make sure our f-k changes land in debian
[10:44] <ogra_> last step: split out the db
[10:44] <NCommander> ogra_: then repeat steps one and two. Doesn't it make mor esense to split out the DB first :-)
[10:45] <ogra_> no idea, i think it makes most sense to discuss it with debian and have them do the split ;)
[10:45] <rbasak> /usr/sbin/dpkg-reconfigure: flash-kernel is broken or not fully installed
[10:45] <rbasak> but apt-get -f install does nothing and there's no other indication of a problem
[10:45] <rbasak> Any hints?
[10:45] <rbasak> I need to run, back in an hour :-/
[10:45] <ogra_> try to dpkg -i the deb
[10:46] <NCommander> rbasak: is that with the new f-k? I wasn't aware you were taking the new f-k enablement
[10:46] <ogra_> alöso the main/universe issues arent solved yet, did you install the necessary packages ?
[10:46] <ogra_> NCommander, yes, he works on highbank support
[10:46] <NCommander> rbasak: I'd much prefer having a boot menu, but I realize this has become a time sink now, so ATM, let's roll with the bootz method you had, then I'll get it fixed for the precise SRU/updated for quantal
=== Guest90314 is now known as Ursinha
[13:38] <rbasak> ogra_: I have a working flash-kernel on highbank now. But one error: http://paste.ubuntu.com/1016144/. This appears to be coming from linux-base because it doesn't recognize flash-kernel as a bootloader. Do we know about this already? Presumably it'll affect all the other boards too?
[13:39] <ogra_> well, flash-kernel isnt a bootloader
[13:39] <rbasak> That's fine. But linux-base needs to not complain :)
[13:41] <ogra_> well, linux-base also need to move to main, i dont expect the switch to work without hassle (never  did) ;)
[13:42] <ogra_> i'll look into it, atm i'm rather trying to find out why the images dont fail if f-k is missing
[13:46] <rbasak> I think this should be a Debian issue as well, which is why I'm confused.
[13:47] <rbasak> f-k depends on l-b, but l-b will complain unless grub or lilo or a bunch of other bootloaders is installed
[13:47] <ogra_> did you set Bootloader-sets-root in your db entry ?
[13:47] <rbasak> Yes
[13:47] <ogra_> to what ?
[13:47] <rbasak> to "yes".
[13:47] <rbasak> To override the one supplied by U-Boot, which doesn't know
[13:47] <rbasak> Previously flash-kernel could write a kernel cmdline into boot.scr, but now it appears that it can't do that any more
[13:47] <rbasak> But Bootloader-sets-root: yes will work for now
[13:48] <ogra_> yes means it creates a file in the initrd which needs to contain a UUID
[13:48] <ogra_> sigh, thats horrible perl in the linux-base postinst
[13:48] <rbasak> more specifically it overrides the root= kernel parameter
[13:49] <ogra_> well, yes, if the file exists in the initrd it will use the value in there
[13:49] <rbasak> Perhaps I could try setting bootargs to omit root= in boot.scr, then I won't need that.
[13:50]  * rbasak tries it
[13:50] <ogra_> hmm, i wonder where "DebianKernel::BootloaderConfig" comes from
[13:51] <ogra_> that seems to be the bit complaining
[13:51] <ogra_> if (!is_fresh_installation() && version_lessthan($ARGV[1], '2.6.32-18')) {
[13:51] <ogra_>     DebianKernel::BootloaderConfig::check($deb_arch);
[13:51] <ogra_> }
[13:51] <ogra_> that seems to be the code snippet that causes the complaint
[13:55] <ogra_> and the real issue seems to be that "my @config_files " doesnt have anything for u-boot at all
[13:56] <ogra_> lool, any idea ? ^^^^
[14:02] <ogra_> rbasak, hmm, looking closer it doews exactly what its supposed to be, what you see there is a note not an error
[14:03] <rbasak> ogra_: it stops the install with priority=critical. Not sure why, since the note is priority=high.
[14:05] <ogra_> well, but we should be able to preseed it differently to quieten it
[14:07] <rbasak> Shouldn't it be clever enough to detect flash-kernel and shut up?
[14:07] <rbasak> The warning is meaningless when flash-kernel is in use
[14:08] <ogra_> flash-kernel has nothing to do with it (as i said, its not a bootloader)
[14:09] <ogra_> the code looks for known bootloader configs and doesnt know about u-boot
[14:09] <ogra_> if i read it right it should be possible to switch that off by preseeding linux-base/disk-id-convert-auto to flase
[14:10] <ogra_> *false
[14:10] <ogra_> rbasak, do you have a virgin env around you could test that in ?
[14:11] <rbasak> I can test a preseed option, yes.
[14:11] <ogra_> or just hack the template of the package :)
[14:12] <ogra_> which i think we should do if the package moves to main, having it check the bootloader configs just for reading out the latest kernel version from /boot doesnt really make sense
[14:12] <rbasak> This is stupid though. I know that flash-kernel isn't a bootloader. But when we're using flash-kernel, then that depends on linux-base, and we know that no bootloader is required. So linux-base should not complain. It should detect flash-kernel as an exception to its warning, such that if flash-kernel is present it does not need to check for a bootloader and does not need to warn the user.
[14:12] <ogra_> well, i beg to disagree :)
[14:13] <rbasak> The message is "The boot loader configuration for this system was not recognized.". If flash-kernel is present, the boot loader configuration can be recognised. It's recognised as do-not-care.
[14:13] <rbasak> OK, well I'll file a Debian bug and see what they say about it.
[14:13] <ogra_> linux-base should learn about u-boot ... not about flash-kernel
[14:13] <rbasak> flash-kernel is where u-boot knowledge is kept.
[14:14] <ogra_> not always
[14:14] <rbasak> Specifically, in that DB now. How else is linux-base to discover the situation?
[14:14] <ogra_> specifically in debian where you are not required to use it at all for arm images
[14:14] <rbasak> If linux-base is taking it upon itself to figure out the situation, it should be able to figure out the situation correctly.
[14:14] <ogra_> right
[14:14] <ogra_> but it looks for bootloaders not for flashing tools
[14:15] <rbasak> flash-kernel is no longer a flashing tool
[14:15] <ogra_> thats its purpose
[14:15] <ogra_> just because we abuse it differently doesnt change its purpose in debian
[14:16] <ogra_> what i dont get in the beginning is why linux-base checks that stuff at all
[14:16] <ogra_> its only a tool to get you the latest kernel version in /boot
[14:19] <rbasak> just reading up a bit: I'd say that linux-base should be figuring out the situation correctly, so it should be looking for both bootloaders _and_ flashing tools
[14:19] <ogra_> rbasak, given we carry ubuntu changes in linux-base anyway 8and will go on doing so as long as debian ships perf in there) we should just change the preseed default
[14:19] <rbasak> I'm testing the preseed as we speak
[14:19] <ogra_> i will upload a change if that works and we should be done
[14:20] <ogra_> we really dont want it to touch any bootloader configs in any ubuntu arch anyway
[14:26] <lilstevie> janimo: downgrades are typically disallowed meaning new exploits are required
[14:30] <rbasak> ogra_: no luck with the preseed. I tried "linux-base/disk-id-convert-auto boolean false" - was that right?
[14:34] <rbasak> ogra_: the flash-kernel change is working though, and ready: https://code.launchpad.net/~racb/ubuntu/quantal/flash-kernel/highbank2/+merge/108173
[14:38] <ogra_> rbasak, awesome, i'll take care for linux-base, dont worry about it
[14:38] <rbasak> thanks ogra_!
[14:39] <janimo> lilstevie, I was just looking at 'Wolf'd method' (sounds like some math theorem) on xda-forums which according to some allows ICS downgrades
[14:40] <ogra_> rbasak, could be be a bit more verbose in the README entry ?
[14:40] <ogra_> like "Calxeda highbank systems" or something like that ?
[14:41] <rbasak> ogra_: I started off doing that, then I realised that the machine type in the db needed to match /proc/cpuinfo, and I made the README match that too. I'm not sure if they're doing that with the other machines or not?
[14:41] <ogra_> no, i dont think armadaxp actually says "Marvell Armada XP Development Board (Ubuntu)" in cpuinfo :)
[14:42] <rbasak> :-)
[14:42] <rbasak> Go ahead and change if you like
[14:42] <ogra_> will do
[14:43] <lilstevie> janimo: pm me please :)
[15:01] <ogra_> rbasak, merged and uploaded
[15:02] <rbasak> thanks ogra_!
[15:48] <ogra_> rbasak, linux-base uploaded with the postinst removed completely ... bug 1006717 is the MIR in case you want to follow it
[15:48] <ubot2`> Launchpad bug 1006717 in linux-base "[MIR] linux-base" [Undecided,Incomplete] https://launchpad.net/bugs/1006717
[15:49] <rbasak> thanks ogra_!
[15:49] <ogra_> (and i dont think its worth filing a debian bug for linux-base ... it makes totally non-ubuntuish assumptions all over the place :) )
[17:28] <GrueMaster> ogra_: the "Marvell Armada XP Development Board" in flash-kernel (12.04) was copy/paste from cpuinfo.  Just FYI.
[17:32] <ogra_> GrueMaster, well, it doesnt have (Ubuntu) appended in cpuinfo i bet
[17:32] <ogra_> i just think the README entry should get you an idea about the HW
[17:33] <ogra_> and "highbank" is somewhat not telling you anything :)
[17:36] <GrueMaster> I couldn't tell you what was in cpuinfo at this point.  I'm a bit removed from the project.  :P
[17:36] <GrueMaster>  But iirc, I was the one that added the entry to flash-kernel, and it was a straight copy/paste.
[17:37] <GrueMaster> Since cpuinfo is largely just raw text from the arm soc code (i.e. not derived from silicon), it could have been (knowing Marvell).
[17:38] <ogra_> well, the db definitely needs the exact match ... the readme not so much
[17:38] <GrueMaster> Yes, agreed.
[17:39] <GrueMaster> Anyway, thought I'd add my $.02 worth.  Back to my real job.
[17:39] <ogra_> heh, have fun
[18:14] <dannf> ogra_: oh.. did i add Ubuntu to the wrong field?
[18:15]  * dannf made that change post-test, after merging onto the ubuntu tree - might've screwed that up
[18:16] <dannf> oh, nope - that's in the README. w/ that i was following suit w/ the precise's flash kernel which appeared to mark Ubuntu-only additions w/ (Ubuntu)
[18:16] <dannf> but that's not in my debian tere
[18:55] <XavierMiller> Leave
[22:04] <janimo> lilstevie, managed to downgrade using wolf
[22:04] <janimo> wolf's method. great.now on to rooting
[23:33] <lilstevie> janimo: :)