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