/srv/irclogs.ubuntu.com/2014/11/17/#ubuntu-installer.txt

DHRI think that it is really important to build a 32-bit UEFI installer.  There are a tonne of new 32-bit only tablets and netbooks that require UEFI.  It is a shame that no mainstream Linux distro can be installed on them02:20
DHRHere's an unofficial Fedora for at least the Asus T100 and the Dell Venue 8 Pro.02:21
DHRWhat prompts me to come here is http://summit.ubuntu.com/uos-1411/meeting/22353/when-should-we-stop-making-32-bit-images/02:21
DHRIs there a better place for me to raise this point?02:21
=== psivaa-holiday is now known as psivaa
DHRIs this the right place to advocate for a 32-bit UEFI installation method?15:50
xnoxDHR: sure.16:09
xnoxDHR: most of those are 64-bit CPUs though, thus what we really need/want is to enable dual-installation of 32-bit UEFI and 64-bit UEFI on the installation media16:09
xnoxand correctly detecting that uefi-arch.16:09
xnoxhowever most of the new generation stuff is actually using 64-bit uefi these days.16:10
xnox"There are a tonne of new 32-bit" - you mean like with new atom SoCs? e.g. latest atom SoCs should be using 64-bit uefi in fact.16:10
cjwatsonWe already know about the 32-bit UEFI need, thanks16:12
cjwatsonThe advocacy has been heard and the very meeting that you linked to above included some ideas on progressing things16:12
* xnox will rewatch that video16:13
xnoxmy understanding is that 32-bit uefi is on the decline after a short usage on certain systems. I might be wrong though.16:13
DHRI know as a consumer that there are a whole raft of new 32-bit uefi systems, mostly tablets.  It might be a passing fad, but it is really strong right now.16:15
DHRI fear that the limitation is intentional (by Intel and possibly Microsoft) and hence is not going to end with a technical solution.16:16
DHRIs it true that a 64-bit kernel cannot currently make UEFI calls (whatever that might be?  ACPI??) to a 32-bit UEFI firmware?16:17
cjwatsonthat's my understanding16:18
cjwatsonnot ACPI, UEFI Runtime Services16:18
cjwatsonICBW, that's why I flagged it as something that needed to be checked when I mentioned it in the meeting16:18
DHRAhh.  I'll google that to understand.16:19
cjwatsonif I am wrong it simplifies things :)16:19
DHRHas Intel released 64-bit UEFI firmware that does the magic power management on the atom SoCs?  It's been a year or so waiting, I think16:20
cjwatsonthings may have changed, e.g. https://lkml.org/lkml/2014/3/4/24216:20
cjwatsonI really think that is not likely to be an installer area of expertise16:20
cjwatson#ubuntu-kernel might know better16:21
xnoxDHR: cjwatson: enabling CONFIG_EFI_MIXED should be sufficient, however it is currently known to me that things do not end up working on fedora/ubuntu with such kernels(64-bit)/firmware(32-bit)/bootloader(32bit efi grub)16:35
xnoxwhich is being troubleshooted, i can followup on the latest state of affairs around this internally here.16:35
DHR(sorry, was away).  xnox: that would be great, I think.  I'm not sure of what that means technically.16:53
DHRa pure 32-bit system SEEMS stupid to me, but in fact it matches these low-end systems fairly well.  They are limited in RAM by Intel (market segmentation game?  surely no good technical reason)16:55
DHRthey have limited "disk" too.16:55
DHRtypical right now: 2G RAM, 32G eMMC.  A flood of 1G / 16G tablets coming with Win 8.116:56
DHRMainstream distros seem to be sitting on the sideline.16:57
DHRI'd really love Linux to be the answer for some of those who discover how bad Win8.1 is on 1/16 tabs.  Wishful thinking?16:58
DHRI naively don't understand why a simple 32-bit-only UEFI install isn't a perfectly fine placeholder until some kind of mixed support can be engineered.16:59
DHRcjwatson: my understanding is: a pure 32-bit Ubuntu exists (obviously), but no UEFI installer for it.  I naively would have thought that creating a new .iso with a 32-bit UEFI installer ought to be just turning a crank.17:02
DHRThat's why I thought that this might be an installer questsion.17:02
cjwatsonI was replying specifically to your question about power management.17:03
cjwatsonAdding an additional image is technically not that hard, but increases our QA load non-trivially, which is a very scarce resource.  So we're not going to do that.17:04
cjwatsonWe would much prefer to add the capability to one of our existing images.  The problem is that historically attempting to do this to the i386 image broke other hardware.  As I said in the meeting, it's possible that the trade-offs are different now.17:05
DHRcjwatson: thanks for the LKML link.  With interruptions, I just got to it now.  It adds a piece to the puzzle.  I wonder why it isn't working on fedora/ubuntu.17:06
cjwatsonAnd if the hardware in question in fact has long mode (i.e. a 64-bit CPU) despite having 32-bit UEFI, then that potentially simplifies the problem considerably.  We were not clear in the meeting on whether this is in fact true.17:06
cjwatsonIt may be working.17:06
cjwatsonI can't claim authoritatively that it doesn't.17:06
DHRthe hardware I know about is advertised has being 64-bit.17:07
cjwatsonIn that case the next step that we arrived at in the meeting will likely work.17:07
cjwatsonThat is, add grub-efi-ia32 to the EFI System Partition on the amd64 images.17:08
cjwatsonAlthough that only helps for booting the images themselves; somebody is also going to need to figure out how to detect this situation at run-time and install grub-efi-ia32 on the target system as well.17:08
DHRdisk space is at a premium on these systems currently.  Isn't a mixed 32/64 system significantly fatter than a pure 32-bit system?17:08
cjwatsonIt wouldn't be particularly mixed.17:09
cjwatson32-bit boot loader, 64-bit everything else.17:09
DHRAs I said, 16G and 32G are the normal size.17:09
cjwatsonThat hardly seems likely to be problematic.17:09
cjwatsonIf we were talking about 4G or something then that might be more of an issue.17:10
cjwatsonWe appear to have CONFIG_EFI_MIXED=y now.17:11
cjwatsonBut I'd defer to xnox's internal knowledge.17:11
cjwatsonI think infinity was going to see if somebody on the development team could expense a suitable system and make it work.17:13
DHRIf that approach can work, is there a way to get a generally usable experimental image out very soon?  About detection: dunno, worst case, let the user tick a box (experimental!)17:13
cjwatsonNo17:13
cjwatson(to "tick a box")17:13
cjwatsonI'm quite sure there's a better option than that :-)17:13
cjwatsonWe're not adding new UI, because, bear in mind, that would logically have to be shown to everyone installing on any UEFI system, i.e. most users, and we're not doing that to people installing vivid.17:14
DHRThey are REALLY cheap.  I'd donate one if it would get things moving.  For example, $200 buys you an Asus x205.  $100 buys you one of several tablets (I can name names if that matters).17:14
cjwatsonI can't speak for timelines because I'm moving out of mainline Ubuntu development at the end of the year.17:15
cjwatsonHence redirecting to infinity ...17:15
DHROh, but I'm an impatient user :-)  Doing it before the end of the year is important :-)17:15
ogra_send a patch then :)17:17
ogra_(or multiple)17:17
cjwatsonogra_: I don't think that's a helpful answer.17:17
cjwatsonPlease don't answer if that's all you're going to say.17:18
* ogra_ shuts up 17:18
cjwatsonBecause this is too complicated for most people to know where to start ...17:18
cjwatsonInformation on how to detect the UEFI machine type (ia32 or x86-64) at run-time would be genuinely helpful though.17:19
cjwatsonhttps://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface says that "ioreg -l -p IODeviceTree | grep firmware-abi17:19
cjwatson" works on Mac OS17:19
cjwatsonAnd gives a non-Mac answer which is sadly inapplicable following CONFIG_EFI_MIXED17:19
DHRcynic: every time you ask a PC about whether it conforms to some standard, it lies.17:20
cjwatsoninfinity: http://kernelnewbies.org/Linux_3.15#head-e6cf8178e4d5eafc23b0abda81974d2b71ffecf417:20
cjwatsonHmm, need to fix grub2 to make linuxefi (for SB) build on i386_efi too then17:21
DHRThe base line assumption: if you were installed (or perhaps booted) by a 32-bit UEFI, you are on a machine in which you should use 32-bit UEFI runtime.17:21
cjwatsonDHR: I'm asking how to discover the former from userspace17:21
DHRMaybe that needs to be part of what CONFIG_EFI_MIXED adds to the mix.17:26
cjwatsonThere may well be information there already, but I don't know it.17:26
cjwatsonBut I'm suggesting that if somebody wants to help move this forward more quickly, then that's a critical-path thing we need to know that could be investigated independently.17:28
DHROK.  Thanks for the suggestion.  What kind of interface would be good for userland?  Something in /proc or /sys?17:29
cjwatsonI'd expect something in /sys17:29
DHRyeah, /proc shows how long ago I did any kernel hacking.17:30
cjwatsonI think once we have that information, the steps are to make grub-installer use it, to make grub2 build linuxefi on i386 as well, to build 32-bit shim binaries (I may not like Secure Boot, but we probably need to do it here), and to add all the relevant things to our amd64 images17:31
=== mwenning is now known as mwenning-lunch
DHRthanks for taking the time!  I'll see if I can find a hook in the patch you pointed me at.  I guess that's a bit stale now, but it's a starting point.17:34
DHRHow can I best return the results (if any)?  This channel?17:35
cjwatsonDHR: The kernelnewbies link above has links to the commits that actually landed, but they're probably best used as starting points for grepping current kernel source.17:35
cjwatsonDHR: Probably as good as any, yes.17:35
cjwatsonThanks for looking.17:35
DHRthinking out loud: something needs to record whether the efi64_thunk needs to be used.  So the info must be represented in the kernel.17:38
infinitycjwatson: Appreciate the redirect, but on VAC until next week. :)17:39
cjwatsoninfinity: Oh good point.  Feel free to park it until then17:44
DHRtype efi_system_table_t has a member "is64".  Seems to be  a start.17:49

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!