Dump bootactions

[tcooper]

It would be nice if the custom bootactions could be saved by rocks dump.

[tcooper]

Tested in dev...

# rocks dump bootaction
/opt/rocks/bin/rocks add bootaction action="install" kernel="vmlinuz-6.2-x86_64" ramdisk="initrd.img-6.2-x86_64" args="ks ramdisk_size=150000 lang= devfs=nomount pxe kssendmac selinux=0 noipv6 ksdevice=bootif"
/opt/rocks/bin/rocks add bootaction action="os" kernel="localboot 0" ramdisk="None" args="None"
/opt/rocks/bin/rocks add bootaction action="memtest" kernel="kernel memtest" ramdisk="None" args="None"
/opt/rocks/bin/rocks add bootaction action="install headless" kernel="vmlinuz-6.2-x86_64" ramdisk="initrd.img-6.2-x86_64" args="ks ramdisk_size=150000 lang= devfs=nomount pxe kssendmac selinux=0 noipv6 headless vnc ksdevice=bootif"
/opt/rocks/bin/rocks add bootaction action="rescue" kernel="vmlinuz-6.2-x86_64" ramdisk="initrd.img-6.2-x86_64" args="ks ramdisk_size=150000 lang= devfs=nomount pxe kssendmac selinux=0 noipv6 rescue ksdevice=bootif"
/opt/rocks/bin/rocks add bootaction action="pxeflash" kernel="kernel memdisk bigraw" ramdisk="pxeflash.img" args="keeppxe"
/opt/rocks/bin/rocks add bootaction action="install vm frontend" kernel="/boot/kickstart/default/vmlinuz-6.2-x86_64" ramdisk="/boot/kickstart/default/initrd.img-6.2-x86_64" args="ramdisk_size=150000 lang= devfs=nomount pxe kssendmac selinux=0 noipv6 ks=http://campfire.sdsc.edu/install/sbin/kickstart.cgi ksdevice=eth1 build airboss=localhost"
/opt/rocks/bin/rocks add bootaction action="pxefix" kernel="com32 chain.c32" ramdisk="None" args="hd 0"
/opt/rocks/bin/rocks add bootaction action="install blacklist postshell" kernel="vmlinuz-6.2-x86_64" ramdisk="initrd.img-6.2-x86_64" args="ks ramdisk_size=150000 lang= devfs=nomount pxe selinux=0 noipv6 ksdevice=bootif blacklist=mlx4_core blacklist=mlx4_en blacklist=mlx4_ib postshell"
/opt/rocks/bin/rocks add bootaction action="install blacklist" kernel="vmlinuz-6.2-x86_64" ramdisk="initrd.img-6.2-x86_64" args="ks ramdisk_size=150000 lang= devfs=nomount pxe selinux=0 noipv6 ksdevice=bootif blacklist=mlx4_core blacklist=mlx4_en blacklist=mlx4_ib blacklist=mlx5_core blacklist_mlx5_en"

[lclementi]

Hmm,
I'm afraid this might cause problem in a restore roll.

Restore roll is meant to upgrade a Rocks cluster from one version to another.

This way of restoring bootaction will keep the kernel version of the old system, which will be invalid on an upgraded system.
Basically if we include this patch the restore roll will create broken system if used during an upgrade.

Luca

[tcooper]

Updated to not include kernel and ramdisk in rocks dump bootaction output. For example...

[root@campfire bootaction]# rocks dump bootaction
/opt/rocks/bin/rocks add bootaction action="install" args="ks ramdisk_size=150000 lang= devfs=nomount pxe kssendmac selinux=0 noipv6 ksdevice=bootif"
/opt/rocks/bin/rocks add bootaction action="os" args="None"
/opt/rocks/bin/rocks add bootaction action="memtest" args="None"
/opt/rocks/bin/rocks add bootaction action="install headless" args="ks ramdisk_size=150000 lang= devfs=nomount pxe kssendmac selinux=0 noipv6 headless vnc ksdevice=bootif"
/opt/rocks/bin/rocks add bootaction action="rescue" args="ks ramdisk_size=150000 lang= devfs=nomount pxe kssendmac selinux=0 noipv6 rescue ksdevice=bootif"
/opt/rocks/bin/rocks add bootaction action="pxeflash" args="keeppxe"
/opt/rocks/bin/rocks add bootaction action="install vm frontend" args="ramdisk_size=150000 lang= devfs=nomount pxe kssendmac selinux=0 noipv6 ks=http://campfire.sdsc.edu/install/sbin/kickstart.cgi ksdevice=eth1 build airboss=localhost"
/opt/rocks/bin/rocks add bootaction action="pxefix" args="hd 0"
/opt/rocks/bin/rocks add bootaction action="install blacklist postshell" args="ks ramdisk_size=150000 lang= devfs=nomount pxe selinux=0 noipv6 ksdevice=bootif blacklist=mlx4_core blacklist=mlx4_en blacklist=mlx4_ib postshell"
/opt/rocks/bin/rocks add bootaction action="install blacklist" args="ks ramdisk_size=150000 lang= devfs=nomount pxe selinux=0 noipv6 ksdevice=bootif blacklist=mlx4_core blacklist=mlx4_en blacklist=mlx4_ib blacklist=mlx5_core blacklist_mlx5_en"
/opt/rocks/bin/rocks add bootaction action="install vm-container" args="ks ramdisk_size=150000 lang= devfs=nomount pxe selinux=0 noipv6 ksdevice=bootif blacklist=mlx4_core blacklist=mlx4_en blacklist=mlx4_ib blacklist=mlx5_core blacklist_mlx5_en intel_iommu=on"

[lclementi]

This solution is better but it can still break things.

If you are changing FQDN KVM will stop working after you apply the restore roll.

If we need to change some args because anaconda has a new sets of args (as it can happen with centos 7), if you use a restore roll from 6 to 7 you might loose those changes.

Honestly speaking I think the best solution is to put move user defined boot agrs into attributes as proposed in:
#2

IMHO this solution is cleaner:

• system flags will be listed in bootflags table and they will get updated from version to version automatically (since they are not part of restore roll)
• user defined boot flags will be defined in attributes hence they will be automatically backed up in the restore roll
• install flags and boot flags will have a unified interface (they will be both defined using attributes), which is easier for end-users

Luca