#596 Issue closed: Cannot boot recovery iso on Debian 8: Failed to load ldlinux.c32¶
Labels: bug, waiting for info
rpasche opened issue at 2015-06-09 12:55:¶
Hi,
Debian wheezy used syslinux < 5 but Debian Jessie uses syslinux >
5, so you need to load additional modules (ldlinux.c32) when using
"isolinux.bin".
Also, in Jessie, "isolinux.bin" is no longer included in "syslinux" or
"syslinux-common", but now in extra package "isolinux". And, the path
for the file is "/usr/lib/ISOLINUX", thus, SYSLINUX_DIR will be
"/usr/lib/ISOLINUX" not finding needed modules. But also, the needed
module "ldlinux.c32" is NOT in /usr/lib/syslinux but in
/usr/lib/syslinux/modules/bios.
Creating a symlink within "/usr/lib/ISOLINUX" fixes this problem
root@jessie-test1:/usr/lib/ISOLINUX# ls -l
total 48
-rw-r--r-- 1 root root 432 Jan 7 07:53 isohdpfx.bin
-rw-r--r-- 1 root root 432 Jan 7 07:53 isohdppx.bin
-rw-r--r-- 1 root root 40960 Jan 7 07:53 isolinux.bin
lrwxrwxrwx 1 root root 42 Jun 8 15:31 ldlinux.c32 ->
/usr/lib/syslinux/modules/bios/ldlinux.c32
root@jessie-test1:/usr/lib/ISOLINUX#
But furthermore, the file "ldlinux.c32" is a "requirement", not an option, so "rear" should exit with an error, so this "missing" is recognized.
http://www.syslinux.org/wiki/index.php/Library_modules
gdha commented at 2015-06-09 13:18:¶
See also #584 - the new paths are in the meantime known. However, the
ldlinux.c32 requirement is new for me.
rpasche commented at 2015-06-09 13:31:¶
Was also new to me. Found the bug yesterday, when I tested rear on Debian 8
abbbi commented at 2015-06-10 12:30:¶
hi,
as a workaround in order to get it working with a proper menu you also
have to symlink:
'chain.c32','hdt.c32','ldlinux.c32','libutil.c32','menu.c32'
was it able to setup the networking in your case? It seems like it
doesnt load the kernel
module for the network card (e1000 in my case).
The cause of hte Problem seems to be that on debian jessie there is no
persistent
networking configuration file in /etc/udev/rules.d anymore, as such
55-migrate-network-service.sh fails
abbbi commented at 2015-06-10 13:34:¶
hi again,
i just tried recovering a jessie system with default installation (just using the entire first disk), it seems to have troubles recreating the extended partition, the original system looks like:
Disk /dev/sda: 10 GiB, 10737418240 bytes, 20971520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x1dcbae11
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 20013055 20011008 9,6G 83 Linux
/dev/sda2 20015102 20969471 954370 466M 5 Extended
/dev/sda5 20015104 20969471 954368 466M 82 Linux swap / Solaris
during recovery:
+++ echo '2015-06-10 15:30:04 Creating partitions for disk /dev/sdb (msdos)'
2015-06-10 15:30:04 Creating partitions for disk /dev/sdb (msdos)
+++ Print 'Creating partitions for disk /dev/sdb (msdos)'
+++ test 1
+++ echo -e 'Creating partitions for disk /dev/sdb (msdos)'
+++ my_udevsettle
+++ has_binary udevadm
+++ for bin in '$@'
+++ type udevadm
+++ return 0
+++ udevadm settle
+++ parted -s /dev/sdb mklabel msdos
+++ my_udevsettle
+++ has_binary udevadm
+++ for bin in '$@'
+++ type udevadm
+++ return 0
+++ udevadm settle
+++ my_udevsettle
+++ has_binary udevadm
+++ for bin in '$@'
+++ type udevadm
+++ return 0
+++ udevadm settle
+++ parted -s /dev/sdb mkpart '"primary"' 2097152B 2149580798B
+++ my_udevsettle
+++ has_binary udevadm
+++ for bin in '$@'
+++ type udevadm
+++ return 0
+++ udevadm settle
+++ my_udevsettle
+++ has_binary udevadm
+++ for bin in '$@'
+++ type udevadm
+++ return 0
+++ udevadm settle
+++ parted -s /dev/sdb set 1 boot on
+++ my_udevsettle
+++ has_binary udevadm
+++ for bin in '$@'
+++ type udevadm
+++ return 0
+++ udevadm settle
+++ my_udevsettle
+++ has_binary udevadm
+++ for bin in '$@'
+++ type udevadm
+++ return 0
+++ udevadm settle
+++ parted -s /dev/sdb mkpart '"extended"' 2147483647B 12884901887B
Error: You requested a partition from 2147MB to 12.9GB (sectors 4194303..25165823).
The closest location we can manage is 2150MB to 12.9GB (sectors 4198400..25165823).
dikslayout.conf:
disk /dev/sda 10737418240 msdos part /dev/sda 10245636096 1048576 primary boot /dev/sda1 part /dev/sda 1024 10247732224 extended none /dev/sda2 part /dev/sda 488636416 10247733248 logical none /dev/sda5 # Filesystems (only ext2,ext3,ext4,vfat,xfs,reiserfs,btrfs are supported). # Format: fs device mountpoint fstype [uuid=uuid] [label=label] [attributes] fs /dev/sda1 / ext4 uuid=1e3af026-42c3-4ba1-b986-c9aad0e8c190 label= blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d bytes_per_inode=16370 default_mount_options=user_xattr,acl options=rw,relatime,errors=remount-ro,data=ordered swap /dev/sda5 uuid=f63b1615-530e-4e03-a139-3364af069448 label=
abi@cefix:~$ cat /tmp/disklayout.conf disk /dev/sda 10737418240 msdos part /dev/sda 10245636096 1048576 primary boot /dev/sda1 part /dev/sda 1024 10247732224 extended none /dev/sda2 part /dev/sda 488636416 10247733248 logical none /dev/sda5 # Filesystems (only ext2,ext3,ext4,vfat,xfs,reiserfs,btrfs are supported). # Format: fs device mountpoint fstype [uuid=uuid] [label=label] [attributes] fs /dev/sda1 / ext4 uuid=1e3af026-42c3-4ba1-b986-c9aad0e8c190 label= blocksize=4096 reserved_blocks=4% max_mounts=-1 check_interval=0d bytes_per_inode=16370 default_mount_options=user_xattr,acl options=rw,relatime,errors=remount-ro,data=ordered swap /dev/sda5 uuid=f63b1615-530e-4e03-a139-3364af069448 label=
rpasche commented at 2015-06-10 14:07:¶
I will test my recovery again.
We use a lot of LVM, and I think, my testsystem has been recreated properly (as far as I can remember). Also have to note, that this was a VM, not a physical machine.
rpasche commented at 2015-06-10 14:28:¶
OK. My recovery just worked. System is up and running fine. I would have
to dig deeper to verify, that everything is really ok. But for the first
sight, all good.
gdha commented at 2015-06-12 19:16:¶
https://github.com/rear/rear/commit/635f5cb844c5208e495bcf2b6d8844551fc38632 should fix the ldlinux.c32 issue and the menu's are back.
rpasche commented at 2015-06-12 20:36:¶
I will try it next time I'm in the office.
rpasche commented at 2015-06-30 09:46:¶
Sorry for the long delay. For now, I can confirm, that the recovery boot menu is loaded correctly. But now, I have a strange problem with my test VM, that is loading some drivers, which are not needed. One of them is "drbd", that caused my recovery test to fail, because the disklayout has changed (drbd is loaded first and therefore shoes /dev/sda as a 8 MB disk.
I have to investigate, why the hell the VM is loaded this driver. No clue
I also tried to blacklist the driver but had no luck yet.
gdha commented at 2015-06-30 10:22:¶
@rpasche Ok thank you for the confirmation - I would rather close this issue - and if your new problem is persistent (?) I would prefer that you open a new issue.
[Export of Github issue for rear/rear.]