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