[12:50] <Teduardo> Hi, is anyone still in this channel?
[12:52] <CarlFK> sure
[12:53] <Teduardo> I've just been having an issue understanding why the Ubuntu 20.04 autoinstall creates a 100% VG but only a 1% LV/filesystem by default if you don't specify a storage: block in the autoinstall file.
[12:54] <Teduardo> I sent a report to the ubuntu-installer mailing list and there hasn't been any response as of yet.
[13:03] <CarlFK> I probably cant help you, but I;m curious.  can you pastebin your autoinstall file?
[16:55] <xnox> Teduardo:  hi
[16:55] <xnox> Teduardo:  there were some bugs about it, and if you refresh the snap when offered it will use "better" defaults.
[16:55] <xnox> Teduardo:  it is intentional, to not use all of the VG, as otherwise one cannot make any snapshots at all, or resize things.
[16:57] <xnox> Teduardo:  you can see discussion about the design at https://github.com/CanonicalLtd/subiquity/pull/737
[16:58] <xnox> If disk is less than 10GB, use all of it.
[16:58] <xnox> If disk is between 10GB and 20GB, use 10GB.
[16:58] <xnox> If disk is between 20GB and 200GB, use 50%.
[16:58] <xnox> If disk is larger than 200GB, use 100GB.
[16:58] <xnox> is the current implementation (if you choose to update subiquity snap to latest)
[16:58] <xnox> Teduardo:  can you explain why you want the rootfs LV to use the whole space?
[19:09] <Teduardo> Refresh the snaps? I am using the daily iso to do the install because whomever decided to get rid of the netboot images
[19:11] <Teduardo> Well, if you are installing to a physical machine with one disk in it, it doesnt really make sense to me that it would create a 100% VG and then a 1% LV and 1% filesystem.
[19:11] <Teduardo> It's not really going to be resized in my environment anyway
[19:12] <Teduardo> Also the larger issue I have is that I would expect that if you completely avoid putting a storage: stanza in the auto install config file that what it would do is basically the exact same thing as just hitting enter and accepting the defaults in the installer
[19:12] <Teduardo> but it seems to do something totally different
[19:13] <Teduardo> which is pretty confusing
[19:20] <Teduardo> Is there a simple command that I can put into the storage: configuration to tell it to do exactly what it is doing by default except make the LV and the FS use the rest of the space of the VG?
[19:21] <Teduardo> I looked at the generated autoinstall configuration (the log from the install) file but it's sort of difficult to understand what is happening in there.
[19:22] <xnox> Teduardo:  "except make the LV and the FS use the rest of the space of the VG" => you mean whichever drive is being guided partitioned, create PV over most of it, create VG out of that, and create LV which uses all of it?
[19:22] <xnox> Teduardo:  but why do you want LVM at all then, why not just use ext4 => that defaults to using the whole drive by default.
[19:22] <xnox> Teduardo:  having LV use 100% of the VG space does not make sence.
[19:23] <xnox> Teduardo: if installer iso you are using, is not the latest one, it offers to self-update (or one can specify refresh key to do that in autoinstall.yaml)
[19:23] <xnox> Teduardo:  note that currently it does not use _just 1%_ it uses a lot more than that.
[19:24] <xnox> Teduardo:  what's your total disk size? Because what the default install does, is dynamic depending on your target machine disk size.
[19:24] <Teduardo> because the really easy to use kickstart interface was removed and i'm just trying to get this done. I don't care, if this was 16, 17, 18, or 19 I would just tell it to use atomic and I would move on with my life
[19:24] <Teduardo> but that no longer exists (for some reason)
[19:25] <Teduardo> It's a 480G drive and it created a 4G LV and a 4G filesystem
[19:25] <Teduardo> without me specifying anything in the storage: portion of the config
[19:26] <xnox> storage:
[19:26] <xnox>   layout:
[19:26] <Teduardo> The why I am using LVM is because that is your default if you don't specify anything for storage:
[19:26] <xnox>     name: direct
[19:26] <xnox> will do ext4, no lvm, full drive
[19:26] <xnox> i don't think we have a single key to say "use 100% of the lvm"
[19:27] <xnox> Teduardo:  note if you are getting 4G LV and 4G filesystme, you are using out of date installer
[19:27] <xnox> Teduardo:  the currnt installer would have created a 480G VG with 200G root LV
[19:27] <xnox> refresh-installer:
[19:27] <xnox>   update: true
[19:28] <xnox> is needed for the installation media, update the installer, prior to completing the install.
[19:28] <xnox> Teduardo:  are you installing VMs or bare metal? cause for VMs we provide pre-installed server images that simply self-resize on boot, and one doesn't need to provide anything to them. Just the ssh key or password for login.
[19:29] <Teduardo> its a network boot though..this is my install media
[19:29] <Teduardo> http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/focal-live-server-amd64.iso
[19:29] <Teduardo> is that not kept up to date?
[19:29] <Teduardo> It's baremetal
[19:30] <xnox> it lags a little bit, as it's gated with automatic CI testing. (i.e. i think that image is stale, cause there was new installer published in stable today)
[19:30] <xnox> i think that location will be updated by tomorrow with latest installer
[19:30] <Teduardo> so then I need to add refresh-installer: .. to the autoinstall?
[19:31] <xnox> Teduardo:  normally, for at scale, i'd recommend to install maas => cause that does one click / one api call installs & provisioning and is very easy to use and at the same time flexible / sane.
[19:31] <Teduardo> also what in the heck were the docs talking about. it said there was an autoinstall-editor snap and then a day later it was like OH MAN WE WERE KIDDING
[19:31] <Teduardo> yeah but we can only use that for ubuntu and we support 9 distros
[19:32] <xnox> autoinstall-editor is on the roadmap, we do timebase releases, and if we run out of time, we cut features =/ it will be available later.
[19:32] <xnox> Teduardo:  maas deployes ubuntu, rehl, centos, windows, freebsd, etc.
[19:32] <xnox> *rhel
[19:32] <xnox> Teduardo:  many people use maas to only ever deploy non-ubuntu, because it's that good.
[19:33] <xnox> but it is an investment.
[19:33] <Teduardo> Okay i'll look into that, we tried to use it awhile back to deploy openstack and it wasnt mature yet
[19:33] <xnox> Teduardo:  by the way, the old d-i based installers are still available for 20.04 LTS. They will not be updated in the future, but we did build them for 20.04.
[19:33] <xnox> Teduardo:  we renamed them and changed the URLs, as otherwise people would not notice that we are trying to stop producing them.
[19:34] <Teduardo> Okay, all I know is i tried to use the same syntax that I use on 16.04 to install 20.04 and it didn't know what a kickstart was so I moved on to autoinstall
[19:34] <Teduardo> ahh the installer crashed with that new storage config, i guess i'll add the refresh-installer: part and try it again
[19:35] <xnox> http://cdimage.ubuntu.com/ubuntu-legacy-server/releases/focal/release/ & http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/legacy-images/ have the legacy d-i based installer
[19:35] <xnox> Teduardo:  you can open terminal with like "ctrl+z" or switch to a different tty or help-menu/shell (F1) => and you can do ubuntu-bug subiquity => to collect logs and open a bug report
[19:36] <Teduardo> since we are just provisioning dedicated servers we really dont need very much to get them ready to go
[19:36] <xnox> Teduardo:  or open bugs on https://bugs.launchpad.net/subiquity/+filebug?no-redirect
[19:37] <xnox> Teduardo:  ack. we try hard to make autoinstall.yaml as short / as simple as possible for such a usecase. Thus ideally, I'd rather fix all the bugs for you, for you to continue to use autoinstall.yaml in the shortest form possible.
[19:37] <xnox> Teduardo:  "the install, use the full disk, sanely" should surely work.
[19:38] <xnox> Teduardo:  with latest installer without any storage config (but refreshed installer) i do expect it by default to use up 200GB for the rootfs.
[19:38] <Teduardo> Yeah but why would the autoinstall without any storage config do something different than the installer installer if you just hit enter when it asks
[19:38] <xnox> Teduardo:  teh images at http://cdimage.ubuntu.com/ubuntu-server/daily-live/20200512.1/ did not pass automated testing yet, but should be using up to 200GB already.
[19:38] <Teduardo> Sorry if I am being like... single minded
[19:38] <xnox> Teduardo:  it's not single minded, it's a very valid point.
[19:39] <xnox> i think that alone deserves a bug report by itself.
[19:39] <xnox> Teduardo:  may i open a bug which just says "but why would the autoinstall without any storage config do something different than the installer installer if you just hit enter when it asks" basically? and start tracking that.
[19:39] <Teduardo> Normally what I do if I am being honest is run through the installer once and then I just steal the kickstart or whatever file that was generated by the installer and use that as a guide.
[19:39] <xnox> Teduardo:  i think the intention was, to not do any weird surprises there =)
[19:40] <xnox> Teduardo:  the "generate matching autoinstall.yaml at the end of the install" => is on the roadmap, but didn't make it on time.
[19:40] <xnox> Teduardo:  we hope to have a lot of this done by 20.04.1 in July
[19:40] <Teduardo> ahhhh okay so what is in the autoinstall log isn't actually what it's even doing
[19:40] <Teduardo> thats REALLY confusing lol
[19:41] <Teduardo> but i understand timelines and all that
[19:41] <CarlFK> Teduardo: I have a similar case: use the interactive install to debug/test/isolate wonky automated installs glitches
[19:41] <xnox> https://bugs.launchpad.net/subiquity/+bug/1878281 => opened a bug report saying that it is unexpected that interractive != autoinstall.yaml storage layout "default choice"
[19:42] <xnox> Teduardo:  subiquity is a UX frontend, which parsers things / takes user input, generates curtin config, which then tries to blast disks with ubuntu / configure them, etc.
[19:43] <xnox> Teduardo:  the autoinstall.yaml stuff is "use cloud-init metadata source, to pre-empt subiquity interractive ui, answer things, and do it's thing" => a bit of a pipeline approache. So yes, there are multiple times when things get interpreted and derived.
[19:43] <xnox> Teduardo:  thus some files that one can find on /var/log/installer after the install, are not actually the inputs one would override.
[19:43] <xnox> Teduardo:  https://bugs.launchpad.net/subiquity/+bug/1878281 can you please "subscribe" to that bug report to be notified when it is fixed?
[19:43]  * xnox doesn't want to loose contact with you
[19:45] <Teduardo> Cool ot
[19:45] <Teduardo> it's installing now I'm interested to see what it does after changing the configs.
[19:49] <Teduardo> Hurray, it did exactly what you said that it would. Thanks.
[20:02] <CarlFK> xnox: is there a name for the new installer?  to differentiate it from "d-i based installer"
[20:09] <xnox> CarlFK:  the new installer & the legacy installer
[20:09] <xnox> CarlFK:  the snap which runs the installer, and the git repository, are called "subiquity" but that is a codeword that makes no sense, and it's not a public/user/marketing name at all.
[20:09] <xnox> CarlFK:  because it's just "the installer".
[20:09] <xnox> CarlFK:  i guess d-i is technical term too.
[20:10] <xnox> CarlFK:  we also say live-server vs legacy-server (when talking about the .iso filename)
[20:10] <xnox> CarlFK:  or yeah subiquity vs d-i
[20:10] <CarlFK> subiquity
[20:11] <xnox> CarlFK:  note that both of technogoies have many media formats. Cause there is full-fat legacy-server.iso (~700MB) and there is live-server.iso (~700MB), but also one can extract initrd/kernel from live-server (which is like ~50MB) and netboot that.
[20:11] <xnox> ditto, one can netboot mini.iso (which is liek ~150MB)
[20:12] <CarlFK> thanks.  needed something for a git comment