[13:22] hi [13:25] how big would be an image with just installer? I would like to boot it on arm chromebook [13:29] hrw, http://ports.ubuntu.com/dists/saucy/main/installer-armhf/current/images/omap4/netboot/ [13:31] 85MB total [13:32] hrw: More like 15MB downloadable. [13:33] so just kernel + initrd? [13:33] hrw: Or that nice little img.gz file. [13:34] hrw: Ignore the FAT images, those are a single partition from the .img. And I really should stop publishing them, I don't think anyone uses them. [13:34] Except Oli, who uses them by accident and gets confused. [13:34] yeah [13:34] hehe [13:35] partitioning step can be too hard for most users ;( [13:36] hrw: Anyhow, I have no idea how one boots the Chromebook, but if you can give me step-by-step "this is what a bootable image should look like and how to consutrct it" pseudocode or shell, or whatever, I can commit that to d-i and make chromebook d-i images. [13:36] infinity: I know. [13:36] Or, well. I can't do that without chromebook kernels being in main, until we take a decision to allow universe-using images, actually. But. We can at least make it work in custom builds. [13:37] infinity: booting is less a problem as we can just give people SD/USB image and tell 'use ctrl-u'. [13:37] I think we were *this* close to enabling universe d-i builds for all the ARM kernel flavours. And then they all went away. [13:37] And I suppose chromebook could go away soon too, with the upstream bits landing in 3.10/3.11? [13:38] (Landing in multiplatform/-generic, that is) [13:38] hrw: Sure, but I need to know what that SD image looks like. [13:38] hrw: (That's what the omap4 ones there are -- SD images) [13:38] the problem is that to install ubuntu on internal you need to resize STATE partition, reboot so chromeos will reinitialize it, boot again, create gpt partitions, write kernel to one of them etc... [13:39] Ahh, so you'd need some solid d-i support for the platform in partman and such. [13:39] (The rebooting bit sounds like a pain) [13:39] yes [13:39] and with those 3 users which may care at all it does not have sense [13:39] Perhaps not. It might be better to just have wiki instructions somewhere than proper installer support. [13:40] Though, why is the reboot necessary? Is ChromeOS blessing the partition somehow? Can we not synthesize that ourselves? [13:40] infinity: it creates some dirs there etc [13:41] setups ecryptfs infra etc [13:43] is there nothing like gpt_rereadpt() ... so you dont need to reboot [13:44] ogra: probably it can be left as it is with hope that chromeos will do what needs to be done on next start [13:44] right, thats what i was thinking [13:45] I kind of like current state - no ppa required to get it working [13:45] flash-kernel needs to be added still [13:46] bug 1164484 anyone? [13:46] Launchpad bug 1164484 in flash-kernel (Ubuntu) "Add support for checking Device Tree model name" [Low,Confirmed] https://launchpad.net/bugs/1164484 [13:47] we need to sync with Debian... [13:47] flash-kernel (3.1~exp.1) experimental; urgency=low [13:47] [ Ian Campbell ] [13:47] * Add support for FDT based devices using /proc/device-tree/model for [13:47] detection. [13:48] i think we have that already [13:48] Yeah, some FDT work is on my TODO list, along with testing a bunch of -generic platforms. [13:49] iirc there were some fixes from ppisati and marvin24 ahead of debian [13:49] (for DT support) [13:49] We do things a bit differently from Debian, AFAIR, but I'm not sure either of us gets it all entirely right yet. [13:50] have to take a look [13:50] well, didnt we release DT based images ? [13:50] with raring [13:50] for server at least [13:50] No. [13:50] hmm, i thought we had the genric kernel there already [13:50] We do. === kentb-out is now known as kentb [13:51] so we have to have DT support [13:51] Not really. [13:51] else server wouldnt work [13:51] highbank has the DT flashed in ROM. [13:51] ah [13:51] Which requires no userspace support at all. [13:51] And that's, by far, the preferred method. If the DT is provided by the ROM/bootloader, we need to do nothing. [13:51] But some platforms aren't so lucky. [13:52] device-tree string not found in flash-kernel anyway [13:52] well, i surely remeber seeing patches for that about 6 months ago already ... [13:52] look through the f-k buglist perhaps [13:53] 15:46 < ubot2> Launchpad bug 1164484 in flash-kernel (Ubuntu) "Add support for checking Device Tree model name" [Low,Confirmed] https://launchpad.net/bugs/1164484 [13:53] Ubuntu bug 1164484 in flash-kernel (Ubuntu) "Add support for checking Device Tree model name" [Low,Confirmed] [13:53] They weren't using the proc lookup, they were using the subarch guessing bits, I think, which is much less reliable. [13:53] ogra: I remember few discussions about it already [13:54] right [13:54] hrw: Anyhow, this is on my TODO, since I have some -generic testing and mangling to do as well. [13:54] and to add chromebook to flash-kernel I will need DT stuff anyway [13:55] and then with 3.11 hope to get rid of kernel ;) [13:55] 3.10 will be too minimalistic [13:55] With any luck, 3.10, but I wouldn't hold my breath on it all landing in time. [13:55] infinity: from Olof's post 3.10-rc4 lacks many things still [13:55] Though, you could move linux-chromebook to being ubuntu-3.10 + patches. [13:56] infinity: plan to move it first to 3.8-chromeos [13:56] Or ask ppisati to backport a mess of patches, if they hit mainline post-3.10 [13:57] ;D [13:57] I'd like to ship 3.11 for Workgroups in saucy anyway, but I'm not sure that'll happen. [13:57] haha, the microsoft kernel ... funny [13:57] 3.11 kernel should use something with 6.22 as well [13:58] Actually, 3.11 should land before kernel freeze, so we might get it. [13:58] Well, just barely. Maybe. [14:00] I wonder why Linux hasn't trolled lkml yet with an announcement that the release after 3.11 will be version 95. [14:00] or 4.0 [14:00] s/Linux/Linus/ [14:01] hrw: No fair, the internal version numbers actually made sense. [14:02] (Though the NT/win-on-dos convergence was confusing as heck) [14:04] I really need to corner a marketing guru sometime and get them to explain to me in really small words why "95, ME, 2000, XP, Vista, 7" was deemed more appealing than "4, 4.1, 5.0, 5.1, 6, 7" [14:05] you forgot 98 [14:05] I did indeed. [14:06] 98 was 4.1, Me was 4.9 [14:06] heh. flash-kernel/ubuntu was not updated in bzr for few versions ;( [14:07] infinity: Maybe they were going for http://news.softpedia.com/news/Presenting-Windows-CEMeNT-Lost-and-Found-39978.shtml [14:07] cjwatson: A classic. [14:08] But, seriously, I've always wondered. None of these names ever seem well thought-out or consumer-friendly. [14:08] Adobe ditches version numbers to go to "creative studio", and then cops out with "CS2" and "CS3". [14:08] Etc. [14:08] 95/98/2000/Me were ~fine - just ~year of release [14:08] It's entertaining to me, but it must be frustrating as heck to people who have no clue what they're buying. [14:10] can we force [14:10] ops [14:20] I see how DT is handled in Debian [14:20] not quite what we wanted during discussions [14:20] as they go for DTname OR cpuinfo-name [14:22] 13 files changed, 333 insertions(+), 194 deletions(-) [14:22] huge change [14:23] no changelog/control: 11 files changed, 125 insertions(+), 120 deletions(-) [14:30] 9 files changed, 98 insertions(+), 9 deletions(-) [14:31] http://pastebin.com/ExmnaiMS - ubuntu changes on top of Debian flash-kernel [14:32] there are some places where Debian code took over Ubuntu one === hrww is now known as hrw === NCommander is now known as Guest14386 === aarcane_ is now known as aarcane === aarcane_ is now known as aarcane === Guest14386 is now known as NCommander === Daviey_ is now known as Daviey === cjwatson_ is now known as cjwatson === kentb is now known as kentb-out