| mup | Bug #1868915 opened: [focal] nm-online -s --timeout=10 timeout every time <amd64> <apport-bug> <focal> <third-party-packages> <uec-images> <MAAS:New> <OEM Priority Project:New for alextu> <network-manager (Ubuntu):New> <https://launchpad.net/bugs/1868915> | 05:05 |
|---|---|---|
| mup | Bug #1868915 changed: [focal] nm-online -s --timeout=10 timeout every time <amd64> <apport-bug> <focal> <third-party-packages> <uec-images> <MAAS:New> <OEM Priority Project:New for alextu> <network-manager (Ubuntu):New> <https://launchpad.net/bugs/1868915> | 05:08 |
| mup | Bug #1868915 opened: [focal] nm-online -s --timeout=10 timeout every time <amd64> <apport-bug> <focal> <third-party-packages> <uec-images> <MAAS:New> <OEM Priority Project:New for alextu> <network-manager (Ubuntu):New> <https://launchpad.net/bugs/1868915> | 05:23 |
| ivve | anyone know of a way to edit any default A records that maas creates? it has created record on the wrong interface | 10:03 |
| ivve | there is no way to find/manipulate them with the maas cli | 10:08 |
| ivve | they are not editable via the GUI | 10:09 |
| ivve | doesn't seem like an easy task in the DB | 10:09 |
| tosaraja | Having a problem with the "Fetching netbook image" @ boot. What we've done is we have set the VLAN tag in UEFI to match our network vlan. We manage to download the bootx64.efi image from MAAS. But after that it goes to "Fetching netboot image" and sticks there. What I am guessing without knowing how things should work, is that our UEFI tells the network card correctly to vlan tag the traffic. And it manages to do so and fetches the bootx64.efi. | 12:14 |
| tosaraja | But after the .efi package has arrived and we start fetching the next stuff, it just fails, because it is untagged. If we change the native vlan from the switch to match the vlan value we use, MAAS starts deploying just fine. So it seems the traffic beyond the first package isn't vlan tagged. How would I proceed in fixing that? | 12:14 |
| tosaraja | Do have to "edit" the bootx64.efi somehow to inform that traffic beyond this point should be vlan tagged, or is this a bug in Dell's UEFI / PXE code that it stops tagging the traffic? | 12:14 |
| tosaraja | The idea is that we don't want to adjust the switch's native vlan as it is not controlled by us | 12:16 |
| mordkoff | hi | 16:33 |
| mup | Bug #1869067 opened: maas-http service changing perms on system nginx paths <MAAS:New> <https://launchpad.net/bugs/1869067> | 19:25 |
| mup | Bug #1869067 changed: maas-http service changing perms on system nginx paths <MAAS:New> <https://launchpad.net/bugs/1869067> | 19:28 |
| mup | Bug #1869067 opened: maas-http service changing perms on system nginx paths <MAAS:New> <https://launchpad.net/bugs/1869067> | 19:31 |
| ltrager | tosaraja: tagged network booting typically doesn't work. From what I've seen in the past most firmware implementations don't support it | 20:54 |
| ltrager | tosaraja: bootx64.efi is signed so editing it will break secure boot. I'm not even sure what you would edit | 20:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!