[06:57] <punkgeek> I have a fully encrypted Ubuntu server. I have enabled the password request to access GRUB editing mode, but it is not required during the OS boot-up process. To automatically unlock the LUKS password request during boot-up, I have installed the initramfs and dropbear packages and configured them as follows:
[06:58] <punkgeek> https://paste.ofcode.org/33dZB2y5bEdBrUc4Atq7RZ5      How can a person reset the root password and access the system files in this scenario? Because, as I understand it, initram is compiled and cannot access initramfs without the root password.
[07:37] <alkisg> punkgeek: put init=/bin/bash in grub, then run: mount -o remount,rw /; passwd
[10:09] <webchat62> i have ubuntu 20.04 machine running which was deployed form one cloud template ,initially it had got ip 10.79.197.24 eth0 interface
[10:09] <webchat62>  if we run dhclient -v then one more new ip is getting assigned from dhcp server even though server had ip assigned
[10:09] <webchat62>  if i run dhclient -v again then it says RTNETLINK answers: File exists
[10:09] <webchat62>  on what basis it decides where to get new ip or to say RTNETLINK File exists
[10:09] <webchat62> i have added dhclient debug data in below file
[10:09] <webchat62> https://dpaste.com/96N3H25UZ.txt
[12:31] <athos> rbasak, kanashiro[m], IIRC, there is no git repository to add packages to the server packageset, is this correct? The correct path should be to email the DMB (or would that be the AAs?) for additions, is this correct?
[12:32] <athos> All I could find was https://wiki.ubuntu.com/ArchiveAdministration#Package_sets
[13:00] <rbasak> athos: correct - please ask devel-permissions@
[13:09] <athos> thanks, rbasak!
[14:20] <Teridon> this storage config works when I boot/install via PXE/BIOS but NOT when I attempt to install ipxe/UEFI  -- I get the error "autoinstall config did not create needed bootloader partition"   But I am creating an ESP/EFI partition, formatting it, and mounting  it at /boot/efi:  https://dpaste.org/u7Rjf
[14:24] <Teridon> here's what fdisk is reporting:  https://dpaste.org/fQnBV 
[14:42] <Teridon> not sure if this is progress or not, but I was missing the "esp" flag from the ESP partition, and also the "boot" flag from the boot partition .  So now I don't get an error, but instead autoinstall drops me to the interactive installer?
[14:46] <Teridon> and now it's the same for both BIOS boot and UEFI boot (both fall back to interactive installer; asking me language)
[14:47] <Teridon> do I need a different storage config for BIOS boot/install ? 
[14:48] <Teridon> i.e. is it possible for the same storage config to work for both? 
[16:11] <alkisg> Teridon: if you're asking "can the same disk be bootable under both bios and uefi", the answer is "yes", you just need both grub-efi and grub-pc, and a bios_grub partition
[16:33] <Teridon> alkisg: ok, thanks.  Any idea why what I'm doing doesn't work for EFI?  ( https://dpaste.org/u7Rjf -- except I also tried adding the "esp" flag to the "part_efi" partition)
[16:37] <alkisg> Teridon: is that a cloud init file? Sorry I'm not using that at all
[16:38] <Teridon> yes, it's cloud-init.  maybe it would be better to ask:  can someone provide an example cloud-init storage config that works for UEFI?  
[16:44] <dbungert> Teridon: this particular bit of yaml is process by Subiquity and Curtin, not cloud-init, and curtin is known to not support dual BIOS and UEFI boot.  I suggest removing the BIOS boot part and seeing if the rest is fine.
[16:45] <Teridon> dbungert: OK will try
[17:01] <Teridon> well, I'm not getting the missing bootloader error any more, but it's falling back to the interactive installer for some reason.  Does that mean my storage config is valid?  
[17:42] <evit> If I'm trying to uninstall Mysql and replace it with MariaDB do I need to also remove /etc/mysql & /var/lib/mysql? 
[18:43] <sdeziel> evit: can you describe the issue you are running into when just uninstalling mysql and installing mariadb?
[18:44] <evit> @sdeziel, I'm not running into any issue. Just wondering if I should also remove /etc/mysql and /var/lib/mysql
[18:46] <sdeziel> evit: For a clean switch, I would probably use `apt-get autopurge mysql...` prior to installing mariadb. That should take care of those directories automatically (or maybe let you know why they were left behind).
[18:48] <evit> Soo... sudo apt autopurge mariadb-server mariadb-client
[18:49] <sdeziel> evit: no, the autopurge is to remove the mysql packages
[18:51] <evit> sudo apt purge mysql-server*
[18:51] <rbasak> lvoytek: o/ I would still like an upstream report for revert-be8348a7.patch please. I appreciate that upstream may just say "unsupported" again, but still, I think we need that to be stated by upstream. It will help inform future decisions wrt. things like keeping mysql in main if it's demonstrable that we're carrying a big pile of patches that they won't accept or fix.
[18:52] <rbasak> On the ppc failure, is that just an OOM killer for a memory exhaustion issue? That might be related to the amount of memory available on the autopkgtest machines.
[18:52] <rbasak> (rather than an upstrema issue). ahasenack or paride might be able to help with that.
[18:53] <rbasak> lvoytek: or if there's some kind of public statement from upstream asking us not to file those or that they do not accept such reports, then we could link to that in our dep3 headers or similar in place of an upstream report.
[18:54] <ahasenack> hmm? What's up?
[18:54] <ahasenack> I heard mysql and ppc
[18:55] <ahasenack> (besides my name)
[18:55] <rbasak> That relates to https://salsa.debian.org/mariadb-team/mysql/-/merge_requests/67/diffs?commit_id=49b324ea7ec8720fea71009b6212253f3fb95a13
[18:55] -ubottu:#ubuntu-server- Merge 67 in mariadb-team/mysql "Update to 8.0.33" [Opened]
[18:55] <rbasak> And https://bugs.mysql.com/bug.php?id=111091
[19:13] <lvoytek> rbasak: sounds good, I'll check on the revert upstream report. For ppc it might be OOM from what upstream stated. I'll look into it more though
[19:31] <ahasenack> there were OOM incidents in mysql dep8 tests, I moved the package to big_packages iirc
[19:38] <rbasak> Yeah I wondered big_packages might need to be involved somehow, but I'm not current on the details of how that all operates (hence my mention)
[19:41] <evit> @sdeziel, Thanks for your help!
[20:07] <ahasenack> rbasak: lvoytek: mysql-8.0 is on big_packages only on amd64 and arm64, not ppc64el
[20:07] <ahasenack> so we can try that before disabling the test
[20:09] <ahasenack> https://git.launchpad.net/~ubuntu-release/autopkgtest-cloud/+git/autopkgtest-package-configs/tree/big_packages#n231
[20:12] <lvoytek> ahasenack: Thanks for looking into that, sounds good to me
[20:13] <ahasenack> it was samba that I moved to big_packages for ppc64el
[20:14] <ahasenack> lvoytek: this is the MP I did for mysql-8.0 back then, for amd64/arm64: https://code.launchpad.net/~ahasenack/autopkgtest-cloud/+git/autopkgtest-package-configs/+merge/438389
[20:15] <lvoytek> ahasenack: Thanks for the reference, I'll submit an mp for it
[21:31] <lvoytek> mp accepted, running autopkgtests
[22:42] <lvoytek> Confimed that moving mysql ppc64el to big_packages fixed the issue