| === maxb_ is now known as maxb | ||
| superm1 | cyphermox: so the root cause of xnox's issue was missing fwupdate-signed (which is that upgrade bug he linked above) but that also reminds me that there needed to be a d-i install item for fwupdate-signed | 14:57 |
|---|---|---|
| cyphermox | hum, what? | 14:58 |
| cyphermox | oh. yeah, to install fwupdate/fwupdate-signed if we detect this is secureboot and all | 14:59 |
| cyphermox | well, EFI really, not secureboot | 14:59 |
| cyphermox | in any case, it's not done, and it's not the right time to do this anymore | 14:59 |
| superm1 | well for .1 though? | 14:59 |
| cyphermox | for now gnome-software will need to pull fwupdate/-signed and everything it needs | 15:00 |
| cyphermox | yeah, for .1 | 15:00 |
| cyphermox | I totally agree we should get it fixed | 15:00 |
| cyphermox | just not that it's critical for the release thursday :) | 15:00 |
| superm1 | right | 15:00 |
| superm1 | the normal install scenario (ubiquity) does it right and that's what most people will do anyway | 15:00 |
| cyphermox | great | 15:00 |
| cyphermox | that's what I expected, but we indeed missed the d-i part | 15:00 |
| cyphermox | that said, doing this in d-i is easy | 15:01 |
| superm1 | it was in the back of my mind, but too much other stuff in the front :) | 15:01 |
| cyphermox | yeah | 15:01 |
| cyphermox | if you convince infinity maybe we can squeeze it in | 15:01 |
| xnox | superm1, it did go to 100% 4/5 times, but it did upgrade fine. | 15:01 |
| cyphermox | it won't be on images, but any networked install would work. | 15:01 |
| * xnox ponders what's new in the new firmware | 15:01 | |
| superm1 | i don't know how to do stuff in d-i myself having not dabbled there before | 15:02 |
| cyphermox | I may be able to do this later | 15:02 |
| xnox | superm1, you probably need somere if efi / if signed / apt-install fwupdate-signed | 15:02 |
| xnox | and that's it | 15:02 |
| superm1 | xnox: yeah i've argued that we should really have multiple bars (1 for overall and 1 for individual item) that "BIOS flash" is actually like 5 different payloads (firmware, TiPD, ME, EC, and some others) | 15:03 |
| xnox | superm1, guys here are seeding fwupdate-signed somewhere to help with upgrades. | 15:03 |
| cyphermox | ok | 15:03 |
| xnox | superm1, or like each item could use the 1/5th of a progress bar | 15:04 |
| superm1 | xnox: yeah, but again out of my hands :) | 15:04 |
| xnox | =) | 15:04 |
| xnox | superm1, which one is for the NSA? | 15:04 |
| xnox | monitoring | 15:04 |
| xnox | superm1, we have no idea what TiPD and ME is =))))) | 15:05 |
| superm1 | TI power deliver (for type c) and intel management engine | 15:05 |
| superm1 | they're all signed with a key pair that matches one burned into hardware, so if NSA is going to modify binaries to insert some monitoring to that, we've got bigger problems :) | 15:08 |
| xnox | of course we do =) | 15:11 |
| xnox | anyway, wondering what's new in that firmware now | 15:11 |
| * xnox goes to try to find release notes | 15:11 | |
| superm1 | it should be mostly stability stuff | 15:11 |
| superm1 | there will be another landing soon too | 15:11 |
| xnox | does that have Intel updates too for skylake power management on linux et.al.? | 15:14 |
| xnox | superm1, also, nice one that I did not have to accept Dell EULA =) | 15:14 |
| xnox | to get the update | 15:15 |
| xnox | anyway, time to fix the release | 15:16 |
| superm1 | xnox: if you are having problems with NVMe not going into lowest power state (i forget where that fix landed) try to reset bios default settings | 15:17 |
| xnox | superm1, resetting bios to default settings will make NVMe disappear from linux | 15:17 |
| superm1 | set it to AHCI mode after | 15:18 |
| xnox | superm1, cause dell xps 15 ships with "intel rapid start" by default for nvme + windos 10. Change that to ACHI setting (like i did) makes Windows 10 non-bootable until one does the dance of safeboot->safeboot->windows | 15:18 |
| xnox | and achi is the one seen by linux. | 15:18 |
| xnox | yeah i am in ahci mode. | 15:18 |
| superm1 | xnox: oh yeah, iRST fun | 15:19 |
| superm1 | we ship it with AHCI mode in linux too | 15:19 |
| xnox | superm1, right, my bug is that Dell should ship Windows with *both* iRST & AHCI "drivers" in the Windows loader, such that flipping the switch in Bios does not break windows 10 boot | 15:20 |
| xnox | aka | 15:20 |
| xnox | Dell should not ship things that are susspeptible to https://en.wikipedia.org/wiki/Advanced_Host_Controller_Interface#Boot_issues | 15:20 |
| superm1 | but so what i was meaning by the reset bios default settings it causes the power management information that is supported by all devices and cached in NVRAM | 15:20 |
| xnox | "Some operating systems, notably Windows Vista, Windows 7, Windows 8 and Windows 10, do not configure themselves to load the AHCI driver upon boot if the SATA controller was not in AHCI mode at the time of installation. This can cause failure to boot, with an error message, if the SATA controller is later switched to AHCI mode. For this reason, Intel recommends changing the drive controller to AHCI or RAID before installing an operating | 15:20 |
| xnox | system.[1] (It may also be necessary to load chipset-specific AHCI or RAID drivers at installation time, for example from a USB flash drive.)" | 15:20 |
| xnox | oh, interesting | 15:20 |
| xnox | i can do that i guess. | 15:20 |
| superm1 | mjg59 was just talking to me about that yesterday | 15:21 |
| superm1 | he told me he couldn't get into PC8 (was stuck in PC3) | 15:21 |
| superm1 | and that was sorted on a BIOS update, but the ASPM information for the NVMe drive was cached from an earlier BIOS | 15:21 |
| superm1 | including both drivers for windows (AHCI and iRST) unfortunately doesn't fix that problem in Windows | 15:22 |
| superm1 | cyphermox: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1572198 there you go for tracking that for .1 | 15:23 |
| superm1 | i didn't see a milestone for .1, so i just marked -updates | 15:23 |
| xnox | superm1, right. surely the firmware upgrade should be able to flush those variables.... no? | 15:26 |
| superm1 | no it won't | 15:26 |
| superm1 | flushing those variables would make next POST longer | 15:26 |
| superm1 | normally they're only regenerated when a new device ID is detected at POST (eg adding a new drive) | 15:27 |
| superm1 | normally circumstances like this won't happen across BIOS releases | 15:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!