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

Michael Green mishagreen at gmail.com
Thu Feb 15 04:28:16 CET 2018


Thanks for the suggestion, Vladimir.

This indeed was one of the reasons it didn’t work. Fixing the PXE boot loader configuration in the way you described helped.

But even after that it still didn’t work. By trial and error I figured that the missing +x bit on the sm22 directory was preventing the kernel from loading.

This is how it was created by rear:

[root at mercury tftpboot]# ls -ld rear/sm22
drwxr-x---   2 root  root        184 Feb 15 04:20 sm22


After fixing it with
[root at mercury tftpboot]# chmod o+x rear/sm22

the kernel was found and loaded.

Bottom line, the issue was the result of these 3 configuration directives:

OUTPUT_PREFIX_PXE=$HOSTNAME
BACKUP_URL=nfs://172.16.0.2/var/lib/tftpboot/rear
PXE_TFTP_URL=nfs://172.16.0.2/var/lib/tftpboot/rear <nfs://172.16.0.2/var/lib/tftpboot/rear>

So the question I have now is how should I adjust local.conf that 

1) all the REAR stuff goes into a folder (/var/lib/tftpboot/rear for example)
2) and the folder created by OUTPUT_PREFIX_PXE=$HOSTNAME has the correct permission right from the start (o+x)?

Thanks,
Michael

> On Feb 13, 2018, at 2:27 AM, Vladimir Gozora <rear at gozora.sk> wrote:
> 
> 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
> _______________________________________________
> rear-users mailing list
> rear-users at lists.relax-and-recover.org
> http://lists.relax-and-recover.org/mailman/listinfo/rear-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.relax-and-recover.org/pipermail/rear-users/attachments/20180214/f938e5d5/attachment.html>


More information about the rear-users mailing list