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