rootfs: fix grub.cfg generation when using pkg-linux-qcom kernel package

The /etc/kernel/postinst.d/zz-update-grub hook (grub-common) guards its
update-grub call with a systemd check:

  if [ -d /run/systemd/system ]; then update-grub || true; fi

In a chroot environment systemd is not running, so /run/systemd/system
does not exist and update-grub is silently skipped. This left
/boot/grub/grub.cfg absent, causing the subsequent sed-based GRUB
cleanup to fail with:

  sed: can't read /boot/grub/grub.cfg: No such file or directory

The build-kernel-deb.sh-generated package calls update-grub directly in
its postinst (unconditionally), so it was unaffected. The pkg-linux-qcom
package follows the Debian standard of delegating to postinst.d hooks,
which exposed this chroot-specific gap.

Fix: call update-grub explicitly in the chroot immediately after kernel
installation, bypassing the systemd guard. No changes to the kernel
package postinst — grub.cfg generation is the build script's
responsibility in a chroot context.

Signed-off-by: Bjordis Collaku <bcollaku@qti.qualcomm.com>

Author: bjordiscollaku

rootfs/scripts/build-rootfs.sh

@@ -551,6 +551,10 @@ echo '[CHROOT] Installing custom firmware and kernel...'
 $CMD_FW_INSTALL
 yes \"\" | dpkg -i /$(basename "$KERNEL_DEB")
 
+# Run update-grub explicitly: the zz-update-grub hook skips it in a chroot
+# because systemd is not running (/run/systemd/system absent).
+update-grub
+
 adduser --disabled-password --gecos '' qcom
 echo 'qcom:qcom' | chpasswd
 usermod -aG sudo qcom