[00:00] <Voxel> dbungert
[00:00] <Voxel> , it seems this one worked!
[00:00] <Voxel> At least, it started installing!
[00:00] <Voxel> https://i.imgur.com/u3SUcUS.png
[00:00] <sarnold> yay :)
[00:00] <Voxel> That's a relief...
[00:01] <Voxel> I'm currently installing using IPMI KVM and Virtual ISO network drive. 
[00:01] <Voxel> Interesting that when starting the live ISO, it verified integrity ~2 hours!
[00:02] <Voxel> https://i.imgur.com/T61cjFM.png this one
[00:02] <Voxel> verifies*
[00:03] <Voxel> Perhaps, the ISO is transferring to the server during that verification.
[00:04] <mwhudson> are you using some very slow virtual iso thing?
[00:04] <mwhudson> you can disable the verification on the command line
[00:04] <Voxel> This feature: https://i.imgur.com/Y8NA6DZ.png
[00:05] <Voxel> Perhaps, it acts like a very slow ISO thing
[00:06] <Voxel> It's IPMIView2.16
[00:08] <Voxel> Oh :(
[00:08] <Voxel> https://i.imgur.com/Fr0wuNS.png
[00:09] <sarnold> holy cow I heard those virtual isos were slow but I had no idea it was *that* bad
[00:10] <Voxel> At least, it works. I'm ~2km from the server :D
[00:10] <Voxel> Although, the connection with it ~500 Mbit/s
[00:15] <Voxel> Welp. The installation failed :(
[00:15] <Voxel> The log: https://termbin.com/u8jd
[00:16] <mwhudson> i bet the apt update run failed
[00:16] <mwhudson> can you dig out /var/log/installer/curtin.log?
[00:16] <sarnold> mwhudson: "password": "3AiK2n29ySjW...
[00:17] <Voxel> No such file
[00:17] <Voxel> These are the files: https://termbin.com/4sh9
[00:19] <mwhudson> sarnold: thats for logging into the live session
[00:19] <mwhudson> Voxel: uh where is it hidden then
[00:20] <mwhudson> Voxel: /var/log/curtin have anything?
[00:20] <sarnold> mwhudson: ah, okay, cool :) /me exhales
[00:21] <Voxel> Indeed, looks like checksum fail in the end.
[00:21] <Voxel> https://termbin.com/loz3
[00:22] <mwhudson> Voxel: grr, maybe try changing the geoip supplied mirror back to plain old archive.ubuntu.com
[00:22] <sarnold> mwhudson: your crystal ball is pretty fantastic :)
[00:22] <Voxel> Let's try!
[00:22] <sarnold> Voxel: is there an apt-cacher-ng or squid-deb-proxy in use here?
[00:22] <Voxel> No proxies were installed.
[00:23] <mwhudson> i really really need to do more mirror validation before the install, or at least make mirror errors much more obvious to the user
[00:23] <Voxel> This one? https://i.imgur.com/6PdD6So.png
[00:24] <sarnold> Voxel: yeah that should work
[00:24] <mwhudson> Voxel: yes
[00:27] <Voxel> Started
[00:30] <Voxel> Still's going
[00:30] <Voxel> https://i.imgur.com/NJortUv.png
[00:31] <Voxel> Fingers crossed ^^
[06:12] <Voxel> Install complete! ^^
[06:12] <Voxel> https://i.imgur.com/9yTBGQ1.png
[06:13] <Voxel> Thank you all very much! You're awesome ^^
[06:19] <Voxel> These are the logs, just in case if required: https://termbin.com/97tg (subiquity-server-debug.log), https://termbin.com/kl2m (curtin/install.log)
[07:01] <Voxel> Oh../
[07:02] <Voxel> It seems, it doesn't install GRUB. Is it expected?
[07:03] <tomreyn> on amd64 hosts, grub should get installed by the installer. if it didn't, this would mean something went wrong (likely a bug).
[07:05] <Voxel> :(
[07:13] <Voxel> Is it possible to install grub using live image?
[07:13] <Voxel> grub-install didn't appear on the image
[07:19] <tomreyn> https://termbin.com/kl2m says "finish: cmd-install/stage-curthooks/builtin/cmd-curthooks/install-grub: SUCCESS: installing grub to target devices"
[07:19] <tomreyn> it seems that it tried to install grub to /dev/disk/by-id/scsi-SLSI_MR9260-8i_00aabec658349ce121908a7d03b00506
[07:20] <tomreyn> but also to /dev/sda
[07:22] <Voxel> Indeed, only /dev/sda was used for installation
[07:22] <Voxel> 3 partitions were made using in-built manager: /, /home and swap
[07:22] <tomreyn> Voxel: you could install grub once more from a live system if you did a chroot mount. but i don't have the time to guide right now.
[07:22] <Voxel> No problem! I'll try ^^
[07:31] <TJ-> Voxel: the install didn't use UEFI mode. Are you trying to start the system in UEFI mode now?
[07:32] <Voxel> I believe it's old BIOS, but I'll check now
[07:33] <Voxel> Welp, that's the BIOS: https://i.imgur.com/OHAZ4iC.png
[07:33] <Voxel> It's oldy one ^^
[07:35] <TJ-> Voxel: jsut to be sure, check on the 'Boot' tab/menu (I see the date is 2010 so its on the cusp of mandatory UEFI for Windows timeframe)
[07:36] <tomreyn> "P05" sounds like it can be an early bios version for this mainboard/server model, i'd look for an upgrade there before i try anything
[07:36] <Voxel> https://i.imgur.com/k2IEXL8.png
[07:36] <Voxel> https://i.imgur.com/UOsaB0p.png
[07:37] <TJ-> Voxel: definitely looks to be BIOS not UEFI... but I've been caught out before since the makerse often still prominently lable it BIOS when it's UEFI
[07:37] <Voxel> This server ran Ubuntu server from 14 to 18 without any problems ^^
[07:37] <TJ-> Voxel: so unless you've got the boot order set incorrectly it should boot from the MR9260-8i
[07:37] <TJ-> Check the Boot Device priority, etc.
[07:38] <TJ-> looks like it uses device class lists rather than specific devices, so also check the MR9260-8i is in the 'Hard disk Drives' list
[07:38] <TJ-> Voxel: also, what do you see happen when starting the PC? 
[07:39] <Voxel> grub: no such device
[07:39] <Voxel> I'll try changing priority
[07:39] <Voxel> I see USB device. Perhaps, someone there locally inserted one
[07:39] <TJ-> Voxel: oh, so GRUB's boot.img (boot sector) is loading!
[07:40] <TJ-> Voxel: yes, that would be my guess too
[07:40] <Voxel> Indeed, it does, but perhaps from wrong source
[07:40] <Voxel> Changed to /sda to be first
[07:41] <Voxel> HEY!
[07:41] <Voxel> https://i.imgur.com/PWlnP5q.png
[07:41] <TJ-> simple solution!
[07:42] <Voxel> Ha! Someone inserted a USB storage there (~2k from here) and boot priority shifted
[07:42] <Voxel> I'll call them.
[07:42] <Voxel> Thank you very much ^^
[07:43] <Voxel> Interesting, noticed accidentally: 
[07:43] <Voxel> https://i.imgur.com/LRO6CNo.png
[07:45] <Voxel> System is booted, but after login prompt it posted the same Cloud-init: https://i.imgur.com/9rnYYZ3.png
[07:46] <TJ-> Voxel: looks correct
[07:47] <Voxel> Haha! https://i.imgur.com/Jxl9tC0.png
[07:48] <Voxel> I see, so Cloud-init is a service which started after complete boot, right? It started after MOTD.
[07:48] <Voxel> Like, it looks like Cloud-init started with posting MOTD message.
[07:52] <TJ-> Voxel: What you saw is, I think, the post-install final steps
[07:53] <Voxel> Makes sense!
[07:53] <Voxel> Thank you! The OS is amazing ^^
[07:55] <mwhudson> Voxel: glad you got there in the end
[07:55] <mwhudson> those cloud-init messages on first boot are a bit ugly, you won't get them again
[07:56] <Voxel> So much to do now!
[07:56] <Voxel> Indeed, after reboot much more less output: https://i.imgur.com/8VZSAQA.png
[07:56] <Voxel> much less* 
[07:57] <Voxel> Stay safe, People! ^^
[13:24]  * enyc meows =)
[13:29] <tomreyn> enyc: here's another reminder to please not do that.
[13:36] <enyc> ooooooooooooooo discovered my own answer was about to type out
[13:36] <enyc> "Starting from Ubuntu Server 20.04.2 the ISO images can optionally boot the installer using the HWE kernel. In this case the installed system will automatically make use of the HWE stack. "
[13:36] <enyc> I guess ryzen Servers etc etc do exist and need k5.8 k5.11 etc
[13:38] <tomreyn> ryzen is a desktop / workstation cpu, amd's server cpu's would be "epyc"
[13:38] <tomreyn> just like intel core2 vs xeon
[14:49] <shubjer0> And I would add that Ryzen has a workstation class sku (threadripper) to better differentiate 
[14:51] <shubjero> coreycb: Hi! Thanks for all the work in https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1927868 . I am testing Ussuri Neutron packages 16.4.0 but I am coming across a pretty bad issue related to rootwrap/privsep. All my neutron services are complaining about "CRITICAL oslo.privsep.daemon [-] privsep helper command exited non-zero (1)". 
[15:16] <coreycb> shubjero: Hi, you're welcome. if you think it's a bug in neutron would you be able to file a bug with more details?
[15:21] <coreycb> I doubt this is related but it was fixed recently https://review.opendev.org/c/openstack/neutron/+/793417
[15:21] <shubjero> coreycb: hopefully not and hopefully can be remedied with some configuration options. I am still investigating
[15:22] <coreycb> it's basically the only hit for rootwrap since 16.3.1
[15:23] <shubjero> Yeah, and I'm just following https://bugs.launchpad.net/neutron/+bug/1887147 at the moment. I've added step #3 [privsep] options in to my neutron.conf which seems to have calmed things down a bit but it's still some whack a mole at the moment