**** BEGIN LOGGING AT Fri Aug 10 02:59:59 2012 Aug 10 08:02:48 I used the ubuntu 12.04 preinstalled omap4 linux image for the Pandaboard ES and after installing I try to install the proprietary graphics driver and it bombs out saying "SystemError: E:Unable to correct problems, you have held broken packages." Any way to fix this? Aug 10 08:57:33 I'm experimenting with putting together a dummy debian package on an intel system. I call "dpkg-buildpackage -aarmel -b -us -uc -nc" which works perfectly. However if I call "dpkg-buildpackage -aarmhf -b -us -uc -nc" dh binary just returns without any errors but it does absolutely nothing and hence no package. Aug 10 08:58:30 do you have the armhf cross toolchain installed ? Aug 10 08:58:42 The package is debhelper based, and rules does not contain anything except a override_dh_auto_install. It never calls this in the armhf one. Aug 10 08:59:04 ogra_: Yes I believe so Aug 10 08:59:57 cooloney_, well, i'm just using the shipped SD card and replace uImage after i rolled a package from your git tree, i was assuming this would work, butu apparently the kernel misses DT entries Aug 10 09:00:18 (at least it complains about DT stuff) Aug 10 09:00:38 Error: unrecognized/unsupported machine ID (r1 = 0x00000eb9). Aug 10 09:00:40 Available machine support: Aug 10 09:00:50 ID (hex) NAME Aug 10 09:00:59 ffffffff Freescale i.MX6 Quad (Device Tree) Aug 10 09:01:01 ogra_: I have armhf gcc, g++ and thus libc, libstc++, binutils and so on Aug 10 09:01:03 cooloney_, ^^^ Aug 10 09:01:33 sveinse, and the package has an entry for armhf in debian/control as well ? Aug 10 09:01:47 ogra_: yeah, it uses DT by default. i grab linaro image here http://snapshots.linaro.org/precise/pre-built/lt-mx6/236/ Aug 10 09:02:03 well, i want tzo use plain ubuntu images ... Aug 10 09:02:21 the userspace i have is fine with the kernel from the shipped SD ... Aug 10 09:02:26 ogra_. /me embarrassed. You're right. It said armel.... Thanks Aug 10 09:02:31 ogra_: after booting it up, i replace the kernel with my own built from the git tree Aug 10 09:02:40 i just dont seem to be able to replace the shipped one with it Aug 10 09:03:37 what mkimage command do you use ? probably i got the adresses wrong (though i picked them from the shipped kernel, they should work) Aug 10 09:04:30 mkimage -A arm -O linux -T kernel -C none -a $ADDR -e $ADDR -n "Ubuntu Kernel @$ADDR" -d $INPUT $OUTPUT Aug 10 09:04:37 haha Aug 10 09:04:39 the $ADDR should be 0x10008000 Aug 10 09:04:44 ah, k Aug 10 09:07:52 I have a somewhat hard time reading gcc specs; what is the default CFLAGS for armhf? Aug 10 09:09:14 I try to cross compile x-loader and I get x-load/bu/cpu/omap3/start.S:1:0: sorry, unimplemented: -mfloat-abi=hard and VFP. But I guess you don't use x-load anymore anyways... Aug 10 09:09:23 cooloney_, still: Error: unrecognized/unsupported machine ID (r1 = 0x00000eb9). Aug 10 09:09:37 cooloney_, right after "Starting kernel ..." Aug 10 09:11:05 cooloney_, http://paste.ubuntu.com/1139260/ thats the complete boot log Aug 10 09:12:32 sveinse, from what I understand x-load is still used, just as MLO (but I might be wrong I don't own any OMAP device" Aug 10 09:12:35 ) Aug 10 09:12:37 ogra_: do you have board.dtb in your mmcblk0p2? Aug 10 09:12:49 and what's your boot.scr Aug 10 09:13:49 the boot.scr is the same modulo a changed root= Aug 10 09:15:06 ogra_: http://paste.ubuntu.com/1139265/, this is my boot.scr Aug 10 09:15:47 ogra_: maybe you need my uImage, boot.scr and board.dtb Aug 10 09:16:31 well, i re-used the shipped boot.scr (6q_bootscript) ... that doesnt even define a .dtb Aug 10 09:16:53 there is a subdir in /boot on the card that carries one though Aug 10 09:17:45 cooloney_, where does the dtb come from ? i would have expected to find it in the package i built somewhere Aug 10 09:19:59 ogra@sabre:~$ dpkg -c linux-image-3.2.0-1001-imx6-sabre_3.2.0-1001.2_armhf.deb|grep dtb Aug 10 09:19:59 ogra@sabre:~$ Aug 10 09:21:49 smashpot mcgoo Aug 10 09:22:16 ogra_: actually i get the .dtb file from linaro image, i didn't change it Aug 10 09:22:31 i take it proprietary powervr sgx is just broken right? Aug 10 09:22:45 electronics-cat, works fine here ... Aug 10 09:23:22 (at least using the integrated one (i.e. the one that you get offered via GUI right after install)) Aug 10 09:23:59 can you tell me what image you used, cause I can't get that to install at all Aug 10 09:24:13 cooloney_, hmm, then let me try your boot.scr Aug 10 09:24:50 electronics-cat, the default ubuntu image for 12.04 ... the hardware manager app will pop up automatically after install and offer you the PVR driver Aug 10 09:24:58 ogra_: need i sent you the board.dtb file? Aug 10 09:25:27 cooloney_, well, the SD ships three, i guess if i define it in boot.scr one might work :) Aug 10 09:25:35 ogra_: yeah it offers me the same thing, except when i try to do it, it says "SystemError: E:Unable to correct problems, you have held broken packages." after a while Aug 10 09:26:01 electronics-cat, that looks more like you messed up your package manager before ... Aug 10 09:26:14 ogra_: great Aug 10 09:26:14 ive tried it twice on a fresh install Aug 10 09:26:32 you said 12.04, right ? Aug 10 09:26:35 not 12.10 Aug 10 09:27:17 ubuntu-120.04-preinstalled-desktop-armhf+omap4.img Aug 10 09:27:39 12.04 Aug 10 09:27:41 and you did no fiddling, adding of any PPAs etc ? Aug 10 09:27:53 absolutely NO fiddling at all. Aug 10 09:28:27 very strange, these images get massive testing Aug 10 09:29:18 cooloney_, hah, wow, of i click on "download as text" for your paste i get "DatabaseError: database disk image is malformed" Aug 10 09:29:24 fun Aug 10 09:29:38 * ogra_ copy/pastes line by line from the html page Aug 10 09:31:02 ogra_: hah, you know i just sent your a virus in that page Aug 10 09:32:33 hehe ... Aug 10 09:54:35 When running armhf ubuntu, what must be armhf? I presume the bootloader can be armel, but the kernel must be armhf, right? Or will the interface between uboot and kernel fail if the eabi dont match up? Aug 10 09:55:00 only the userspace needs to be hf Aug 10 09:55:33 oh, I thought the kernel had to be armhf due to the userspace-kernel interface Aug 10 09:56:23 cooloney_, k, none of my dtb files work, gimme yours :) Aug 10 09:56:44 ogra_: ok, will email you soon Aug 10 09:56:51 thx Aug 10 09:57:03 I have to admit not having total overview of what the specific differences between armel and armhf are Aug 10 10:03:33 If the kernel is agnostic to armel and armhf, can a system have both armel and armhf installed via multiarch? Aug 10 10:23:23 hmpf, so following the linaro instructions to reflash seems to have bricked the board Aug 10 10:26:56 yay, bricking! Aug 10 11:06:30 ogra_: do you have any trick to speed up 'sbuild-update --keygen' Aug 10 11:06:47 Not enough random bytes available. Please do some other work to give Aug 10 11:06:48 the OS a chance to collect more entropy! (Need 300 more bytes) Aug 10 11:12:10 cooloney_, never used sbuild Aug 10 11:12:15 better ask infinity Aug 10 11:12:37 * cooloney_ faint Aug 10 11:13:09 ogra_: i assume you asked me never use sbuild, hah Aug 10 11:14:56 cooloney_, well, i usually just have a tarball with a chroot and manually build the package for a testbuild Aug 10 11:15:04 (in there indeed) Aug 10 11:15:15 i dont need any fancy buildd setup for that :) Aug 10 11:15:46 * ogra_ curses, so the only way to recover the mx6 is a windows tool Aug 10 11:15:58 i dont have any windows copy around :( Aug 10 11:16:20 and while it runs under wine it doesnt find the usb port Aug 10 11:23:14 ogra_: oh, you broke you mx6 board? Aug 10 11:23:33 i followed the linaro wiki to update the NOR bootloader Aug 10 11:23:42 ogra_: me either, i have an broken one on the desk Aug 10 11:23:48 and after reboot the board is completely dead Aug 10 11:24:06 yeah, i think some boards has problem to access SD card. Aug 10 11:24:20 there is a windows tool that can flash via USB to recover Aug 10 11:24:26 even I booted it up from MicroSD, I cann't read/write SD card from U-boot Aug 10 11:24:42 i cant boot from anything anymore Aug 10 11:25:00 ogra_: yeah, i just gave up since no Windows PC and borrowed one board from Eric Aug 10 11:25:18 hmm, there are two dip switches on the board Aug 10 11:25:30 i wonder if you can influence the boot process somehow with them Aug 10 11:25:43 heh, seems you can Aug 10 11:26:38 ogra_: i think fsl will try to boot SD card directly in their new board. Aug 10 11:27:01 ogra_: but for our broken board, have to use that windows tool to recover Aug 10 13:42:58 sigh, finally fond an old win98 cd ... installation takes hours ! Aug 10 13:49:30 ogra_: What on earth are you installing Win98 for? Aug 10 13:49:55 infinity, to unbrick my mx6 Aug 10 13:50:34 infinity, i made the mistake to follow the linaro instructions to update u-boot ... even though i only copy/pasted in the u-boot shell and it all seemed to work, the board is dead now Aug 10 13:50:59 and the tool FLS offers to unbrick via OTG is a windows tool Aug 10 13:51:15 ogra_: Sure, I get that. It Aug 10 13:51:23 i couldnt get the OTG port recognized under wine so i'm trying a vbox install now Aug 10 13:51:25 It's specifically "why Win98" that I was asking. :P Aug 10 13:51:26 why not xp, or something a little more modern that most people have on some machine tucked away in a corner Aug 10 13:51:44 infinity, heh I got you, I was thinking the same thing :p Aug 10 13:51:48 Then again, Germans are known for their masochism. Aug 10 13:51:49 becuase the 98 CD is the only usable win media i found in my big brown box Aug 10 13:52:19 all PCs i bought the last 15 years were whitebox products Aug 10 13:52:29 so i never got any win licenses or media Aug 10 13:52:31 ogra_: I have several legit licenses for NT4/2K/XP/7, if you ever actually need a legit NT install sometime. Aug 10 13:52:56 * ogra_ had a hard time even finding a machine with usable CD rom over here Aug 10 13:53:28 well, as long as vbox can natively work with USB i should be good now Aug 10 13:54:11 though i might lose my left leg ... the laptop running vbox is pretty old and starts getting quite hot already Aug 10 13:54:14 Ugh. I must need to go back to bed. Aug 10 13:54:47 I just typed by 80 bazillion character GPG passphrase into a sudo prompt SIX TIMES before I realised it wanted my password, not my passphrase. :P Aug 10 13:55:06 lucky you didnt type it into IRC Aug 10 13:55:17 I'm tired, not mentally deficient. Aug 10 13:55:33 * ogra_ twiddles thumbs watching a drum and little drumsticks on the screen Aug 10 13:56:40 last time I tried to install windows in a vm it didn't work so well :( Aug 10 13:57:02 works fine apparently ... but its ultra slow Aug 10 13:57:11 apparently 1.7GHz was far too much for win3.1 to handle Aug 10 13:57:41 3.1 from virtual floppies ? Aug 10 13:57:50 yeah Aug 10 13:57:56 heh Aug 10 13:59:06 * ogra_ likes how it says "less than a minute" since 20min Aug 10 13:59:23 heh Aug 10 13:59:37 that takes me back to running on real hardware when win9x was current :p Aug 10 13:59:52 it will take 1 microsoft minute Aug 10 14:00:01 heh Aug 10 14:00:17 at least it has an innovative 640x480 splashscreen Aug 10 14:00:35 :D Aug 10 14:00:50 * lilstevie wonders how much fun it would be to install win98 natively on his current hardware Aug 10 14:01:16 27" monitor at 2560*1440 Aug 10 14:01:29 argh, i thought i was done ... Aug 10 14:01:41 but after first start it first wants to install drivers Aug 10 14:01:49 ah yeah, that Aug 10 14:01:51 * ogra_ totally forgot what a pain windows is Aug 10 14:02:06 hey, at least modern windows is a little less painful Aug 10 14:02:10 but my little fried, the drum with sticks is back at least Aug 10 14:02:54 who ported tianocore uefi to the beagle btw Aug 10 14:03:19 * ogra_ has no idea Aug 10 14:05:00 hm Aug 10 14:20:03 grrr, i forgot that adding a dns server needs a restart Aug 10 14:24:46 fun Aug 10 16:03:28 What is the relationship between plymouth and libpango ? From what I see, plymouth does not depend on libpango. However, pango files are indeed used by plymouth... Aug 10 16:05:44 text rendering Aug 10 16:07:32 ogra_ , yes. For some reason my lacks libpango and hence update-initramfs fails. plymouth wants to read libpango files and croaks. Isn't this an error in the deps? Aug 10 16:08:10 no, thats the opposite, it prevents you from a bug :) Aug 10 16:08:34 copy_exec in the plymouth hook is supposed to pull all libs in a binary is linked against Aug 10 16:08:55 if it cant it has to fail, else you would be left with a non-functional initrd Aug 10 16:12:05 ogra_ maybe I'm getting this all wrong, but looking at /usr/share/initramfs-tools/hooks/plymouth it refers at the bottom to pango, right. But my system has no libpango since noone depends on it. Aug 10 16:12:20 plymouth does Aug 10 16:14:15 uhm. not immediate/direct dependency. neither in natty nor in precise (armel) afaics. I haven't searched the dependency tree (deps of deps) thou Aug 10 16:14:25 I hope I'm wrong... Aug 10 16:18:30 ogra@anubis:~/Devel/packages/flash-kernel-3.0~rc.4ubuntu18$ apt-cache rdepends libpango1.0-0|grep plymouth Aug 10 16:18:30 plymouth-x11 Aug 10 16:18:30 plymouth-label Aug 10 16:23:33 ogra_, But that's not plymouth... Point is I'm making a theme and it depends on plymouth (only for now). Which in turn does not depend on pango even if it does use it. Now, I see that common themes usually require plymouth-label which in turn pulls in libpango. I still think this to be a bug Aug 10 16:24:03 * ogra_ thinks its a feature Aug 10 16:24:54 well Depends on plymouth in incomplete and hereby disobeyes the Ubuntu Policy manual... Aug 10 16:25:09 ?? Aug 10 16:25:44 initramfs-tools hooks dont obey to a packaging manual Aug 10 16:25:47 they dont have to Aug 10 16:27:21 Isn't the point of Depends to actually tell which packages I need to make use of this package?? "The Depends field should be used if the depended-on package is required for the depending package to provide a significant amount of functionality." Aug 10 16:27:43 plymouth is broken unless libpango is installed. Aug 10 16:28:36 Well, anyways. I can add plymouth-label as a dependency to my theme (even though that is not true) just to allow update-initramfs to complete Aug 10 16:31:18 ogra_: No initramfs-tools hooks dont need to obey to the manual in itself, but the package system does, right? I mean the whole distribution is built upon sane dependencies Aug 10 16:32:27 Recommends: plymouth-theme-ubuntu-text | plymouth-theme Aug 10 16:32:38 recommends are installed by default in ubuntu Aug 10 16:37:52 Ubuntu policy manual: ยง7.2 "Recommends: This declares a strong, but not absolute, dependency.". When a package become unusable because of a missing recommends package is rather stronger than recommends I'd say. But ok. I give. This is the most awkward usage of dependencies I've seen in a while. Aug 10 16:39:52 sveinse: If the initramfs-tools hook unconditionally copies libpango without a hard dependency, that's a bug, yes. Aug 10 16:40:21 infinity: It does Aug 10 16:40:40 sveinse: Then please file the bug (if it's not already filed). Aug 10 16:41:09 thanks, will to (tomorrow) Aug 10 16:47:27 but I see ogra_'s point, if a theme requires libpango and its not there, its much better to fail during update-initramfs rather than in boot because of missing so's. Aug 10 16:48:07 sveinse: Sure, but either plymouth needs a dep on libpango, or how this all works needs to be made smarter. Aug 10 16:48:46 sveinse: Being able to install plymouth but have the initramfs-hook fail is broken behaviour. Aug 10 16:50:19 infinity: My initial proposal was to test for libpango presence in initramfs-tools hook and include it conditionally. I have a theme that do not need pango, and hence that would be a better solution for me. Aug 10 16:50:49 The other is to simply depend on libpango from plymouth as you said Aug 10 16:52:26 Reading the hook I think it comes from an assumption that a theme always depends on libpango and hence it's present when update is run Aug 10 16:58:43 Another related thing ogra_: It seems /lib/plymouth/renderers/vga16fb.so is missing from the armhf packages, while present on armel (which also croaks update-initramfs). Is this is bug as well? Aug 10 16:59:40 no idea, file it and someone will look :) Aug 10 16:59:48 ok, thansk Aug 10 16:59:51 *thanks Aug 10 17:05:35 rsalveti, poke Aug 10 17:05:54 ogra_: hey Aug 10 17:06:09 rsalveti, do the ubuntu linaro images ship PVR ? Aug 10 17:06:28 (the ready made img's not what i build at home with l-m-c) Aug 10 17:06:36 ogra_: yup Aug 10 17:06:51 hmm, so we could do that as well in ubuntu i assume Aug 10 17:06:54 ogra_: stop updatting flash-kernel! Aug 10 17:06:56 hahah Aug 10 17:07:01 I sent a better patch yesterday Aug 10 17:07:04 lol, tell rbasak Aug 10 17:07:05 need to rebase it again Aug 10 17:07:15 he always complains if i break his installs !!! Aug 10 17:07:27 users ... Aug 10 17:07:30 *g* Aug 10 17:07:44 lol Aug 10 17:08:11 ogra_: I think the license can be an issue on a few places Aug 10 17:08:59 rsalveti, well, unity-2d is considered dead now Aug 10 17:09:07 yeah, I knoe Aug 10 17:09:08 know Aug 10 17:09:14 llvmpipe does apparently not work on GLES yet Aug 10 17:09:30 how could you know, decision was apparently just made :) Aug 10 17:09:44 well, it was dead already, wasn't it? Aug 10 17:09:44 * ogra_ wants rsalveti's crystal ball ! Aug 10 17:09:50 it was still around, but not maintained Aug 10 17:09:57 it wasnt clear if we drop it in quantal already Aug 10 17:09:57 or you mean it's not going to be available anymore? Aug 10 17:10:02 right Aug 10 17:10:16 all 2D stuff will be gone from the desktop Aug 10 17:10:42 ogra_, since when is u-2d considered dead? Aug 10 17:10:50 janimo, UDS Aug 10 17:11:03 ogra_: then we might need to include a way to install the proprietary drivers from the installer Aug 10 17:11:08 so u-3d will be on all CDs? Aug 10 17:11:15 but back then it still sounded like it would stay around on the images in maintenance mode Aug 10 17:11:25 I thought so far that u-2d would eventually replace the compiz based one :) Aug 10 17:11:29 which was apparently just decided to not happen Aug 10 17:11:41 janimo, we all hoped that :) Aug 10 17:12:08 link to ml discussion or irclogs? I did not follow much of desktop recently Aug 10 17:12:15 besides UDS talks I mean Aug 10 17:12:19 rsalveti, well, if you could ship them, we can as well, we just need to make sure ubiquity still works in framebuffer, i dont see a way to boot a live image and use dkms Aug 10 17:12:37 janimo, nope, there were no discussions at all apart from UDS :/ Aug 10 17:13:11 ok, since you said above 'was just decided' I though very recently Aug 10 17:13:15 hm, I don't see why we'd be using gles from the start Aug 10 17:13:20 gles/opengle Aug 10 17:13:41 I we had plans to put wayland right at initrd :-) Aug 10 17:13:45 janimo, yes, the actual decision to drop it asap was made just now Aug 10 17:13:50 but that was just one part afaik Aug 10 17:14:06 i dont see wayland as the default in quantal Aug 10 17:14:13 because of the qt uncertainty or just carrying two similar codebases is not worth it Aug 10 17:14:17 nor do i see space on the images to ship it Aug 10 17:14:26 (in parallel with xorg) Aug 10 17:15:18 * ogra_ hugs jcrigby ... thanks for the upload ! Aug 10 17:15:22 so framebuffer will still be an option for the installer, right? Aug 10 17:15:33 rsalveti, i hope so Aug 10 17:15:49 ogra_: bug 1034734, a new debdiff for you sr Aug 10 17:15:49 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 Aug 10 17:15:53 uness they decide the slideshow needs to be in clutter or some other evil thing Aug 10 17:15:57 ogra_: please review it :-) Aug 10 17:16:15 ogra_: lol Aug 10 17:16:19 would not be surprised Aug 10 17:16:34 boot log in 3d, fancy installer Aug 10 17:16:36 that's the future Aug 10 17:16:44 :-) Aug 10 17:16:47 rsalveti, hmm, thats the third place we set FLASH_KERNEL_SKIP now Aug 10 17:17:01 i wonder if we cant do it more globally Aug 10 17:17:02 ogra_: yup Aug 10 17:17:15 ogra_: well, this is a hook for initramfs Aug 10 17:17:19 like in the flash-kernel script itself probably :) Aug 10 17:17:42 so it's not actually running flash-kernel Aug 10 17:17:47 (where we did it in the past) Aug 10 17:18:00 but more like, please don't mess with my system in case I don't want to run flash-kernel Aug 10 17:18:01 :-) Aug 10 17:18:31 but I understood why we had 2 options yesterday on that crazy if block Aug 10 17:18:41 yep Aug 10 17:18:42 one is setting the root to overwrite the one provided by the kernel Aug 10 17:18:48 and the other just to provide a default Aug 10 17:18:57 yeah, and we want the latter Aug 10 17:19:02 yup Aug 10 17:19:10 so if we keep as 'no', it'll behave as we want Aug 10 17:19:26 we will default to yes though Aug 10 17:19:31 why? Aug 10 17:19:39 as soon as i changed f-k-i to create a proper default config Aug 10 17:19:43 the yes is to replace the rootfs parameter from the boot loader Aug 10 17:19:48 there's no need to do it Aug 10 17:19:53 because by default ubuntu sets root=UUID= on the cmdline Aug 10 17:20:03 we dont want to have an initrd override that Aug 10 17:20:05 sure, and that's why you actually want a no here Aug 10 17:20:16 no, we want a yes :) Aug 10 17:20:22 no means it'll set a default root argument at the initramfs, that will not replace the one from the kernel Aug 10 17:20:29 if yes, then the bootloader sets the root parameter Aug 10 17:20:35 no! Aug 10 17:20:35 :-) Aug 10 17:20:38 if no, flash-kernel tiresd to set it in initrd Aug 10 17:20:46 check the readme Aug 10 17:21:26 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. Aug 10 17:21:43 so 'no' is what we want at ubuntu Aug 10 17:22:04 and my patch fixes the behavior to match exactly as we need Aug 10 17:22:17 My god, that's an unintuitively-named option. Aug 10 17:22:30 infinity: exactly! Aug 10 17:22:31 ++ Aug 10 17:22:31 It should be "Initrd-overrides-root" Aug 10 17:22:57 talk to the linaro OCTO :P Aug 10 17:23:02 lool: ^ Aug 10 17:23:05 your fault Aug 10 17:23:09 :P Aug 10 17:23:14 its *all* his fault ! Aug 10 17:23:25 it's your baby, you created the new monster Aug 10 17:24:34 infinity: No, right now it's implemented with initrd, but with some boards it might set root in e.g. bootloader environment :-) Aug 10 17:24:51 rsalveti: ^ :-) Aug 10 17:25:10 exactly Aug 10 17:25:13 but here Aug 10 17:25:19 we have the bootloader setting the rootfs Aug 10 17:25:32 and we don't want that to be forced by the initramfs Aug 10 17:25:46 rsalveti: I've read the patch earlier today, but I didn't really see all the use cases for both adding the SKIP support (ok with that) *and* the other code changes Aug 10 17:26:02 rsalveti: Sure, so you want Blst: no Aug 10 17:26:06 one, without /etc/fstab Aug 10 17:26:18 currently if you don't have a /etc/fstab it'll break and explode to the user Aug 10 17:26:28 rsalveti: not having a fstab is bad; why not have one? Aug 10 17:26:34 lool: chroot? Aug 10 17:26:49 so you disable flash-kernel until you have one Aug 10 17:26:58 why do you need flash-kernel in a chroot? :-) Aug 10 17:27:01 why disabling flash-kernel? Aug 10 17:27:06 well, not sure, why not? Aug 10 17:27:30 this I got because of the way linaro-media-create runs Aug 10 17:27:39 it sets the /etc/fstab as the last step in the game Aug 10 17:27:45 can be changed, but where I got the issue Aug 10 17:27:51 rsalveti, if you dont disable it it will try to write to the defined device Aug 10 17:27:58 still, it should deal with the situation where no rootfs can be found at /etc/fstab Aug 10 17:28:18 breaking and asking for user input is bad Aug 10 17:28:44 rsalveti: I don't like the user input thing, I agree, it's historical, but breaking the install by default kind of make sense to me Aug 10 17:28:47 *makes Aug 10 17:28:53 rather than silently resulting in an unbootable system Aug 10 17:29:19 lool: that's why I'm now breaking in case we have a "yes" and we don't have a rootfs Aug 10 17:29:31 if we have a "no" we don't actually care Aug 10 17:29:34 rsalveti: l-m-c should have a step to install packages and a separate one to "make the system bootable", just like during an install Aug 10 17:30:04 lool, will you be at UDS btw ? Aug 10 17:30:33 we have patches piling up again and i think we shoudl sit down and look whats acceptable for debian and what needs to stay ubuntu only Aug 10 17:30:33 rsalveti: One thing which might not be obvious: Blsr is just a cosmetic thing for how the root is set by f-k, in *both* cases f-k needs to know the root dev Aug 10 17:30:38 ogra_: which one? Aug 10 17:30:44 next one Aug 10 17:30:48 ogra_: I'll be in Copenhagen Aug 10 17:30:53 great Aug 10 17:30:55 lool: well, it doesn't need to know, that's the thing Aug 10 17:30:59 lool: not at ubuntu at least Aug 10 17:31:14 lool, so mark 1h for f-k discussion over a beer or wine then ;) Aug 10 17:31:50 if we're dealing with the rootfs argument by ourself, we don't want flash-kernel to mess with it Aug 10 17:32:06 it tries to provide a default one, but if it can't find a rootfs, it'll just skip it Aug 10 17:32:14 that's why I changed at my patch Aug 10 17:32:19 *what Aug 10 17:32:58 I don't know why the decision was made to always have a working rootfs at initrd Aug 10 17:33:09 I know that the use case 'yes' here is valid Aug 10 17:33:33 rsalveti: I'm not sure it's a good direction; f-k knows a bit too little about the boot details at the moment, moving towards it knowing less for certain devices isn't great :-/ Aug 10 17:33:35 but still, you're forcing the rootfs argument to the user Aug 10 17:33:46 lool: why not? Aug 10 17:33:55 rsalveti: the system should know about the boot and root devices Aug 10 17:33:55 that's just the rootfs argument Aug 10 17:34:19 rsalveti: I don't undertsand "you're forcing the rootfs argument to the user"? Aug 10 17:34:34 ogra_: if I do that we're going to drink wine or beer for one hour ;-) Aug 10 17:34:39 well, by forcing a rootfs argument at the initrd, that also replaces the one provided by the kernel Aug 10 17:34:50 rsalveti: It's not necessarily forced Aug 10 17:34:53 it is Aug 10 17:34:55 rsalveti: one code path only sets a default Aug 10 17:35:09 just in case it's a 'no' Aug 10 17:35:10 rsalveti: that's the point of Blsr Aug 10 17:35:12 rsalveti: Yes Aug 10 17:35:39 rsalveti: The reason this exists is because some bootloaders hardcode it without f-k being able to update this Aug 10 17:35:58 sure, but here you're assuming you know which bootloader is used Aug 10 17:36:01 e.g. some systems hardcode root=/dev/ram/ram0, others hardcode /dev/hda1 when you want /dev/sda1 or /dev/md0 etc. Aug 10 17:36:05 and that can be updated Aug 10 17:36:15 *it can't Aug 10 17:36:30 rsalveti: I'm explaining where the feature comes from Aug 10 17:36:45 I hate this idea of the system setting everything up for the user, and forcing him to use such options Aug 10 17:36:54 if he wants to change the rootfs, it'll be a huge pain Aug 10 17:37:03 rsalveti: Now, rather than always overriding the kernel root=, it was considered a good idea to only override it if it's hardcoded Aug 10 17:37:28 rsalveti: hold on Aug 10 17:37:35 rsalveti: I think you're jumping to conclusions Aug 10 17:38:01 no, it's just weird we're assuming that for a few devices the user will not be able to update the bootloader Aug 10 17:38:05 or the bootloader arguments Aug 10 17:38:17 Now that I've explained where this comes from, when I moved this option from an "if" in the code to the database, I also looked at the code and tried to make everything as automatic and config-less as possible Aug 10 17:38:32 I'm sure there are advanced use cases that were never well supported and that we should try to support Aug 10 17:38:47 But I'd like to support these use cases in a solid and maintainable (upgradeable) way Aug 10 17:39:21 lool, i think if f-k is configured to not handle root= it should simply not handle it at all Aug 10 17:39:24 rsalveti: It's exactly that: for certain devices, we can't update the bootloader settings or the bootloader Aug 10 17:39:27 I understand, but it can be quite confusing as well Aug 10 17:39:39 it's hard for the user to understand that the initrd is replacing his own kernel options Aug 10 17:39:43 rsalveti: it might be because it's too risky to do so, because the sources are ancient / hard to build / missing, or because the feature is lacking Aug 10 17:39:48 the current behavior makes it still fiddle with it Aug 10 17:39:51 and that's not explicitly happening Aug 10 17:40:23 rsalveti: I understand, this is a historical implementation which has some advantages, let's think of how we can provide alternate options? Aug 10 17:41:07 with the 'yes' path I'd be just happy if we had a *big* warning saying to the user that the system is now controlling the rootfs argument Aug 10 17:41:16 and for the 'no' case, please don't do anything :-) Aug 10 17:41:26 which is what we want at ubuntu Aug 10 17:41:39 rsalveti: I disagree Aug 10 17:41:51 I don't think we want to do nothing wiht Ubuntu Aug 10 17:41:58 we do :) Aug 10 17:42:06 we should speak of concrete system-wide use cases rather than just thinking at the f-k level Aug 10 17:42:24 at ubuntu we want a file to control the rootfs argument Aug 10 17:42:25 we want to put root=UUID= in place from f-k-i Aug 10 17:42:25 if you do nothing you end up with a kernel panic because no root= is set Aug 10 17:42:26 lool: For Ubuntu, hardcoding rootfs in an initrd is wrong, period. Distro initrds should be generic. Aug 10 17:42:30 as we always did Aug 10 17:42:31 rsalveti: Yup, that's valid Aug 10 17:42:35 in our case, it's the boot.src Aug 10 17:42:43 uEnv or similar Aug 10 17:42:48 lool: If I move my rootfs from one disk to another, and update my kernel cmdline, it should Just Work. Aug 10 17:42:55 infinity: generic distro initrds are just a NTH IMO Aug 10 17:43:05 we have them on x86 Aug 10 17:43:19 and i even can use my omap4 initrds on my ac100 Aug 10 17:43:20 I can give you higher priority features that are missing such as supporting multiple kernels Aug 10 17:43:28 We can and should have them anywhere where the bootloader can set the kernel cmdline. Aug 10 17:43:29 as long as i dont make use of modules Aug 10 17:44:01 initrd should be mostly generic Aug 10 17:44:09 and will be generic once we have a single zimage Aug 10 17:44:24 adding other options based on different systems, is wrong Aug 10 17:44:29 unless there's no way to support Aug 10 17:44:33 rsalveti: I don't mean generic across subarches (though that will be nice when subarches go away), I mean system-independant. Aug 10 17:44:46 and even with that, we should have a huge warning to the user Aug 10 17:44:54 Folks, I agree with your goals but I'll play devil's advocate: some Debian-supported devices have limited storage for the initrd and can only deal with MODULES=dep Aug 10 17:44:55 because it breaks the default logic from the initrd Aug 10 17:45:02 this makes the initrd non-generic Aug 10 17:45:06 An initrd generated on my Panda booting from /dev/sdb1 should work on another Panda booting from /dev/sda2. Aug 10 17:45:15 lool, some ubuntu ones too Aug 10 17:45:19 lool: That's subarch. Aug 10 17:45:30 lool: Maybe the word I want here is "portable", not "generic". Aug 10 17:45:44 Hardcoding filesystem localtion in an initrd breaks portability. Aug 10 17:45:57 location, too. Aug 10 17:45:57 ++ Aug 10 17:45:57 In any case, I'm happy to note down "We want initrd to be as generic as possible, if the boards allow" Aug 10 17:46:03 as a goal Aug 10 17:46:26 lool, no... "we dont want f-k to make any use of the initrd if we told it not to" Aug 10 17:46:45 with emphasis on "any" Aug 10 17:46:46 this is not a feature Aug 10 17:46:59 It's an anti-feature, which is even better. :P Aug 10 17:47:00 no, its a bug :) Aug 10 17:47:01 Less is more. Aug 10 17:47:13 at least the current behavior is Aug 10 17:47:14 please Aug 10 17:48:09 It's not flash-kernel's job to find the root filesystem, it's the initrd's job, in a generalised fashion. Yes, in weird corner cases where you MUST override the kernel cmdline, sure, having that option is cool. Aug 10 17:48:10 i agree that rsalveti shouldnt run f-k in a chroot but i also agree that f-k should mess with the initrd if the bootloader sets the root Aug 10 17:48:21 *shouldnt Aug 10 17:48:27 But it's by no means the default state of affairs. We trust out kernel cmdline, generally. Aug 10 17:48:31 infinity: GRUB knows my root device Aug 10 17:48:44 lool: Yes, GRUB is your bootloader, and it's setting the cmdline. Aug 10 17:48:47 GRUB sets my kernel cmdline Aug 10 17:48:47 boot.scr and uEnv.txt do too Aug 10 17:48:48 yes Aug 10 17:48:48 lool: f-k isn't a bootloader. Aug 10 17:48:58 No, but it also is in charge of making the system bootable Aug 10 17:49:18 it is in charge of putting the bits and pieces in the right places Aug 10 17:49:24 lool: And, hence, it should set bits for u-boot systems, and not hardcode the same in the initrd. Aug 10 17:49:38 and in case of f-k-i i agree its in charge of doing initial configuration Aug 10 17:49:57 infinity: Yes, I agree that we could have a more specialized / more clever approach on U-Boot systems Aug 10 17:50:05 it's painful though Aug 10 17:50:07 lool: Yes, I understand this can't work this way everywhere. That's no excuse for not doing it right where it can work. Aug 10 17:50:09 but I'd like us to move to that Aug 10 17:50:38 infinity: I'm not looking for excuses here, I'm explaining where the current implementation comes from Aug 10 17:50:54 I'm not saying we should keep it forever like this, I'm explaining why it's currently like this Aug 10 17:51:17 and trying to understand the use cases so that we have a design to handle them, rather than workarounds for the current limitations Aug 10 17:51:49 for instance, one thing which we could do is generate boot.scr or uEnv.txt with a root= in them, and have a f-k config file with a root fs override Aug 10 17:52:03 lool, thats the plan on my side Aug 10 17:52:04 or we could have a setting to ignore that the root device mentioned in fstab is missing Aug 10 17:52:15 the two ones I wanted to fix is, please don't stop to the user in case it can't find the rootfs while updating the initramfs, and the other is please don't do anything in case we have a 'no' here :-) Aug 10 17:52:20 rsalveti: I don't think it's a good idea not to have a fstab though Aug 10 17:52:25 and at ubuntu we'll mostly just support devices with a 'no' Aug 10 17:52:43 lool: Not having an fstab actually works perfectly fine, it's not required. Aug 10 17:52:48 rsalveti: So what's the scenario for updating the initramfs somewhere else? Aug 10 17:52:53 lool: And it's certainly not required to list / in fstab. Aug 10 17:52:55 lool, having /etc/default/flash-kernel carrying the distro defaults, if f-k runs we have a detection that merged root= with this and creates a preEnv.txt Aug 10 17:52:59 lool: so if for some reason, I install flash-kernel into a chroot, I can't update initramfs Aug 10 17:53:07 let's suppose I want to mount the sd card somewhere Aug 10 17:53:14 and change something, or even update the initrd Aug 10 17:53:15 I can't! Aug 10 17:53:29 infinity: An initrd shouldn't be required either, yet f-k assumes one right now Aug 10 17:53:34 because it'll break and warn me that it could not find the original rootfs device Aug 10 17:53:35 infinity: And you're not required to run a linux kernel either Aug 10 17:53:39 rsalveti, your chroot tool should set FLASH_KERNEL_SKIP Aug 10 17:53:47 in fact you could be booting Windows with flash-kernel, if you spend sufficient time porting it Aug 10 17:53:54 thats why we invented it Aug 10 17:53:57 ogra_: that's also what I added to the patch Aug 10 17:53:58 seriously, let's stick to the useful questions :-) Aug 10 17:54:23 lool: Erm. "Not relying on the contents of fstab" is perfectly reasonable and useful, unlike discussing booting Windows. :P Aug 10 17:54:35 but still, it should't break unless it's really needed Aug 10 17:54:40 unless we have a 'yes' Aug 10 17:54:52 rsalveti: So assuming you want to update the initrd on some other device, how would you set the target device? Aug 10 17:54:55 it should no-op actually Aug 10 17:54:58 mounting the sd card at a different machine and updating the initrd is a quite solid use case Aug 10 17:55:00 rsalveti: Would we need some env var to chose it? Aug 10 17:55:07 that the user shouldn't need to set any skip variable Aug 10 17:55:12 rsalveti: (For the case where some devices require a custom initrd) Aug 10 17:55:49 infinity: If we're designing a production system for end-users, it should have a fstab like standard system do Aug 10 17:55:52 lool: then it needs to be run at the device, or break to the user warning that the rootfs can't be found Aug 10 17:56:00 but not on all use cases Aug 10 17:56:03 that's what I'm saying Aug 10 17:56:07 that's needed to pickup mount options, for fsck etc. Aug 10 17:56:13 and that's what I changed at my patch :-) Aug 10 17:56:15 lool: The "standard system" doesn't rely on the fstab to set up the bootloader. Aug 10 17:56:32 lool: (By standard here, I mean "x86") Aug 10 17:56:47 * infinity shrugs. Aug 10 17:56:52 infinity: no but it relies on a fstab being present Aug 10 17:57:30 I've been pushing back against people who want to embed fstab snippets in initrds for other reasons, I'm irked to see it happen here. Aug 10 17:57:49 anyway, I don't think we need to spend out energy on the least useful case of supporting fstab-less systems; it's more important to fix the use case preventing e.g. Ricardo to create images Aug 10 17:58:14 This isn't about specialised devices or doing things between subarches, those are straw men. An initrd generated on omap4 should work on any machine with a matching kernel. Aug 10 17:58:19 infinity: Keep in mind it's historical; I'm happy if we implement ways to avoid it in the future Aug 10 17:58:23 lool: so please take my patch! :-) Aug 10 17:58:44 I think we should go into 2 steps here Aug 10 17:58:54 one is making sure we're not breaking anything with the current implementaiton Aug 10 17:59:03 and later fixing it properly, like not depending on fstab Aug 10 17:59:19 I think we shouldn't mix all problems in this IRC discussion, it's also getting close to diner for me (in fact I tried to run away an hour ago, but was pulled into another chat with Zach :-) Aug 10 17:59:26 but for ubuntu this case is not relevant I believe, because I don't think we'll support devices that forces the rootfs argument Aug 10 17:59:29 but I could be wrong Aug 10 17:59:50 rsalveti: That's right Aug 10 17:59:58 we'll have a detection routine that sets the UUID in ubuntu Aug 10 18:00:09 rsalveti: Also a while ago ogra_ told me that he wanted support for initrd-less booting for Ubuntu Aug 10 18:00:21 right Aug 10 18:00:24 (I don't remember why that was needed, but ISTR there was a valid reason) Aug 10 18:00:40 well, I believe that's supported already Aug 10 18:00:43 at least for 12.04 Aug 10 18:00:45 we just want the option as we have on all other arches Aug 10 18:01:00 but yeah, it'll break the ones that needs the 'yes' here, as for that we'd need an initrd anyway Aug 10 18:01:00 maybe in Ubuntu's f-k, I don't think it's the case in Debian's Aug 10 18:01:35 since i merged 3.0 its not the case in ubuntu Aug 10 18:01:45 but its planned to be changed before FF Aug 10 18:01:49 rsalveti: Ok; diner is ready here now, could we discuss your specific problem(s) and get over the patch together next week? Aug 10 18:02:20 lool: sure, that's covered at the bug already, but if needed we can discuss it properly again Aug 10 18:02:33 if you can just reply it later on it'd help already Aug 10 18:02:43 rsalveti: Would it be worth a bug that l-m-c doesn't generate the fstab before making the system bootable? Aug 10 18:03:05 not that sure, that shouldn't be a requirement Aug 10 18:03:07 that's my point Aug 10 18:03:27 we don't support devices that we can't control the bootloader Aug 10 18:04:04 If you're building, say, a bootable installer, you *can't* generate a valid fstab before making the image bootable. Aug 10 18:04:14 ogra_: the only thing that we probably need to check again with current debian implementation is that they are supporting device tree already Aug 10 18:04:15 You generate the fstab at install time. Y'know, after you've booted. Aug 10 18:04:18 at the 3.2 version Aug 10 18:04:57 (Granted, in these cases, we hand-craft the boot bits, and ignore f-k entirely) Aug 10 18:05:02 rsalveti, well we surely dont support it yet Aug 10 18:05:03 so we want to make sure we try to avoid duplication here Aug 10 18:05:18 but we'll need to support I believe Aug 10 18:05:27 i just fell over that when trying my mx6 board (before i briked it hard following the linaro instructions) Aug 10 18:05:57 that wikipage should get a big fat warning btw Aug 10 18:06:53 ogra_: that's why my heads up :-) Aug 10 18:06:57 ogra_: yup =\ Aug 10 18:07:55 infinity: But then don't run flash-kernel in it (SKIP=yes) -- I'm fine with the SKIP use case Aug 10 18:08:29 that is, I'm fine with install the flash-kernel package with SKIP=yes, and then run flash-kernel when deploying on the device to make the device bootable Aug 10 18:09:22 rsalveti: Hmm I think you're envisioning the installer as running flash-kernel *and* setting up u-boot files, while I envision flash-kernel to also setup the u-boot files if needed Aug 10 18:09:46 setting up should only be happening by f-k-i Aug 10 18:09:55 ogra_: Wow, how did you manage to brick your board? Aug 10 18:09:55 f-k should only update Aug 10 18:10:13 lool, by following the linaro wiki (copy/paste) Aug 10 18:10:21 https://wiki.linaro.org/Boards/MX6QSabreLite Aug 10 18:10:38 ogra_: why did it get bricked? Aug 10 18:10:59 sudo dd if=iMX6DQ_SPI_to_uSDHC3.bin of=/dev/sdx ... then boot with this in the slot ... and copy paste the 5 lines into the u-boot shell Aug 10 18:11:28 that will tell you it successfully updated and crc checked etc ... and after that the board is dead Aug 10 18:12:05 i got the windows unbrick tool but lacka proper windows that can see raw usb devices to fix it ... Aug 10 18:12:13 (my weekend homework) Aug 10 18:13:39 ogra_: but is it because the files are for another board? Aug 10 18:14:17 its a sabrelite Aug 10 18:14:37 not sure if there are many iterations of it Aug 10 18:15:15 but i wouldnt think so Aug 10 18:15:42 i even have the same u-boot prompt (not that this says much) Aug 10 18:15:54 s/have/had/ Aug 10 20:06:22 ogra_: Try Win32ImageWriter? **** ENDING LOGGING AT Sat Aug 11 02:59:58 2012