[10:47] <lordievader> Good afternoon.
[10:49] <BluesKaj> G'Day folks
[11:24] <BluesKaj> Hi again
[17:42] <teward> has anyone seen network interfaces named `ens##` in virtual environments instead of `eth##` for Wily?
[17:42] <teward> (whereas installer disks see `eth##`)
[17:43] <lordievader> ens? Not enp?
[17:44] <teward> mhm
[17:45] <teward> also, installer set up the interfaces file with eth0, eth1, so networking didn't come up (this is the server iso but still)
[17:45] <teward> (so I had to write /etc/udev/rules.d/70-persistent-net.rules to assign the names)
[17:46] <teward> lordievader: it threw me for a loop too
[17:46] <teward> and there's a discrepancy between the installer ISO and what's actually installed
[17:46] <teward> so IDK where to report such issues
[17:46] <teward> or what to file against
[17:46] <teward> and it wasn't part of the ISO testing, i needed the VM set up for package change verify-it-works ness :P
[17:47] <lordievader> Hmm, well we should be moving to bios names sometime soon. But ens is new for me, perhaps because it is virtual, but nic's are named as enp with me.
[17:48] <teward> lordievader: that still doesn't explain why /etc/network/interfaces was populated with eth#, nor why the installer ISO read the interfaces as eth#
[17:48] <lordievader> True, true.
[17:48] <teward> and that shows the bigger problem of if the ISO doesn't correctly configure the /etc/network/interfaces on install, you get a nuked network routing table and connectivity
[17:49] <TJ-> the naming is done by systemd now, isn't it?
[17:49] <teward> and it's a damn good thing i keep a 70-persistent-net.rules file template lying around
[17:49] <teward> TJ-: if it is, does that explain the discrepancy between installer naming and system naming?
[17:49] <teward> and does that explain the broken /etc/network/interfaces upon install?
[17:49] <lordievader> Still udev right? Though udev and systemd share a lot.
[17:50] <lordievader> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
[17:50] <lordievader> Hmm, perhaps it is systemd..
[17:50] <teward> lordievader: i had to put a udev override
[17:51] <teward> but there's still that ISO/installed discrepancy
[17:51] <teward> that will make people be "WTH Y DOESNT IT WORK"
[17:51] <teward> (and this was the daily iso from yesterday)
[17:51] <teward> "Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)"  <-- explains the ens##
[17:51] <teward> does NOT explain why only 2 cards got ens33 and ens35
[17:52] <teward> (at least from the guest os's perspective)
[17:52] <teward> I am much more concerned about the ISO seeing the kernel style naming versus the installed version using systemd and the predictable method in that link
[17:54] <lordievader> Ah, thanks for clearing that up :)
[17:55] <TJ-> what init system does the installer use?
[17:59] <teward> can't tell i can only get a busybox prompt o.O
[17:59] <TJ-> unpack the squashfs image, if that's what it is
[18:00] <lordievader> No ps in busybox?
[18:03] <teward> /bin/busybox init  <-- that
[18:03] <lordievader> Sounds like sysv/upstart.
[18:04] <teward> so what do i file the bug agains
[18:04] <teward> because this is a HUGE issue
[18:04] <TJ-> teward: I'm pulling in the ISO to try in a VM
[18:05] <teward> TJ-: i have two interfaces attached, one NAT, one host only
[18:05] <teward> i use VMware
[18:05] <teward> VBox might be different
[18:06] <TJ-> I use neither :)
[18:06] <lordievader> KVM?
[18:06] <TJ-> but of course :)
[18:07] <TJ-> I have several servers here with multiple interfaces so I can test it on those
[18:07] <lordievader> Whoop whoop
[18:19] <TJ-> teward: is it booting UEFI or BIOS?
[18:25] <teward> TJ-: I think BIOS, within VMware
[18:25] <teward> any way to find out from the shell?
[18:32] <TJ-> "ls /sys/firmware/efi/vars/"
[18:33] <teward> no such dir
[18:33] <teward> no efi dir either
[18:33] <teward> so probably BIOS
[18:33] <TJ-> OK, so BIOS
[18:40] <TJ-> I've found another bug... missing kernel package!
[18:44] <teward> o.o
[18:52] <teward> TJ-: did you try a BIOS boot yet, and what did you find?  I see the +UEFI boot issue in -devel you just said
[18:59] <TJ-> I'm about to try it... but it wont make any difference. The detection happens from within the /target/ chroot and the device names will already have been set