feat: increase size of boot partition

[LKHN]

Increase the size of boot (/boot) partition from 512 MiB to 1024 MiB.

By default the DNF package manager is configured to hold three different versions of kernel packages[^1]. While the 512 MiB boot size is enough on the majority use cases, There are other use cases where the initramfs (initial ram file system) may be bigger than usual. Since the kernel (vmlinuz) and initramfs resides on the boot partition. Even having three installed kernel may be impossible.

It is worth mentioning that rescue initramfs is larger than regular ones.

This commit aims to address this issue with incrementing the size of boot partition from 512 MiB to 1024 MiB. Such amount of size should work well nearly all situations and use cases where larger size of initramfs and more number of kernels are present on the boot filesystem.

[^1]: See installonly_limit main option ([main]) on /etc/dnf.conf

[codyro]

What's the reason you're removing/disabling the firewall in the ks?

(Modified my text to make more sense, I'm tired 😀)

[LKHN]

No worries :smile:

This kickstart command specifies the firewall configuration for the installed system. It does not make any sense for the cloud images because We built cloud images without firewall (firewalld)^1 to relay firewall technology of cloud and virtualization technology to avoid double maintenance.

For instance when you add/remove a port on a security group on OpenStack/AWS/Azure/OCI/OpenNebula etc., you also need to to the same with the firewalld inside the VM. If you don't know where to look, you can pull your hairs that why the security group is not effective.

[codyro]

Is that standard for cloud images across providers? I've always deployed mine with firewalld enabled even if there is a FW/SG/ in front of the VM (we do this for our Infra VMs as well via Ansible).

I guess what I'm asking is do people expect cloud images to have firewalld disabled by default?

[LKHN]

Is that standard for cloud images across providers?

Yes as far as I observed.

I've always deployed mine with firewalld enabled even if there is a FW/SG/ in front of the VM (we do this for our Infra VMs as well via Ansible).

As you see from the link of ansible task which removes firewalld, the firewalld package is not present on the cloud images at all. How you can get the VMs with not just firewalld package installed also the service is enabled?

I guess what I'm asking is do people expect cloud images to have firewalld disabled by default?

Do you mean generally or just for AlmaLinux OS cloud images. To be clear the firewall related change on this kickstart file never had any effect. The PR just saves Anaconda to do an action where is not needed.

[codyro]

As you see from the link of ansible task which removes firewalld, the firewalld package is not present on the cloud images at all. How you can get the VMs with not just firewalld package installed also the service is enabled?

Haha! I didn't look into the full ks but only the diff. I figured since you were disabling it entirely that the package was installed. That makes this whole curiosity superfluous!

Thanks for humoring my questions :)!

[LKHN]

Thanks a lot for your review and questions!

I hope my answers would make you and anyone to ask more. :smirk:

[micxer]

@LKHN Please add the information that firewalld is now disabled by default to https://wiki.almalinux.org/cloud/cloud-changelog.html. We found everything else there to be consistent with the commit messages in this repo, but it took us quite a while to figure out that firwalld was disabled in a PR that seemed to be related only to the size of the boot partition.

And BTW: reasoning to disable it is fully valid. It is just not expected when yo only read the changelog.

[LKHN]

@micxer , Thanks a lot for the review.

As I said on my previous replies, It doesn't affect the end result, the cloud images. Since firewall related packages are removed as a part of Ansible provisioner of Packer^1.

The firewall has always been disabled. If this change would change the end result then I would create a separate commit and PR and entry on the changelog.