[03:28] ogra_: seems the flash-kernel hook at initramfs broke the way linaro uses to generate the image [03:29] without a valid fstab, update-initramfs will be blocked at /usr/share/initramfs-tools/hooks/flash_kernel_set_root [03:29] at pause_error [03:33] that's just because we install the kernel and the extra packages before setting up the rootfs [03:36] ogra_: while we could fix at linaro-media-create, to set up fstab before installing the packages, this would probably be an issue when using a chroot that contains a valid kernel package installed [03:37] guess it'd also try to update the initramfs, and would prompt the user at the same warning message [05:44] ogra_: mind reviewing the debdiff? bug 1034734 [05:44] Launchpad bug 1034734 in flash-kernel "flash-kernel shouldn't prompt the user when updating initramfs in case there's no valid /etc/fstab" [Medium,Confirmed] https://launchpad.net/bugs/1034734 [05:44] I pushed a similar version at our overlay ppa and I'm finally able to get them working and booting again [05:45] without this patch it'll set root as "", which it'll not end up finding the rootfs to mount at the boot [05:45] janimo: probably what caused your boot issue as well ^ [05:45] * rsalveti gone [08:00] rsalveti: fstab is the wrong place to be looking for the root device in the first place. [08:26] rsalveti, you mean the quantal linaro image not booting? thanks [08:37] rsalveti, i'm working currently on changing that ;) [08:37] infinity, thanks for the cedarview package reviews [08:38] rsalveti, /etc/default/flash-kernel will carry the cmdline, you can just put a default value for root= in there [09:45] infinity, its not wrong, it is doing what it is defined to do (there ia a switch in the db for it that i will flick as soon as we generate proper bootloader configs again) [09:59] ogra_: No, it's wrong regardless. Systems can run without an fstab. Refusing to install a bootloader because you can't be bothered to actually find the rootfs (but, instead, just trust fstab) is, well. Wrong. [09:59] ogra_: But I agree that the wrongness will be worked around by switching to commandline mangling. [09:59] not if you say that the parameter in the config will do exactly this :) [10:00] ogra_: Still, there's no reason to hardcode / ANYWHERE. [10:00] once we can set Bootloader-sets-root to yes it will behave properly [10:00] ogra_: I'd have to double-check, but I imagine update-grub does it on the fly, not from conffiles. [10:01] if grub has a setting "make-grub-search-for-root-in-fstab" and i set that, it is exactly what i expect it to do [10:02] we simply default to the equivalent option in flash-kernel atm [10:04] which is wrong but unavoidable until we have proper bootloader configuration in place [10:04] ogra_: No, but I mean, when you change things to use /etc/default, you're still hardcoding the rootfs. [10:04] yep [10:06] I see no reason to do that... [10:06] just to provie an easy way for the user to change the cmdline [10:07] No, I'm cool with the easy way to change the commandline. [10:07] in a generic place all arm setups we offer has [10:07] Not the hardcoding of the rootfs. [10:07] oh, i read you now [10:07] you want the logic from grub copied into f-k [10:08] or at least similar behavior ... [10:08] Indeed. [10:08] * ogra_ agress but doesnt want something like /etc/grub/ in the end :) [10:09] You should be able to ship /etc/default/f-k in a way where it's the same on every normal system. [10:09] And running f-k should "just work". [10:09] right [10:09] Having the rootfs hardcoded anywhere is wrong. [10:09] btw ... it just struck me that all the live installer stuff i'm doing here is total nonsense [10:10] we just need to export FLASH_KERNEL_SKIP ... [10:10] (and make sure its unset when we run f-k-i) [10:10] I still think that diverting update-initramfs and only calling it once at the end of the install is the Right Thing, optimisation-wise. [10:10] But that's certainly not flash-kernel's job. [10:11] well, diverting works fine up to the point where pkgsel wants to do the same [10:11] Yes, like I said, it shouldn't be any package's job to do it. [10:11] my option would be to check for an existing diversion and mangle the DIVERTS list [10:11] It should be something the installer cleverly sorts out at a more fundamental level (as ubiquity does). [10:12] but that adds more code that i like to [10:12] But, in your case, exporting a magic variable does seem much simpler. :P === Quintasan_ is now known as Quintasan [10:12] *than [10:13] hmm, except that in-target doesnt seem to carry it over into the chroot [10:13] weird, i thought it should [10:13] in-target just runs commands... [10:13] chroot /target blah blah [10:14] yeh, i know [10:14] That certainly won't carry an environment. [10:14] And probably clears it intentionally. [10:14] thats what i mean [10:16] Yeah, I misread the first time, and thought you were doing somehting odd like "in-target export FOO=1" [10:18] nope, i just set FLASH_KERNEL_SKIP=1 in the live-installer.postinst at the top [10:18] hmm, i should probably export as well :P [10:18] Did you export it? [10:18] Jinx. [10:18] * ogra_ sighs, bug 1028905 is making me mad [10:18] Launchpad bug 1028905 in cdrom-detect "cdrom-detect in quantal omap4 hangs trying to look for install media on an extended partition" [High,Confirmed] https://launchpad.net/bugs/1028905 [10:21] funnily i didnt see it once during the bamboo-feeder testing where we used rotary usb didsk ... [10:21] i wonder if its actually limited to flash storage by whatever reason [10:23] Could be, it was on flash that I saw it here too. [10:23] But... Weird, if so. [10:24] yep [10:37] yeah, exporting works fine indeed [10:43] infinity, hmm, so grub uses grub-probe from grub-common to find the uuid, i wonder how evil people would consider making flash-kernel depend on grub-common [10:46] ogra_: Hah. Seems a bit silly. ;) [10:47] well, grub-probe is a c binary, not sure i would want to pull something like this into f-k [10:48] If it doesn't depend on anything else in grub-common, one could perhaps examine shipping the binary on its own. [10:48] (and i surely dont want to have to maintain it) [10:48] Or something. [10:49] i guess we have enough scripted alternative tools to find / though [10:49] from where i could steal snippets and put them into f-k === piezo_ is now known as piezo [13:03] howdy! ubuntu runs the pandaboard with the ondemand governor by default - any nice way to pin it down at 920MHz? or just hackish things? [13:04] modify the ondemand init script? [13:13] LetoThe2nd, blacklist cpufreq-ondemand.ko so it can't load if it's a module (although this doesn't stop GNOME from picking it), and pick performance as a governor instead. That said, GNOME definitely forces ondemand the first time you load the power management utilities. Since Unity tends to re-use GNOME code and I think this is definitely one of the things they re-used, there's not really a good way of doing it. You could take the ondemand gover [13:13] nor out completely though :) [13:14] Neko: no gnome there, its a cli only install [13:14] oh, then nothing should try and load it if you blacklist it in theory [13:34] sigh, nothing more depressing than your server's hd failing [13:34] ogra_: sorry, didn't follow the entire discussion, but my issue with the current way flash-kernel is dealing with the rootfs parameter is that it replaces the one provided by the bootloader [13:34] while that can fix a few cases, where the user can't change the bootloader settings, it can also cause some other side effects [13:34] like not allowing the user to change the rootfs by the command line, just from the rootfs [13:35] besides that, the implementation was wrong as well, fixed with my debdiff [13:35] ogra_: how are you planning on fixing the issue? [13:35] just because that breaks our quantal images [13:36] rsalveti, just edit the db entry as i described in the bug [13:37] oh, will check the bug, just got on-line [13:37] which i will make the default once we started generating bootloader configs again [13:37] currently it is just set in a way that forces the lookup in fstab [13:38] well, it's looking for that setting, but it's broken anyway [13:38] no, it isnt [13:38] it fails before actually checking for Bootloader-sets-root [13:38] because we don't have any fstab by the time that script runs! [13:38] oh, that would be broken [13:39] Bootloader-sets-root should definitely trigger looking for fstab [13:39] if thats not happening the right way, i agree it is a bug [13:39] Bootloader-sets-root: yes should just use whatever the bootloader config provides [13:40] and shouldnt use fstab or the initrd at all [13:40] if thats not working as expectd that needs fixing [13:40] the point is that we currently forcefully default to checking fstab [13:40] on purpose [13:41] yeah [13:41] so the behavior is exactly what we defined in the config [13:42] the patch I sent it's just makes the script to skip this setting, because in case there's no fstab, there's nothing to do [13:42] Bootloader-sets-root: yes looking for fstab is a bug though, but a different one [13:42] right, it isnt supposed to do that, since your initrd wont have the needed entry then [13:42] the problem with the current code is that it checks for /etc/fstab first and then check for Bootloader-sets-root [13:42] it should fail if it cant set the entry [13:42] right, lets fix that then [13:43] ogra_: alright, let me propose a better fix then [13:43] suppressing something that was explicitly set isnt the solution though [13:44] yup [13:45] * ogra_ tried out postler today ... looked like an awesome minimal desktop mail client... until i found my password in clear text in ~/.config/postler :P [13:46] ogra_: :D [13:54] ogra_: But you run full disk encryption anyway, so it doesn't matter, right? :P [13:55] hahaha [13:55] ogra_: (And most mail clients store passwords in reversible hashes, it's not actually any more secure) [13:56] ture ... but plain text ... uh [13:56] Plain text it just not having silly pretense. [13:56] and no, i dont get why anyone would use disk encryption on a home desktop [13:56] As long as the file perms are correct, it's the same level of security as every other client. [14:00] ogra@anubis:~/Devel/kernels/build/ubuntu-precise-imx6-sabre-77f462e$ ls ../*deb [14:00] ../crypto-modules-3.2.0-1001-imx6-sabre-di_3.2.0-1001.2_armhf.udeb ../linux-headers-3.2.0-1001_3.2.0-1001.2_armhf.deb ../linux-image-3.2.0-1001-imx6-sabre_3.2.0-1001.2_armhf.deb ../nic-shared-modules-3.2.0-1001-imx6-sabre-di_3.2.0-1001.2_armhf.udeb [14:00] ../kernel-image-3.2.0-1001-imx6-sabre-di_3.2.0-1001.2_armhf.udeb ../linux-headers-3.2.0-1001-imx6-sabre_3.2.0-1001.2_armhf.deb ../mouse-modules-3.2.0-1001-imx6-sabre-di_3.2.0-1001.2_armhf.udeb ../storage-core-modules-3.2.0-1001-imx6-sabre-di_3.2.0-1001.2_armhf.udeb [14:00] :D [14:00] * ogra_ really loves that he can cross build a fully packaged kernel in 4min now :) [14:00] it doesnt build manyu udebs though [14:01] infinity, want it ? or do you build yourself anyway ? [14:03] ogra_: I haven't built it yet, no, I'm happy to trust your binaries, if you want to toss them somewhere for me. [14:03] * ogra_ pushes to preople.c.c [14:16] infinity, http://people.canonical.com/~ogra/mx6/ [14:18] oh, nice, mx6 uses 5V 4A, i can actually use my panda PSU [14:27] ogra_: crossbuilding just u/zImage or a real package? [14:30] LetoThe2nd, the whole package ;) [14:30] and all its udebs [14:30] and headers etc [14:30] ogra_: mind sharing the procedure? [14:30] make deb-pkg is broken :( [14:31] jsut getting into rt-testing the omap4 and that could come in handy :) [14:31] i mount an 8G tmpfs, unpack the source package in there and then run: [14:31] DEB_BUILD_OPTIONS=parallel=8 CROSS_COMPILE=arm-linux-gnueabihf- dpkg-buildpackage -b -aarmhf [14:32] inside the source folder i assume? [14:32] yep [14:32] requires a debian patched kernel, i'd guess? [14:32] at least a debian dir, yeah [14:33] *notes* [14:55] LOL [14:55] that shipped microSD image for the mx6 is awesome [14:56] i specifically like /viminfo and /session.vim === zyga is now known as zya-afk [14:58] haha [14:58] and /root/.bash_history tells you how to play big_buck_bunny on it [16:13] ogra_: Is this a publicly available platform or is it still early? [16:13] GrueMaster, thats just an mx6 board someone handed to me in boston [16:14] Ah. [16:14] it comes with a preinstalled oneiric linaro microSd in the slot [16:14] heh [16:14] armel indeed :( [16:14] which is bad since it ships all the binardy drivers as debs in /root ... [16:15] I fount the iMX6 dev boards on Freescale's website, but no info or pics. Just basic info and huge price tage. [16:15] s/tage/tag [16:15] well, quad core with sata [16:15] no idea what they cost [16:15] :D [16:15] The "cheapest" I see is $399 USD [16:16] So ~1.50 Euro. [16:16] ogra_: the weird thing with the flash-kernel hook script is that it always expect to set the ROOT param at the initramfs [16:16] (note price adjusted for sarcastic effect). [16:17] if Bootloader-sets-root is set to yes, it'll force it anyway expecting the parameter from the bootloader to be wrong [16:17] rsalveti, even if the confi g option is set differently ? [16:17] if it's set to no, it'll provide one anyway [16:17] yup [16:17] ogra_: http://paste.ubuntu.com/1138037/ [16:17] right. yes should make it ignore all root search functions [16:17] eek ! [16:18] that definitely needs fixing [16:18] so basically, with flash-kernel, there's no way to use the root parameter from the bootloader [16:19] yes, i plan hanging that by adding a function that either reads a var or determies it from the current list of mounts [16:19] *changing [16:19] not hanging :P [16:19] sure, but we need to deal with this use case as well [16:19] in any case line 9 and 10 are horridly wrong [16:19] guess the variable Bootloader-sets-root is used wrongly here [16:20] just remove 6-10 ? [16:20] we could have one option to force the initrd to overwrite the bootloader cmdline [16:20] not in case of the official and supported platforms for ubuntu [16:20] but in case there's no way to chagne the bootloader settings [16:20] the official and supported platforms in ubuntu will have a proper config already [16:20] just thinking that this would need to land at debian at some point [16:21] yeah [16:21] flash-kernel-installer will create it [16:22] actually, officially we don't need to use this hook at ubuntu [16:22] * ogra_ really doesnt get that assumption of root=/dev/ram [16:22] but it'd be nice to get it fixed anyway [16:22] ogra_: in case the bootloader hardcode the root argument [16:22] for some weird and bizarre values :-) [16:22] and ? [16:23] if the bootloader hardcodes /dev/ram as root= something went seriously wrong way before flash-kernel [16:23] you still want to boot your distro, pointing to a different rootfs [16:23] and f-k shouldnt be the one working around this [16:23] sure, but one workaround, and probably what was done initially at flash-kernel, is to fix that at the initrd level [16:23] which is just wrong [16:23] not that sure [16:24] hardcoding your root= line in an initramfs is plainly wrong [16:25] if you actually *want* this and set the config to do it, thats fine, but it cant be the default [16:25] yup, we should probably just use another variable [16:25] and if your installer did the right stuff, you will have a bootloader congif with either root=UUID= or root=/dev/whatever1 [16:25] Bootloader-sets-root: (required) when "yes" indicates that the bootloader passes a root= value to the kernel and that this should be overriden in the initrd; when "no", flash-kernel only sets a default value for the root device, which allows end-users to pass root= to the kernel [16:26] Found it. Expensive little beast. http://boundarydevices.com/products/sabre-lite-imx6-sbc/ [16:26] Cost will be $199 in Production (October 2012) [16:26] $299 pre-production, $199 production (~10/2012) [16:26] rsalveti, err, wheer is that from ? [16:27] oh, wow [16:27] ogra_: README :-) [16:27] i have read the README x times now [16:27] i never noticed the "and that this should be [16:27] overriden in the initrd" [16:28] so yeah, definitely wrong [16:28] the initrd cant override, thats total nonsense [16:28] not for debian I'd guess [16:28] then we'd probably need to handle it differently here [16:28] yes [16:28] probably by creating another option, or by just skipping in case it's ubuntu [16:29] i fear we will end up with a lot of diversion from debian again anyway [16:29] like Trust-Bootloader-root :-) [16:29] so i dont mind mangling the "yes" case to do the right thing [16:29] yeah, let me open a bug at debian about that [16:30] heh [16:30] let me just grab some food first [16:30] lunchtime [16:30] i doubt you will get any positive feedback :) [21:23] just fyi, i need all comments posted on omap5 wishlist by COB friday [22:32] infinity, FYI building linux-ti-omap4 on the mx6 takes 100min (i left it doing three test runs, one with parallel=8 which intrestingly took 1min longer than without)... on launchpad the saem is listed with 4h+ atm [22:32] *same [22:38] ogra_: Righ, so vaguely half the time with twice the cores. That's not unexpected for well-multithreaded builds. [22:38] ogra_: (Which is why I'd prefer people stop using kernel builds as build benchmarks, unless that's the only thing we ever build) [22:39] yeah, what surprised me was that the build actually used all cfour cores regardless [22:39] "regardless"? [22:41] well, even with DEB_BUILD_OPTIONS=parallel=8 which i thought might speed it up (two threads per core should be possible) the build didnt make a difference to not setting DEB_BUILD_OPTIONS [22:41] Two threads per core definitely won't speed anything up. :P [22:41] well, it actually delayed it by 60sec :) [22:41] not significant [22:42] Yeah, cause you cause more I/O contention. [22:42] still, i thought if i dont define parallel i would have expected to build single core [22:43] Nope, cause the kernel rules file is tricky. [22:43] ah, it does checks ? [22:43] If you define parallel=, it uses what you ask for, but if you don't, it uses $(getconf _NPROCESSORS_ONLN) [22:43] aha [22:43] so thats package specific, k [22:43] Yeah. [22:44] well, at least we know it can build a kernel in half the time a panda can :) [22:44] if i find some spare time i want to try a livefs build tomorrow ... that should really fly on 60MB/s [22:45] i sadly cant get cooloney'S kernel to boot ... [22:45] i suspect the package should ship devicetree files somewhere but i cant find any