Bugzilla – Bug 703673
LiveUSB bad MBR-ID
Last modified: 2011-08-08 08:22:41 UTC
MS2 and several Factory LiveCD-i686 isos since 2011-06-18 had 7fffffff as MBR-ID making it fail to boot from HDD or USB mass storage. Steps To Reproduce: for f in factory/iso/openSUSE-*iso -mtime -40 ; do dd if=$f bs=1 skip=440 count=4 2>/dev/null | od -tx4|grep -q 7fffffff && echo bad $f ; done bad factory/iso/openSUSE-GNOME-LiveCD-i686-Build0060-Media.iso bad factory/iso/openSUSE-GNOME-LiveCD-i686-Build0063-Media.iso bad factory/iso/openSUSE-GNOME-LiveCD-i686-Build0067-Media.iso bad factory/iso/openSUSE-GNOME-LiveCD-i686-Build0069-Media.iso bad factory/iso/openSUSE-GNOME-LiveCD-i686-Build0071-Media.iso bad factory/iso/openSUSE-GNOME-LiveCD-i686-Build0072-Media.iso bad factory/iso/openSUSE-GNOME-LiveCD-i686-Build0097-Media.iso bad factory/iso/openSUSE-KDE-LiveCD-i686-Build0059-Media-.iso bad factory/iso/openSUSE-KDE-LiveCD-i686-Build0060-Media.iso bad factory/iso/openSUSE-KDE-LiveCD-i686-Build0061-Media.iso bad factory/iso/openSUSE-KDE-LiveCD-i686-Build0062-Media.iso bad factory/iso/openSUSE-KDE-LiveCD-i686-Build0063-Media.iso bad factory/iso/openSUSE-KDE-LiveCD-i686-Build0071-Media.iso bad factory/iso/openSUSE-KDE-LiveCD-i686-Build0072-Media.iso bad factory/iso/openSUSE-KDE-LiveCD-i686-Build0089-Media.iso bad factory/iso/openSUSE-KDE-LiveCD-i686-Build0090-Media.iso bad factory/iso/openSUSE-KDE-LiveCD-i686-Build0092-Media.iso bad factory/iso/openSUSE-KDE-LiveCD-i686-Build0093-Media.iso bad factory/iso/openSUSE-KDE-LiveCD-i686-Build0095-Media.iso bad factory/iso/openSUSE-KDE-LiveCD-i686-Build0096-Media.iso bad factory/iso/openSUSE-KDE-LiveCD-i686-Build0097-Media.iso
I finally found out why some of those isos had a bad MBR id: when isohybrid from syslinux-4 is called (on a 32bit system) with -i 0x80000000 or above, the value will be clipped to 0x7fffffff before being written into MBR thus causing it not to be found on USB-boot. As the default is to use a random id, this would cause 50% of isos to be bad. there are two possible ways to solve this: a) the most significant bit is cleared early enough (e.g. &=0x7fffffff right after parsing the -i param and after generating a random id value) b) the whole code is made to work cleanly with 32-bit/unsigned id values
*** Bug 709432 has been marked as a duplicate of this bug. ***
This seems to hit quite a lot of systems, raising priority.
fixed some time ago *** This bug has been marked as a duplicate of bug 708043 ***