| === soren_ is now known as sorne | ||
| === sorne is now known as soren | ||
| ev | cjwatson: correct me if I'm wrong, but installing grub to a partition's VBR when it's already on the MBR will mean you're still booting off the MBR pointing at whatever partition was created when GRUB was installed to the MBR | 12:14 |
|---|---|---|
| ev | in other words, not the desired effect | 12:14 |
| ev | I'm wondering if grub leaves any kind of signature on MBR beyond the obvious 0x55AA so we could detect this scenario and warn the user | 12:15 |
| CIA-3 | console-setup: cjwatson * r392 ubuntu/debian/ (changelog keyboard-configuration.postinst): | 12:19 |
| CIA-3 | console-setup: Don't fail to configure keyboard-configuration if setxkbmap fails to | 12:19 |
| CIA-3 | console-setup: talk to the X display (LP: #728764). | 12:19 |
| cjwatson | ev: there is unfortunately no way to reliably detect that | 12:20 |
| cjwatson | it would be lovely, but the MBR is basically chaos. any signature you might use is either seriously mutable across GRUB versions, susceptible to not being overwritten when another boot loader is installed, or both | 12:21 |
| cjwatson | and there are zero bytes free in GRUB's MBR so no room to add anything | 12:21 |
| cjwatson | (0x55AA isn't GRUB's signature, BTW - the disk doesn't have a valid DOS partition table without that) | 12:22 |
| cjwatson | I'm actually not at all sure how the BIOS detects whether the MBR is bootable | 12:23 |
| cjwatson | actually I suspect that the MBR must always be bootable and will sometimes chain to a PBR | 12:24 |
| ev | oh I didn't mean to imply it was grub's signature, but that of the mbr | 12:27 |
| ev | which is why I said beyond 0x55AA | 12:28 |
| ev | perhaps we should just always display a message when they select a partition | 12:28 |
| ev | chances are there will be a bootloader in the mbr | 12:28 |
| ev | and just word it to say "if you have a bootloader in the mbr" | 12:29 |
| ev | we don't ever use blocklists, right? | 12:29 |
| ev | just trying to determine what state mpt's laptop is in (running around the office between broken computers today, it seems) | 12:29 |
| ev | ah, we do. | 12:31 |
| ev | I guess that's preferable to taking up an entire primary partition for just core.img, even with the risks of the filesystem moving things around? | 12:32 |
| cjwatson | the thing is | 12:48 |
| cjwatson | there is a contingent who really, really, really, really, really want to install our boot loader in a partition record | 12:48 |
| cjwatson | I'm worried we'll piss them off even further by throwing up more and more warnings | 12:48 |
| cjwatson | and they sort of have a point, they don't want Ubuntu to take over the machine because it isn't their primary OS | 12:49 |
| cjwatson | don't generalise from mpt's laptop | 12:49 |
| cjwatson | it's a Mac | 12:49 |
| cjwatson | they're weird | 12:49 |
| cjwatson | once the world switches over to GPT, this will stop being a problem - GRUB will occupy a partition | 12:50 |
| cjwatson | can't really do that sanely on MBR though | 12:50 |
| cjwatson | I confess I can never remember exactly how boot loaders are best installed on Macs, and it always makes my head hurt | 12:50 |
| cjwatson | I think if you put them in the MBR there, other things stop working | 12:51 |
| cjwatson | there are messy interactions with refit and boot camp | 12:51 |
| CIA-3 | console-setup: cjwatson * r393 ubuntu/debian/changelog: releasing version 1.57ubuntu10 | 13:42 |
| ev | fair point | 13:53 |
| ev | I'm not arguing for or against blocklists, in case that wasn't clear. I was just curious as to the motivation for using them given the risks. | 13:54 |
| cjwatson | lesser evil | 13:54 |
| cjwatson | I'd love not to need to | 13:54 |
| ev | right-o :) | 13:54 |
| cjwatson | (we won't need them with btrfs, once we get round to writing the code to make grub use its bootloader embedding area) | 13:55 |
| ev | is this documented/explained somewhere? Google-fu seems to be failing. | 14:05 |
| cjwatson | the btrfs bit? | 14:06 |
| ev | yes | 14:08 |
| cjwatson | http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg02036.html | 14:08 |
| cjwatson | the 64kb comment | 14:09 |
| ev | great stuff, thanks | 14:12 |
| ev | cjwatson: we had someone try to install Ubuntu today and wasn't offered the resize option, because HP thinks it's funny to use up all four primary partitions. Given that the only option from here for the regular user is format, what are your thoughts on pointing them in the direction of Wubi in this case (if they have an NTFS partition)? | 14:28 |
| ev | Not trying to apply it as the solution to everything, but it seems like one of those cases where their options are already limited and if it doesn't work they're no worse off. | 14:28 |
| ev | (This would presumably be done by greying out the resize option and changing its text to explain the situation with a link to run Wubi. The code behind the link would copy Wubi to the Windows startup folder and reboot, and I'd change Wubi to remove itself from there during install.) | 14:28 |
| ev | sorry to keep bugging you today | 14:28 |
| ev | but I figured this is one of those things you'd want a say on before I just went ahead and did it | 14:28 |
| cjwatson | interesting thought | 14:29 |
| cjwatson | it's not the only option of course since it's conceivable they might want to delete something | 14:29 |
| cjwatson | but I think it's worth mentioning | 14:29 |
| cjwatson | if it can work smoothly, go for it | 14:30 |
| ev | brilliant, thanks | 14:31 |
| ev | but indeed, it would still leave the other options intact | 14:31 |
| ev | this would just replace the resize option in that case | 14:31 |
| cjwatson | ev: bug 712654 - is this something you know of us having fixed between alpha 2 and alpha 3? | 14:52 |
| ubot2 | Launchpad bug 712654 in ubiquity "system does not reboot after installation is complete - virtual box" [Medium,New] https://launchpad.net/bugs/712654 | 14:52 |
| ev | nope | 14:52 |
| ev | I've seen intermittent reports of this over the years, but I've never been able to reproduce it | 14:52 |
| cjwatson | could you mention that in the bug for the record? | 14:54 |
| ev | cjwatson: absolutely | 15:00 |
| cjwatson | ta | 15:01 |
| ev | any thoughts on what could be causing this? It's a bit perplexing as the code around shutting down is fairly simple. | 15:01 |
| ev | I wonder if we should start logging the loop level. | 15:01 |
| cjwatson | I'm not sure, I wondered if it might be outside ubiquity | 15:03 |
| ev | yeah, that's definitely possible though quite harder to debug | 15:05 |
| ev | especially if it's X level | 15:06 |
| ev | :-/ | 15:06 |
| ev | I wonder. Perhaps the flush during unmount of /target is taking quite a long time | 15:07 |
| ev | and it's appearing as though the system has locked up | 15:07 |
| cjwatson | or could be YA upstart job logic error | 15:11 |
| ev | lets tell them to pass --debug and strace -f and just wait for the aufs overlay to fill up. ;) | 15:13 |
| ev | I've followed up on the bug | 15:13 |
| cjwatson | hah | 15:14 |
| cjwatson | the other day I wound up waiting until after partitioning and stracing to /target/tmp/ubiquity.trace | 15:14 |
| cjwatson | which was a good decision since the strace was >1GB | 15:14 |
| cjwatson | ev: also - did you notice Brian got back to you on bug 709363? | 15:18 |
| ev | oo, I had not. Thanks | 15:20 |
| ev | strace> :) | 15:20 |
| ev | huh, so it's definitely not swap anymore | 15:22 |
| ev | ohhh, ecryptfs. | 15:24 |
| === cody-somerville_ is now known as cody-somerville | ||
| === superm1` is now known as superm1 | ||
| === highvolt1ge is now known as highvoltage | ||
| === dtech is now known as d-tech | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!