| === Ursinha is now known as Ursinha-away | ||
| === bivab is now known as bivab_away | ||
| === bivab_away is now known as bivab | ||
| highvoltage | is it normal for Ubuntu ARM builds to depend on having busybox in the initramfs? I disabled it and then I got a kernel panic on "init: grep: not found" | 11:48 |
|---|---|---|
| === ericm_ is now known as ericm | ||
| === Ursinha-away is now known as Ursinha | ||
| === bivab is now known as bivab_away | ||
| === bivab_away is now known as bivab | ||
| === yofel_ is now known as yofel | ||
| GrueMaster | highvoltage: Yes, it is. All of the premount init scripts need it to run. If you don't want that, don't use initrd. | 13:58 |
| ogra_ | erm, *all* ubuntu initrds depend on busybox | 13:59 |
| ogra_ | its the default shell in the initrd | 13:59 |
| ogra_ | nothing arch specific with that | 13:59 |
| === bivab is now known as bivab_away | ||
| === bivab_away is now known as bivab | ||
| === bivab is now known as bivab_away | ||
| highvoltage | ogra_: I usually disable busybox in my initrds on ubuntu machines and they work just fine | 14:16 |
| highvoltage | (at least they appear to) | 14:16 |
| ogra_ | well, how exactly do you disable it ? | 14:22 |
| ogra_ | /init in the initrd is a shellscript | 14:23 |
| ogra_ | and the only shell shipped in initrd is busybox | 14:23 |
| ogra_ | (also all local-top/bottom/premount scripts are shell) | 14:24 |
| ogra_ | you probably found an arm specific bug | 14:24 |
| ogra_ | (i.e. that it is actually disableable while that option is ignored on other arches or some such) | 14:26 |
| === bivab_away is now known as bivab | ||
| === bivab is now known as bivab_away | ||
| === bivab_away is now known as bivab | ||
| === bivab is now known as bivab_away | ||
| === bivab_away is now known as bivab | ||
| janimo` | highvoltage, have you switched to ARM lately :) ? | 15:16 |
| janimo` | are you on a quest for lowpower thin clients? | 15:17 |
| highvoltage | janimo`: I don't really switch to anything. I just assimilate, like the borg :) | 15:17 |
| janimo` | borg needs arms too | 15:17 |
| highvoltage | indeed. | 15:18 |
| === bivab is now known as bivab_away | ||
| GrueMaster | ogra_: Can you review my change to lp:ubuntu/flash-kernel (lp:~gruemaster/flash-kernel/bug-961174)? Thanks. | 16:36 |
| === zyga is now known as zyga-food | ||
| ogra_ | GrueMaster, hmm, that somewhat defeats the purpose of Env.txt etc, shouldnt they override boot.scr ? | 17:17 |
| GrueMaster | That's the problem. Apparently, Orchestra (or some provisioning tool) uses those, but our images don't. | 17:18 |
| GrueMaster | So if you use that tool to tell a system to do a netboot install, the boot partition never gets overwritten. | 17:19 |
| GrueMaster | Maybe it should go in f-k-i? | 17:19 |
| ogra_ | well, its still wrong imho | 17:20 |
| ogra_ | if some tool puts a broken file in the way it should also move it away | 17:20 |
| ogra_ | if a user puts such a file there it should do what its supposed to do | 17:20 |
| ogra_ | (override the system default) | 17:21 |
| ogra_ | f-k-i would surely be a better place but my complaint still stands even there | 17:21 |
| GrueMaster | The other issue (as I understand it) is if it exists and bricks the system (i.e. won't boot), you can't recover via usb boot. For remote deployments, this will be a problem. | 17:22 |
| ogra_ | right, still, the questions are a) why does it exist at all (why isnt boot.scr used) and b) why is its content broken | 17:23 |
| ogra_ | if we would rm the file or mv it like you do we prevent the user from using a documented override mechanism (and imho *introduce* a bug) | 17:24 |
| ogra_ | GrueMaster, can you ask rbasak why that file exists at all, why its broken in the bug ? | 17:24 |
| ogra_ | removing it isnt the proper solution | 17:25 |
| rbasak | ogra_: because it's been created by a previous tenant | 17:25 |
| ogra_ | since that would make the overriding impossible | 17:25 |
| ogra_ | the purpose of this file is to give the user an easy way to modify boot settings ... | 17:26 |
| ogra_ | if your tool uses that on a system level, fix the tool to use the system file please | 17:26 |
| ogra_ | breaking behavior for the use cant be a solution to this bug | 17:26 |
| rbasak | ogra_: When I install Ubuntu on an Intel machine, I expect the installer to override whatever the boot configuration was previously. If the MBR was set up to boot Windows, after running the installer and confirming that I want the boot configuration changed, I expect the system to boot Ubuntu. | 17:27 |
| rbasak | ogra_: if you want to override this, you change the boot configuration _after_ running the installer but before booting into the new system | 17:27 |
| ogra_ | if you install on an intel system you have various possibilities to override the bootloader settings | 17:27 |
| rbasak | ogra_: I don't see why the behaviour on a Pandaboard should be any different | 17:28 |
| mahmoh | so that's not entirely true, you can add info. to grub for boot specifics which I don't think you can with u-boot/boot.scr at the moment | 17:28 |
| rbasak | If you want to override the boot, then tell the installer that you don't want to run flash-kernel-installer | 17:28 |
| ogra_ | if you use u-boot the only way to i.e. ebnable a serial console in the kernel cmdline is to put an uEnv.txt in place | 17:28 |
| ogra_ | or to fiddle with the provided boot.scr ... | 17:28 |
| mahmoh | righjt | 17:28 |
| mahmoh | right | 17:28 |
| ogra_ | the .txt files were enabled for easier overriding through user action | 17:29 |
| ogra_ | if you have any tool using that machanism, make it better use boot.scr | 17:29 |
| rbasak | What you have in there at the moment is a hack which is preventing the installer from doing its job properly. What I want is for the installer to work in all cases. If you want to add a hack later, then please don't break my use case! | 17:29 |
| ogra_ | i dont want to add any hacks at all | 17:29 |
| rbasak | It is necessary for the installer to be able to erase any configuration left by a previous tenant | 17:30 |
| ogra_ | if your use case usues a user definable file to set system settings your use case does it wrong | 17:30 |
| ogra_ | thats like having a package put a used rule into /etc/udev/rules.d | 17:30 |
| ogra_ | instead of using /lib/udev/rules.d | 17:30 |
| rbasak | My use case requires a machine to be able to be reinstalled regardless of what was there before | 17:31 |
| ogra_ | you wouldnt use /etc in that case either | 17:31 |
| rbasak | Orchestra needs this too. | 17:31 |
| ogra_ | still you make use of a user override mechanism on a system level | 17:31 |
| rbasak | I'm not making use of anything | 17:31 |
| ogra_ | use the system mechanism for this | 17:31 |
| rbasak | The user leaving a uEnv.txt is a DoS | 17:31 |
| rbasak | I'm not using it | 17:32 |
| ogra_ | well, who puts the .txt file in place ? | 17:32 |
| ogra_ | the one that got in your way i mean | 17:32 |
| rbasak | Somebody who has root on the machine before I remotely decide to wipe and reinstall it to give it to someone else who has root on the machine. | 17:32 |
| infinity | DoSing yourself isn't a DoS. | 17:32 |
| ogra_ | rbasak, if there is a way that we can know we are in such an environment, i'm happy to add a hack for that specific env | 17:34 |
| infinity | Maybe it would be nice if d-i detected this odd situation and asked about it, but this isn't "just like ovewriting a windows MBR", and it would be best to not pretend it was. | 17:34 |
| GrueMaster | I think the root of the problem is that partman currently doesn't reformat the boot partition during netinstall. | 17:34 |
| ogra_ | breaking documented override behavior for everyone cant be the solution for a corner usecase | 17:34 |
| rbasak | ogra_: how about a preseed option to say "override any user overrides"? | 17:34 |
| GrueMaster | Known bug. | 17:34 |
| ogra_ | rbasak, that sounds saner at least | 17:34 |
| rbasak | ogra_: if it sees that then it will either delete uEnv.txt or *. | 17:34 |
| rbasak | infinity: it's not "yourself", it's a previous tenant DoSing a future tenant. Imagine if your EC2 instance didn't come up because a previous user left a file somewhere. | 17:35 |
| ogra_ | i'm not opposed to hacks (if you ask others they might call me the master of bad hacks even) ... but i'm opposed to break user abilities for providing their own defined overrides at install time | 17:36 |
| rbasak | ogra_: I think you've got the sense inverted. If the user wants to define an override at install time, he should say so using debconf! | 17:36 |
| ogra_ | thats not possible on a u-boot level | 17:36 |
| infinity | rbasak: Root is you. Calling yourself a "tenant" doesn't change things. There are a number of ways I can mess up an Intel system for the next person I sell it to as well. | 17:37 |
| infinity | rbasak: And the "boot partition" on firmwareless SD system (ie: a Panda) is more akin to the BIOS than to a disk MBR. | 17:37 |
| === zyga-food is now known as zyga | ||
| === steev_ is now known as steev | ||
| infinity | dannf: f-k highbank changes sponsored. | 19:23 |
| infinity | dannf: Do you have a sane way to test this once it's in the archive? | 19:24 |
| ogra_ | GrueMaster, bug 848782 looks suspiciously like a duplicate of bug 921137 | 19:25 |
| ubot2` | Launchpad bug 848782 in flash-kernel "Serial console not enabled for passphrase prompt when using LUKS" [Medium,In progress] https://launchpad.net/bugs/848782 | 19:25 |
| ubot2` | Launchpad bug 921137 in flash-kernel "Flash-kernel-installer doesn't support d-i debian-installer/add-kernel-opts in preseed " [Undecided,Confirmed] https://launchpad.net/bugs/921137 | 19:25 |
| GrueMaster | Similar, but slightly different. | 19:25 |
| infinity | They can both be fixed in the same way, I think. I had a local branch for that and got sidetracked... | 19:25 |
| ogra_ | well, i dont see any solution for 848782 apart from using add-kernel-opt | 19:26 |
| ogra_ | s | 19:26 |
| * infinity wonders where that went. | 19:26 | |
| ogra_ | that you use LUKS doesnt reallys imply that you use a serial console, that needs to be specified anyway | 19:26 |
| ogra_ | (luks could indeed preseed that value if it knows there is only serial) | 19:27 |
| infinity | Nah, it should just do the same thing grub-installer does here. | 19:27 |
| infinity | And, like I said, I was working on that. Tobin and I discussed it a while ago. I just got sidetracked with other stuff and let it slip. :/ | 19:28 |
| ogra_ | ah, k | 19:28 |
| ogra_ | the discussion above made me look at the f-k buglist :) | 19:28 |
| infinity | ogra_: So, I fixed all the *sums generation for all the images... Except for ac100.bootimg. Were you doing something abnormally hackish in how you deal with that? | 19:29 |
| ogra_ | not that i can think of | 19:30 |
| infinity | Hrm. | 19:30 |
| infinity | I'll have to investigate that further. | 19:30 |
| infinity | But at least the big images are all right now, which was the major concern. | 19:30 |
| ogra_ | look at the debian-cd code, i just added the .bootimg type to the file types | 19:30 |
| ogra_ | it isnt generated as .raw like the others though, since it comes directly out of live-build iirc | 19:31 |
| ogra_ | probably that gets in our way | 19:31 |
| ogra_ | feel free to leave that issue to me though | 19:31 |
| ogra_ | (not today anymore, but I can look at it before B2) | 19:31 |
| infinity | Yeah, it comes from live-build, same as manifest and other files. | 19:32 |
| infinity | It could just be exposing some weird assumption in cdimage, given than this is the only image that produces two files that need summing. | 19:32 |
| ogra_ | yeah | 19:33 |
| infinity | I could probably paper over it by making debian-cd sum the bootimg files, but I'd like to figure out why cdimage is doing it wrong. | 19:33 |
| ogra_ | iirc cdimage does it while renaming them from .raw to their actual filetype | 19:35 |
| ogra_ | or do i remember wrong ? | 19:35 |
| infinity | No, cdimage does it after the rename. | 19:35 |
| ogra_ | ah | 19:35 |
| infinity | But then maps certain extensions back to .raw, so it can match against the *SUMS in scratch. | 19:36 |
| * ogra_ through its the same function in the makefile | 19:36 | |
| infinity | bootimg doesn't get mapped though (which is correct), so... | 19:36 |
| infinity | I wonder how much of this mess I need to replicate to iterate through some local testing. | 19:37 |
| ogra_ | pfft, just do it on nusakan and revert it if it breaks | 19:37 |
| ogra_ | thats why we have it all in bzr :) | 19:38 |
| dannf | infinity: cool - yeah, just qemu though | 19:38 |
| infinity | ogra_: :P | 19:39 |
| infinity | ogra_: Not doing it in production for the obvious "don't work in production" reasons, but mostly, I want to reduce this to a small enough test that I can do it in seconds, not hours. :P | 19:40 |
| ogra_ | ah, yeah | 19:40 |
| ogra_ | still, relpicating cdimage loacally cries for pain | 19:41 |
| infinity | Oh, I've done that before. | 19:41 |
| infinity | But in this case, it's reducing, not replicating. | 19:41 |
| * ogra_ too, thats why i said that | 19:41 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!