| doko | oSoMoN: is thunderbird supposed to migrate in eoan? | 07:17 |
|---|---|---|
| oSoMoN | doko, yes, once I manage to fix the enigmail pcc64el test failures | 07:19 |
| oSoMoN | doko, I'm on the case | 07:20 |
| === dwmw2_gone is now known as dwmw2 | ||
| rafaeldtinoco | morning o/ | 10:32 |
| xnox | infinity: kees: stgraber: vorlon: can i get a response on https://lists.ubuntu.com/archives/technical-board/2019-August/002456.html ? or should I open some bug report and start uploading things referencing it? | 10:40 |
| juliank | I'm trying to UEFI boot eoan kernels in eoan's qemu, but I get emulation failures | 11:01 |
| juliank | sudo kvm -boot c -hda fat:rw:/boot/efi -drive file=/dev/nvme0n1p2,format=raw,readonly,if=virtio -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd -drive if=pflash,format=raw,file=/tmp/M | 11:01 |
| juliank | Y_VARS.fd | 11:01 |
| juliank | basically | 11:01 |
| juliank | qemu fails the emulation with invalid opcode, kvm with emulation failure | 11:02 |
| juliank | ah, not enough mram for the vm | 11:03 |
| juliank | yeah, more ram makes it work more | 11:28 |
| juliank | still aborts after a kvm_mem_ioeventfd_add: error adding ioeventfd: No space left on device later on | 11:28 |
| juliank | oh, but I have a new kernel, I should reboot | 11:29 |
| juliank | yes, yes, now it works :) | 11:40 |
| juliank | 5.3 is one of the worst kernels in recent history | 11:40 |
| juliank | so many bugs | 11:41 |
| === ricab is now known as ricab|lunch | ||
| === ricab|lunch is now known as ricab | ||
| xnox | vorlon: infinity: why do we ship pool/ on the isos signed by the cdimage key, instead of simply doing "apt install --download-only" during squashfs building? especially since pool/ on subiquity & desktop images are there only for the offline install case and/or optional components, and not for general consumption. | 13:47 |
| xnox | (classic server iso has a more useful pool/ that is genuenly useful even post-install) | 13:48 |
| xnox | vorlon: infinity: with apt install --download-only, image building gets simplier and drops using a GPG key. | 13:48 |
| xnox | (useful discussion with Chipaca and zygo got me thinking) | 13:49 |
| vorlon | xnox: historically there was no squashfs at all, so you couldn't do that. So I don't think anyone's thought deeply about doing apt --download-only into the squashfs | 14:38 |
| xnox | vorlon: does it sound crazy, or doable? | 14:39 |
| vorlon | it doesn't initially sound impossible to me, but it needs more thinking | 14:40 |
| rbasak | You'd have to be careful about how you call "apt-get update", because the moment you do, offline install will be broken | 14:47 |
| rbasak | (but that's not a blocker) | 14:47 |
| infinity | xnox: If you download a bunch of debs into the squashfs, then you need to exclude them in the copy when you install, which complicates the installer. Not a blocker, but a point. Personally, though, the location of the repo doesn't matter to me, I still want it signed, cause it's too easy to screw up what you're doing with apt when you mix signed and trusted sources. | 16:08 |
| infinity | xnox: But they don't need to be signed with the cdimage key to achieve that goal, and my plan when we moved to building ISOs in LP instead of just squashfses was to sign with an ephemeral key generated at build time, and trust that one in the installer. | 16:09 |
| xnox | infinity: subiquity is already layered, and the point is that you do want to install those. Most of the time the pool will have like optional things in it needed in the target system, but not installed by default. something like 'zfsutils' | 16:12 |
| xnox | infinity: and there is no harm in copiying them to target, if they are small enough. | 16:13 |
| xnox | infinity: or like we run apt cache clean when done | 16:13 |
| xnox | infinity: i'm trying to reduce number of artefacts inside the .iso and things needed for subiqutiy netboot. | 16:14 |
| infinity | xnox: Uhh, what? | 16:14 |
| infinity | xnox: None of this is relevant for netboot. | 16:14 |
| xnox | infinity: yes and no. | 16:14 |
| xnox | infinity: airgapped netboot matters on s390x | 16:14 |
| infinity | xnox: In the netboot case, anything you'd find on the ISO pool is fetched from the archive. See the "net" in "netboot". | 16:14 |
| xnox | infinity: to be able to complete the install from the iso, whilst netbooting that iso. | 16:15 |
| infinity | xnox: Airgapped netboot implies a local mirror, dude. | 16:15 |
| xnox | infinity: and z has no way to access an ISO normally | 16:15 |
| infinity | xnox: There's no story for netboot without an apt mirror. | 16:15 |
| infinity | xnox: Please don't invent one. | 16:15 |
| xnox | infinity: well there could be =) | 16:15 |
| infinity | There never has been. | 16:15 |
| infinity | Please don't go out of scope. | 16:15 |
| xnox | infinity: dude stop. i know it's not a requirement. | 16:15 |
| infinity | The whole point of "netboot" is a very minimal boot artifact that bootstraps you into doing the rest from an archive mirror. | 16:16 |
| infinity | It's not just "not a requirement", it's entirely antithetical. | 16:16 |
| xnox | infinity: but instead of having: base, installer, modules, pool/, kernel, initrd I am thinking that we could restructure subiquity iso for it to only be: base.squashfs, installer.squashfs, kernel, initrd | 16:16 |
| infinity | Moving parts of the archive into the netboot to avoid the archive is the opposite of what netboot is for. | 16:16 |
| xnox | which can complete offline installs, or netboot installs, without needed to have access to cdrom mount which contains base/installer/kernel/initrd | 16:17 |
| xnox | infinity: no, the point of netboot is not at all to be minimal =) | 16:17 |
| xnox | infinity: the point of netboot that it does network boot. The minimal is not in scope at all. | 16:17 |
| xnox | infinity: cause i am downloading in RAM the full 500MB+ iso and booting subiquity off it, in full. | 16:18 |
| infinity | Yeah, fine. "minimal". :P | 16:18 |
| infinity | But also, you're not dowloading the full ISO, just squashy bits. | 16:18 |
| infinity | So sort of minimal. :P | 16:18 |
| xnox | and mirroring contents of an iso, and keeping all the pieces matching sounds hard, hence point to an .iso (which is just one file) is more simple for the user. | 16:19 |
| xnox | in turns out subiquity is coupled to the contents of just not the squashy bits =/ | 16:19 |
| xnox | and it's too many things to remember to download, hence download .iso is easier, and casper supports that a lot better. | 16:19 |
| infinity | It's coupled to the pool? I can't see how or why that would be, since it didn't even HAVE a pool until recently. | 16:19 |
| xnox | not to the pool per-se, but that there is /cdrom mount with a valid pool | 16:20 |
| xnox | and that there is different squashfs, called in particular way and moutable | 16:20 |
| xnox | and other auxiliry files in a specific layout, which keeps on changing from release to release. | 16:20 |
| xnox | anyway | 16:20 |
| infinity | I assume mwhudson has been consulted with your plans for his spec? | 16:21 |
| xnox | that's why i think it's obsurd the amount of things we have in an .iso and if combinding things inside the iso will make things a lot easier to manage / build / mirror / netboot / offline-install | 16:21 |
| xnox | i'm just doing implementation prototype now, and realising that some of the things we speced out, were a lot more pretier in the spec than in practice. | 16:22 |
| xnox | anyway. | 16:22 |
| infinity | Anyhow, I'm very much -1 on "just point to the ISO, who cares if it's twice the size of what we actually need". | 16:22 |
| xnox | simplifying contents of .iso is a tagent | 16:22 |
| infinity | People never had problems mirroring the old d-i netboot structures and unpacking them. I don't see why this needs to suddenly be "hard". | 16:23 |
| xnox | infinity: let me get the delta. | 16:23 |
| infinity | Multiple files isn't a killer. | 16:23 |
| infinity | Be sure to get the delta on an LTS point release ISO. | 16:23 |
| xnox | infinity: they mirrored the one archive. | 16:23 |
| infinity | Which ships with two kernels, two sets of modules, etc, and you don't need all of that to boot one machine. | 16:23 |
| xnox | infinity: d-i runs from an initrd, subiquity is a snap. | 16:24 |
| infinity | xnox: Yes, they mirrored the archive, and we identified that as a thing we need to figure out for this to work properly. | 16:24 |
| xnox | infinity: and like maas does download cloud-image squashfs mounts that, and runs system from there curtin and all that. | 16:24 |
| infinity | How subiquity is packaged is entirely irrelevant. | 16:24 |
| infinity | Unless you're proposing snapd in firmware. :P | 16:25 |
| xnox | well i don't want to create a new artefact at all. I.e. such that an iso has the things one needs to either unpack, or publish, or boot directly. | 16:25 |
| xnox | *any new* | 16:25 |
| infinity | Okay, making the ISO "unpackable" seems not terribly difficuly. But I don't see how that would look a lot different from today's ISO. | 16:26 |
| infinity | Not that "unpacking an ISO" is really any easier for people than "mirror these bits". | 16:28 |
| xnox | infinity: point is that today, when doing network boot, casper doesn't know the layout and the contents of the iso. It blindly mounts all the things it sees, in alphabetical order, and boots it. And pieces inside it have loosely coupled dependencies on the rest of the iso layout. | 16:28 |
| infinity | You're making that sound a lot worse than it is. | 16:29 |
| xnox | and i don't feel like encoding in casper filenames to walk/download, or which ones are mandatory, if normal boot path doesn't. Cause we change livecd-rootfs and eventually add code to use new pieces. without touching casper normally. | 16:30 |
| LocutusOfBorg | jamespage, hello, please src:gnocchi fix on armhf autopkgtests? | 16:34 |
| LocutusOfBorg | you probably want to add curl to test dependencies | 16:34 |
| LocutusOfBorg | (assuming curl is available might be not the best idea= | 16:35 |
| jamespage | yep (although it would be nice in test envs where consistent) | 16:36 |
| LocutusOfBorg | jamespage, this is true, I can't understand why curl is installed everywhere except armhf, but in any case if you use it directly, a dependency is the best thing to do... | 16:38 |
| LocutusOfBorg | Laney, ^^ do you happen to know why? | 16:38 |
| Laney | no, something in cloud images depends on it presumably | 16:38 |
| jamespage | most likely - its part of the server and cloud-image tasks | 16:39 |
| jamespage | LocutusOfBorg: anyway fix uploaded | 16:39 |
| LocutusOfBorg | thanks | 16:39 |
| xnox | infinity: like people will not mirror .disk/info and .disk/casper-uuid-generic correctly =) unless you ask for url to the full .iso =) | 16:44 |
| infinity | xnox: Okay, so if casper doesn't see squishyfses, it tries to grab the ISO from a well-known location (or a preseeded location, if given), mounts, and carries on. | 16:46 |
| infinity | xnox: That doesn't imply a layout change is necessary either. | 16:46 |
| xnox | infinity: yeah. but enqually the current iso listing is, well.... tasteless | 16:47 |
| xnox | and not as cute as for example maas artefacts. kernel + initrd + filesystem (which is both used for ephemeral boot, provisioninged, and is deployed/layed on disk) | 16:48 |
| xnox | infinity: not sure about the well-known location, cause at the moment initrd is coupled to the iso contents. I.e. it must be at least the same kernel abi. And the well known location changes, for a given initrd. | 16:49 |
| xnox | that's why i kind of want to decouple things more, such that vmlinuz+initrd pair can use/deploy many .isos; i.e. not necessarily the one matching the build that vmlinuz+initrd came out of. | 16:49 |
| infinity | Then you want kexec. | 16:50 |
| infinity | Comparing this to maas isn't fair, as their initrd is also the entire "installer", much like d-i. | 16:51 |
| infinity | We're getting our installer from a massive rootfs that must actually be usefully bootable. | 16:51 |
| xnox | infinity: no their initrd is not the intire installer. | 17:16 |
| xnox | infinity: their initrd has cloud-config, which they drive ephemerally booted cloud-image squashfs without kernel (the lxd squashfs) | 17:17 |
| xnox | which talks to maas to run curtin, talk back to maas, and shutdown. | 17:17 |
| xnox | so their initrd has all the kernel modules + cloud-url / overlayroot stuff | 17:18 |
| infinity | xnox: Oh, right, they have two rootfses. Forgot about that bit. | 17:20 |
| xnox | infinity: i still have no idea why we ship linux-firmware package on s390x | 17:22 |
| xnox | is it useful for like mellanox scsi cards? because that's like the only peripheral that could be used on the mainframe | 17:22 |
| infinity | xnox: Because it's arch:all and a dep of the kernel. If literally no drivers for s390x reference firmware in it, request the dep be dropped from s390x kernels? | 17:24 |
| infinity | xnox: (the kernel team should have tooling to discover said deps) | 17:24 |
| sarnold | mellanox scsi? | 17:24 |
| xnox | is it scsi | 17:26 |
| xnox | Mellanox ConnectX®-4 LX adapter as the, IBM 10GbE RoCE Express2, FC# 0412, offers the best cost effective Ethernet adapter solution for 10Gb/s Ethernet speeds | 17:27 |
| xnox | sarnold: what is that? | 17:27 |
| xnox | PCIe not Scsi right?! | 17:27 |
| xnox | https://blog.mellanox.com/2017/08/mellanox-delivers-connectx-4-lx-ibm-z14/ | 17:27 |
| sarnold | man that's one catchy name | 17:28 |
| infinity | sforshee: How feasible would it be to conditionalise linux-firmware deps in the kernel build with a build-time scan of objects to decide if they actually have external firmware deps in the first place? | 17:30 |
| infinity | sforshee: (One could do this scan manually and twiddle deps manually too, but then the world explodes the first time that situation changes for $flavour and no one notices) | 17:30 |
| xnox | sarnold: infinity: so 13% of our subiquity s390x iso is linux-firmware.deb | 17:31 |
| xnox | probably more than that, cause pieces of it are copied into initrd.ubuntu and hte xecond ubuntu.ikr initrd. | 17:32 |
| xnox | *the second | 17:32 |
| infinity | Technically, that would also mean most linux-firmware deps would move from the metapackage (where they live today) to linux-modules-extra-ABI, which actually has the dep in most cases. | 17:32 |
| infinity | xnox: I'm not sure that's a useful datapoint I care about, since removing it from s390x doesn't help amd64, and s390x is the enviornment least likely to care about the installer being a bit chubby. | 17:33 |
| infinity | xnox: But from the POV of things being clean, I agree that useless l-f deps shouldn't exist. | 17:33 |
| xnox | infinity: currently subiquity requires pool to be there, but i think it can be empty. Pool is 20% of the iso, most of which is the kernel debs, as things are small and tiny below linux-modules-extra. | 17:33 |
| xnox | infinity: and currently subiquity would use the .deb from the pool, even if the network is available, if the one over the network is no newer. | 17:34 |
| infinity | Yes, by design. | 17:34 |
| infinity | But not ideal for netboot. | 17:34 |
| xnox | (for example installing daily devel image, one will have to fetch linux.deb into target anyway, so doesn't matter if it comes from the predownloaded .iso or the archive) There is runtime RAM penalty. | 17:35 |
| infinity | Anyhow, I tihnk "make it netboot" takes first priority, then "figure out how to put it on a diet" might come second. | 17:35 |
| xnox | so i'm not sure there is a massive difference in downloading a few (less than 10) files that add up to 381 with 80 later (460 total) or 575MB in one go. | 17:36 |
| infinity | I am somewhat concerned about the RAM usage in general, but I hope that's just me living in the past when computers didn't have gobs of RAM. | 17:36 |
| xnox | to me, it sounds interesting point that maas deploys useful baremetal machine; they used to have d-i & cloud-image based installer, and use cloud-image based installer and do fetch over the network and boot in ram the cloud-image squashfs. | 17:37 |
| xnox | realistically, our cloud-image squashfs is small enough to do that, on all but extra-small / small VM sizes in the cloud. | 17:38 |
| xnox | and all bare-metal servers are larger than S sizes in amazon. | 17:38 |
| xnox | infinity: i agree that it should "netboot" as a priority, and optimizations / changes can be iterated on top of htat. | 17:39 |
| infinity | Holding an ISO in RAM probably throws those calculations off a bit, but point taken that MaaS basically does the same thing, ish, just slightly slimmer. | 17:39 |
| xnox | infinity: i am pondering in my head, how i can come up with something that can be a thin/independant overlay that can be put on top of the maas squashfs. Or even if we could just use cloud-image with elaborate config of "talk to snap store, fetch subiquity, and please run it" =) | 17:44 |
| infinity | I don't think we want to reimplement MAAS here. | 17:47 |
| infinity | Having two rootfses instead of one isn't really going to help subiquity, when it needs to function with only one for the ISO already. | 17:47 |
| xnox | infinity: true | 17:48 |
| xnox | infinity: i am also still pondering to have more UI in casper initrd | 17:48 |
| xnox | infinity: like "I didn't find cdrom, or drive, and no network was provided", would you like to "ip=dhcp? url=http://releases.ubuntu.com/{release}/ubuntu-server-live.iso" | 17:49 |
| xnox | infinity: or like able to type in ip= command, vlan, url from there. | 17:49 |
| infinity | s/casper/subiquity initramfs hook that ends up in casper initrd/ maybe? | 17:49 |
| xnox | such that one doesn't need to reboot, if there is console access (remote kvm) and one made a typpo | 17:50 |
| xnox | yeah | 17:50 |
| xnox | basically interactise it to be on par with network-console d-i page | 17:50 |
| infinity | I wouldn't be against such fanciness for v2 (or v0.2 :P) | 17:50 |
| xnox | (which is what s390x people use today) | 17:50 |
| infinity | The only problem you have with early interaction is that we won't do keyboard/locale setup until we enter subiquity. | 17:51 |
| infinity | So it assumes everyone knows how to blindly type on pc101 on their local keyboard. | 17:51 |
| infinity | s/pc101/us101/ | 17:51 |
| infinity | Unless we can do it so early that we're still getting raw keyboard input. | 17:52 |
| infinity | Which might be true in early initrd. I'm not sure how "configured" the linux console is before we do things to it. | 17:53 |
| infinity | As someone whose chosen keyboard layout happens to also be the accepted default everywhere, I don't usually have to think about this sort of thing. | 17:53 |
| sforshee | infinity: on the surface it seems feasible to base the linux-firmware dep on scanning objects in the package, I'd have to play with it to see how hairy it works out to be in practice | 17:59 |
| infinity | sforshee: Yeah, I figure it's not as simple as one sentence on IRC. But I was also pretty sure you already have tools for scanning module->firmware relationships that you use for d-i udebs, and also just to know if you're missing junk (for HWE, etc). | 18:02 |
| infinity | sforshee: So turning that into a "if binary package foo needs firmware, it should depend on it, if not, not" would move firmware deps to modules or modules-extra (or sometimes nowhere for some flavours), which feels more "correct". | 18:03 |
| infinity | sforshee: To get it right, I imagine you'd also have to build-dep on linux-firmware to know what it ships. And flavours with their own firmware packages would get those in the build-deps too. Or something. Maybe. I dunno. Also happy to have you file it under Flying Cars, decide it's too much trouble, do a one-time scan of s390x for xnox to decide if you can drop the l-f dep from generic/s390x meta deps, and call it done. :P | 18:05 |
| sforshee | infinity: firmware required my modules is supposed to be declared in the .modinfo secion, so it's pretty easy to get at. Not all drivers are so straightformward though, e.g. iwlwifi will accept a range of firmware versions but only declares a single version in .modinfo | 18:06 |
| sforshee | still, one would hope that version is in fact in linux-firmware | 18:06 |
| infinity | sforshee: I try to pretend iwlwifi doesn't exist, except every three years when it's laptop buying season and I have to begrudgingly admit that theirs works better than everyone else's and buy another one. | 18:09 |
| sforshee | infinity: must be nice | 18:09 |
| infinity | Maybe the free ath drivers are finally on par by now, I haven't done side-by-side for a while. | 18:10 |
| sforshee | yeah me neither, they seemed to be doing pretty good for a while but I'm not sure now | 18:11 |
| xnox | infinity: i wonder if we will find that we do compile wifi drivers on s390x even though that's impossible to use | 18:19 |
| === southey is now known as foxtrot | ||
| infinity | xnox: I feel like the maintainer of the s390x port should know the answer to that. :) | 18:22 |
| xnox | infinity: if only they would rotate me into the kernel team finally | 18:28 |
| infinity | xnox: You need to be in the kernel team to look at /boot/config*? | 18:28 |
| xnox | infinity: nah =) but like digging and optimising it. | 18:29 |
| infinity | I guess I should stop reading things not produced by my team. ;) | 18:29 |
| xnox | enotime for that | 18:29 |
| * xnox checks which version zfcpdump-kernel is at | 18:29 | |
| xnox | https://launchpad.net/ubuntu/+source/zfcpdump-kernel is v4.13 | 18:29 |
| infinity | Pretty sure if we rotated you into the kernel team, bjf would murder you in the first week. | 18:29 |
| * xnox is happy we shipped it as a full source package | 18:29 | |
| infinity | Likely for the best that you're not. :P | 18:29 |
| xnox | well i'll move to portland to rotate into the kernel team | 18:31 |
| infinity | Moving to Portland gets you rotated into management. | 18:31 |
| sarnold | look if you joined the channel you're going to have to move here | 18:32 |
| sarnold | don't worry you'll like birkenstocks I swear | 18:32 |
| infinity | I hear the current administration is very sympathetic to Russians. No better time to immigrate. | 18:33 |
| ejat | hi, why gnome-session-bin & gnome-session-common package version in eoan still 3.33.92-1ubuntu1 where gnome-shell already 3.34.0-1ubuntu1? | 19:24 |
| seb128 | ejat, because no-one updated gnome-session yet, but there are no change out of translations in the update ... | 19:25 |
| * ejat facing re-login issue (cant login)after locking screen / come back from sleep | 19:26 | |
| ejat | how to debug/get the log | 19:27 |
| ejat | just recently i faced this issue | 19:27 |
| ejat | using eoan -proposed | 19:28 |
| ejat | anyone can advise me how to debug/get log can't login after locking screen/ come back from sleep ? | 19:47 |
| ahasenack | can you switch to a console? ctrl-alt-f2 for example | 19:56 |
| * gQuigs has found ctrl-alt-f5 the most reliable, with the way gdm/gnome-shells now work.. | 20:00 | |
| ejat | ahasenack: yups ... like gQuigs say | 20:00 |
| mwhudson | infinity, xnox: i'm all for making the ISO layout simpler but it's not going to be hard to get subiquity to not put file:///cdrom in sources.list if it's not there | 20:33 |
| mwhudson | also my last attempt to simplify casper-helpers broke two other things i had no idea existed so eh | 20:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!