[rear-users] SLES 12 SP1 PXE rescue boot issue

Vladimir Gozora rear at gozora.sk
Tue Feb 13 08:27:58 CET 2018


Hello Michael,

Can you try following change
- kernel sm22/sm22.kernel
- append initrd=sm22/sm22.initrd.cgz root=/dev/ram0 vga=normal rw selinux=0 console=ttyS0,9600 console=ttyS1,9600 console=tty0

+ kernel rear/sm22/sm22.kernel
+ append initrd=rear/sm22/sm22.initrd.cgz root=/dev/ram0 vga=normal rw selinux=0 console=ttyS0,9600 console=ttyS1,9600 console=tty0

Maybe it will help ...

Best regards

V.

On Mon, 12 Feb 2018, Michael Green wrote:

> Hello collective wisdom,
> The issue here is that the host to be recovered isn’t booting off PXE - not finding the kernel. See the screenshot and logs here ->
> <https://www.dropbox.com/sh/lw73oznbmma421n/AACS3lKj2c1dasgui6CddhS4a?dl=0>
> 
> I’m backing up and recovering to the same physical host - SLES 12 SP1.
> 
> The configuration:
> sm22:/etc/rear # less local.conf
> <snip the comments>
> OUTPUT=PXE
> OUTPUT_PREFIX_PXE=$HOSTNAME
> REQUIRED_PROGS=( "${REQUIRED_PROGS[@]}" snapper chattr lsattr )
> COPY_AS_IS=( "${COPY_AS_IS[@]}" /usr/lib/snapper/installation-helper /etc/snapper/config-templates/default )
> BACKUP_PROG_INCLUDE=( '/var/tmp/*' '/var/spool/*' '/var/opt/*' '/var/lib/pgsql/*' '/var/lib/named/*' '/var/lib/mysql/*' '/var/lib/mariadb/*'
> '/var/lib/mailman/*' '/var/lib/libvirt/images/*' '/usr/local/*' '/tmp/*' '/srv/*' '/opt/*' '/boot/grub2/x86_64-efi/*' '/boot/grub2/i386-pc/*'
> '/var/log/*' )
> USE_DHCLIENT="yes"
> BACKUP=NETFS
> BACKUP_PROG=tar
> BACKUP_URL=nfs://172.16.0.2/var/lib/tftpboot/rear
> PXE_TFTP_URL=nfs://172.16.0.2/var/lib/tftpboot/rear
> PXE_CONFIG_URL=nfs://172.16.0.2/var/lib/tftpboot/pxelinux.cfg
> EXCLUDE_MOUNTPOINTS=( /mnt/e8b0 /mnt/e8b2 /mnt/e8b1 /mnt/e8b3 )
> 
> The mkrescue commands begins and completes:
> 
> sm22:/etc/rear # rear -v mkrescue
> Relax-and-Recover 2.3 / 2017-12-20
> Using log file: /var/log/rear/rear-sm22.log
> Using backup archive '/tmp/rear.FIvaJZKEe4JDBMF/outputfs/sm22/backup.tar.gz'
> Creating disk layout
> Using sysconfig bootloader 'grub2'
> Creating root filesystem layout
> Copying logfile /var/log/rear/rear-sm22.log into initramfs as '/tmp/rear-sm22-partial-2018-02-13T03:06:26+0200.log'
> Copying files and directories
> Copying binaries and libraries
> Copying kernel modules
> Copying all files in /lib*/firmware/
> Creating recovery/rescue system initramfs/initrd initrd.cgz with gzip default compression
> Created initrd.cgz with gzip default compression (116651106 bytes) in 14 seconds
> Copied kernel+initrd 116M to nfs://172.16.0.2/var/lib/tftpboot/rear/sm22
> Created pxelinux config 'rear-sm22' and symlinks for MAC adresses in nfs://172.16.0.2/var/lib/tftpboot/pxelinux.cfg
> Copying resulting files to nfs location
> Saving /var/log/rear/rear-sm22.log as rear-sm22.log to nfs location
> 
> 
> On the PXE server the structure gets produced:
> 
> [root at mercury tftpboot]# ls -l rear/
> total 0
> drwxr-x--- 2 root root 195 Feb 13 02:25 sm22
> [root at mercury tftpboot]# ls -l rear/sm22/
> total 119384
> -rw------- 1 root root       516 Feb 13 03:06 README
> -rw------- 1 root root    602220 Feb 13 03:06 rear-sm22.log  <-- included in the Dropbox folder
> -r--r--r-- 1 root root 116651106 Feb 13 03:06 sm22.initrd.cgz
> -r--r--r-- 1 root root   4975344 Aug 10  2016 sm22.kernel
> -r--r--r-- 1 root root       268 Feb 13 03:06 sm22.message
> -rw------- 1 root root       268 Feb 13 03:06 VERSION
> 
> [root at mercury tftpboot]# ls -l pxelinux.cfg/
> 
> drwxr-xr-x.  2 tftpd tftpd 4096 Feb 13 03:06 ./
> drwxr-xr-x  29 root  root  4096 Feb 13 02:28 ../
> <snip>
> lrwxrwxrwx   1 root  root     9 Feb 13 03:06 01-0c-c4-7a-92-61-cc -> rear-sm22
> lrwxrwxrwx   1 root  root     9 Feb 13 03:06 01-0c-c4-7a-92-61-cd -> rear-sm22
> lrwxrwxrwx   1 root  root     9 Feb 13 03:06 01-24-8a-07-a8-09-48 -> rear-sm22
> -r--r--r--   1 root  root   955 Feb 13 03:06 rear-sm22 <-- included in the Dropbox folder
> 
> 
> I then reboot the host, force it to attempt PXE boot. The host finds the pxelinux.cfg configuration and the message, however the kernel doesn’t
> get executed, as in the screenshot above.
> 
> Any pointers?
> 
> Thanks,
> Michael
> 
> 
>


More information about the rear-users mailing list