[06:09] <lordievader> Good morning
=== cpaelzer__ is now known as cpaelzer
[11:21] <Peanut> Hi - I'm trying to install Ubuntu-server 21.04, but it seems there is no netboot.tar.gz or anything similar any more?
[11:21] <mgedmin> no (and it was never a supported install method)
[11:21] <mgedmin> you can netboot the -live-server.iso
[11:23] <Peanut> It wasn't? I've used it for many years, we have an install server for Debian and Ubuntu netboot/pxe.
[11:24] <mgedmin> discourse.ubuntu.com has several discussions about this
[11:25] <mgedmin> canonical's official position is that it's hard to support all the possible nonstandard installation methods (debootstrap, mini.iso, etc.) and so they're only supporting -live-server.iso and the cloud VM images these days
[11:26] <rbasak> I'm not sure about the status of the legacy images. The current method for netboot is documented at https://ubuntu.com/server/docs/install/netboot-amd64
[11:33] <Peanut> mgedmin: I see. It looks like this new method is quite different, sorry to hear that the simple netboot method has been dropped. I'll see if I can get this to work.
[11:41] <Peanut> rbasak: Thanks for the link. It seems that the pxelinux files are not available for hirsute unfortunately.
[11:44] <rbasak> Peanut: I think that's an oversight/bug
[11:45] <rbasak> Peanut: pxelinux.0 is fairly independent of the OS release. You can probably use http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/legacy-images/netboot/
[11:45] <rbasak> (for pxelinux.0, not the others)
[11:46] <Peanut> rbasak: Ok, thanks, I have those already on my install server.
[12:01] <Peanut> X9DR3-F/i
[12:01] <Peanut> Oops!
[12:02] <mgedmin> password change time!
[12:03] <Peanut> *laugh* no, I don't use ancient SuperMicro mainboard product IDs as my password.
[12:03] <rbasak> Using ancient SuperMicro mainboard product IDs as your password was a clever idea. Provides plausible deniability when you accidentally leak it :-P
[12:10] <Peanut> Using an ancient SuperMicro mainboard however is a pretty poor idea, the thing won't netboot.
[12:10] <Peanut> But that's not an Ubuntu problem.
[12:12] <unwatchedtarget> Unable to webcam working on Macbook Air 2015. Any help ?\
[12:21] <rbasak> unwatchedtarget: try #ubuntu? This channel is for Ubuntu Server.
[12:22] <unwatchedtarget> ok
[15:35] <Peanut> Well, I've manged to install 21.04, sort of - I'm quite unimpressed by this new installer. It installed more than 9 GB, and so far is unusable because the network interfaces change name on every reboot (wasn't that fixed ages ago?)
[15:39] <Peanut> The two interfaces seem to get into a race to see who gets to be named eth0 or eno0, so sometimes I have eno0/eth0, sometimes eno0/eno1, and at the moment it's eno1/eth1 which is utterly ridiculous :-)
[17:37] <teward> Peanut: um... that doesn't sound like an issue with the installer.  `eno0 or eno1` will be based on firmware/BIOS, if something else is renaming it to `eth` then that's something else taking precedence - kernel naming as failover when it can't get firmware/bios data
[17:38] <teward> (https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ explains that behavior).
[17:38] <teward> i've *never* seen a case where the installers (even 21.04) will not obey ^^ that
[17:38] <teward> (and I did some 21.04 testing)
[17:43] <teward> Peanut: the other cases I think are if `biosdevname` is installed or you have udev rules changing the names, those will take precedence.  not sure if either of those got installed on your environment.
[17:49] <Peanut> teward: Thanks for your reply. This is a clean install of 21.04, biosdevnames is not installed because the package no longer even exists (it existed in Bionic, but not in Focal or later).
[17:51] <Peanut> If, after an install from the network (which populated /etc/netplan/something.yaml) you end up with a system without working network, I would call that a significant issue with the installer.
[17:59] <rbasak> Peanut: sounds like a bug somewhere but one that is elsewhere than the installer.
[17:59] <teward> ^^
[17:59] <teward> i'd point at firmware usually
[17:59] <rbasak> Because interface name fixing needs to happen all the time (eg. if you hotplug a NIC or plug in a PCI NIC) rather than just at install time.
[18:00] <teward> you... could reprogram the YAML and use a match argument to always match the network data
[18:00] <teward> it won't fix the incorrect-yaml on install but will fix permanently going forward
[18:04] <teward> Peanut: https://paste.ubuntu.com/p/2JTYV5Z2Vh/ for a static config example, https://paste.ubuntu.com/p/FXjJdGtXTP/ for DHCP
[18:04] <teward> adjust config accordingly
[18:04] <teward> this will guarantee that regardless of how the BIOS / system would detect the interface, the interface will always match and get the name 'mainif' in the configs
[18:04] <teward> (these are based on the examples from https://netplan.io/examples/ )
[18:05] <teward> so if you consistently have a problem where your system is not getting a set interface name / ID because of whatever firmware issue you're having that is making Ubuntu have that issue (it's NOT an installer problem) then you can fudge it into place by using match-defined named interfaces.
[18:06] <teward> which, if the system is consistently failing and falling back to unpredictive naming, then i'd use a match-based interface declaration to make sure the interface is defined properly in a way that is consistent.
[18:08] <teward> just to make a point i have a server that sits on the WAN link and an internal network link, and I use match definitions to name them accordingly - wan, lan## (for VLAN ID because it's an access port on the switch it's connected to)
[18:08] <teward> so i'm pretty familiar in how to make things work when the system out of the box does not with network matching/configuration ;)
[18:10] <teward> Peanut: and I'm assuming the MAC address of your device isn't changing, so that should match properly in either example.
[18:16] <Ussat> I have NEVER had an issue with interfaces "changing" on reboot, ubless I physically change the interface/nic
[18:16] <Ussat> teward, and yes I have a setup like that also and use match directive
[19:09] <Peanut> teward: Thanks for your replies - I was heading home for some dinner (shouldn't stay in the office till 8pm!). I had indeed already added 'match' directives to somewhat sidestep the issue. The machine now does come up with networking, but it still hangs for a long time during boot where systemd says that it is waiting for the network to start.
[19:11] <Peanut> Ussat: I've been installing Ubuntu boxes for over a decade, and network interfaces renaming themselves is unfortunately somewhat of an endemic problem. I though systemd had finally fixed that, but perhaps that's now in a race condition with netplan? On my other servers, I don't even install netplan, and that's been very steady with the long interface names (enp3s189f0 and the like)
[19:16] <sarnold> Peanut: netplan only generates systemd-networkd configuration files
[19:16] <sarnold> Peanut: you can write those yourself if you'd rather
[19:20] <Peanut> sarnold: I'd rather keep using /etc/network/interfaces, these are servers with completely static networking configs, so any additional steps just lead to more confusion and failure modes.
[19:38] <Ussat> Peanut, I run..a lot, and have NEVER had that issue
[19:39] <Ussat> I use netplan with completely static, almost everything I have is static
[19:40] <Ussat> if you MUST;  https://askubuntu.com/questions/1031709/ubuntu-18-04-switch-back-to-etc-network-interfaces
[19:40] <Ussat> i DONT RECCOMEND
[19:41] <Peanut> Ussat: BUT I'M DOING THAT ALREADY! ;-)
[19:41] <Peanut> And on 20.04, too..
[19:41] <Ussat> https://netplan.io/faq/#how-to-go-back-to-ifupdown
[19:41] <Peanut> Actually, I end up removing netplan, resolvconf and a few other things that just make absolutely no sense to me - perhaps I should give Devuan a try.
[19:41] <Ussat> TBH I have never had the issue of interfaces randomly changing
[19:42] <Ussat> "give Devuan a try" um....sure
=== not_phunyguy is now known as phunyguy
[20:57] <Ussat> few other things that just make absolutely no sense to me <<--- scary
[20:58] <teward> Peanut: I think you've got a larger problem than 'netplan' here - the fact you don't have any idea how these things work is a larger problem than you're going to encounter.  The longer you try and stick with `ifupdown` the more and more you won't be able to get support for your infrastructure.  When the netplan switch happened I was in the same boat, but once you actually get an understanding of the netplan configuration it's scarily
[20:58] <teward> simple compared to ifupdown
[20:58] <teward> resolvconf is equally important, etc.
[20:59] <teward> if none of these core components make sense, you should probably consider hiring a linux admin instead of trying to keep yourself on the legacy obsolete things.
[21:01] <Peanut> teward: It looks scarily simple, and it would be - if it actually worked. Your other comments are uncalled for and unfriendly.
[21:02] <Ussat> teward, I was also in that boat, but after useing netplan, I REALLY like it
[21:02] <teward> Ussat: i dont' disagree I love it
[21:03] <Ussat> OH NO...safe space neded
[21:03] <Ussat> Peanut, I really does work quite well
[21:10] <teward> which comments?  keeping yourself on legacy software, or hiring an admin?  I should point out SysvInit is even older than netplan, and MOST distributions have switched from it.  "Unfriendly" is an opinion but I don't believe I was actually being intentionally unfriendly, just making a point.
[21:11] <teward> if you don't like the decisions Ubuntu has made in terms of the way the OS will move forward then yes perhaps Ubuntu is not for you, except we've been using SystemD and Netplan since 2018 with LTSes so...
[21:35] <Peanut> Telling someone to 'hire an admin' is pretty condescending, and definitely the opposite of being helpful when someone tries to discuss actual buggy behaviour. I'm glad these services work well for you, enjoy.
=== de-facto_ is now known as de-facto