bitmage
commented
2 years ago Additional Configuration
I don't think these are relevant for troubleshooting the grub-reboot issue. But I'll post them here for anyone else wanting to follow along or replicate this process.
grub.cfg modifications
These lines are appended to the grub.cfg with the intention of providing a remote upgrade option. The kernel parameters are set as directed in the k3OS Installation Instructions.
menuentry "k3OS Upgrade" {
search.fs_label K3OS_STATE root
set sqfile=/k3os/system/kernel/previous/kernel.squashfs
loopback loop0 /$sqfile
set root=($root)
linux (loop0)/vmlinuz k3os.mode=install k3os.install.silent=true k3os.install.device=/dev/sda k3os.install.config_url=http://192.168.1.2:1313/agent.yaml k3os.install.iso_url=http://192.168.1.2:1313/iso/k3os-amd64-v0.22.2-k3s2r0.iso
initrd /k3os/system/kernel/previous/initrd
}In addition the first line of the file is set to:
set default=savedWhich should instruct grub to read from the parameters described in the issue above.
agent.yaml
This file is served from my laptop using node-static and the command static . -p 1313 -a 192.168.1.2. It's ephemeral - only served during the installation.
ssh_authorized_keys:
- ssh-rsa [redacted]
- bitmage@[redacted]
# change this manually with each install
hostname: laba2
k3os:
dns_nameservers:
- 192.168.1.1
- 8.8.8.8
- 1.1.1.1
ntp_servers:
- 0.us.pool.ntp.org
- 1.us.pool.ntp.org
password: [redacted]
server_url: https://192.168.1.10:6443
token: [redacted]
k3s_args:
- agentThe install ISO listed in the command line parameters is being served by the same node-static instance.
If everything were working properly, this should allow remote flashing of the operating system followed by a reboot into the default grub menu "0" which would boot the new OS normally.
Version:
Kernel:
Machine:
Intention
My intention is to remotely upgrade the operating system on a cluster of 12 machines. If
grub-rebootworks properly it will allow me to instruct via SSH for the machine to reboot once-only into a system upgrade, as described in the k3OS kernel command line documentation. Once I'm satisfied with the behavior I can automate it using a shell script.Defect Summary
In my experience so far,
grub-rebootsets thenext_entry, viewable fromgrub-editenv list, but the machine does not actually respect this setting on the next boot.Steps
I did the following:
/boot/grub/grub.cfg(see Additional Information below for full text)./boot/grub/grub.cfgto readset default=saved.grub-set-default 0grub-reboot 4rebootObservation
Machine reboots, comes to the grub menu and the first option "0" is still selected, and boots after a few seconds.
Expected
It should boot from the fifth option "4". (zero indexed)
Additional Information
grub-editenv listprints out:So I know the preference is being saved, but it's not being respected on reboot. To my knowledge and awareness the
set default=savedon line 1 of/boot/grub/grub.cfgshould instruct grub to read from this environment value. I have also modified/etc/default/grubto addGRUB_DEFAULT=saved, but this parameter also does not affect the boot behavior.On reboot also I notice that
next_entryis not modified... So grub does not appear to be interacting with this in any way.There are different versions and ways to configure grub. The articles I'm reading on this subject have not so far pointed me to how the k3OS configuration might be different, and what would need to be adapted for the desired outcome to be achieved. Appreciate any insights or adjustments that I could try.