I used syslinux to make an external usb hard drive booting up "system
rescue cd" from a FAT primary partition.
The procedure I followed was setting on the boot flag on the FAT partition and
copying the content of the iso image to it and renaming isolinux to syslinux
wherever needed. I then unmounted the device and ran "syslinux -d
/syslinux/ -i /dev/sdxn" where sdxn is the appropriate partition. It worked
nicely on both laptops i have at hand.
Then I wanted to try the same using an ext2 partition instead and so using
extlinux. For this, after creating an ext2 partition, moving the boot flag to it
and copying the live linux files, I copied the file mbr.bin from the syslinux
package to the hard drive mbr. Then I ran "extlinux -i
/mnt/mountpoint". This time booting up "system rescue cd" failed
on one of the two laptops. Afterwards even retrying to boot from the FAT
partition resulted with the same computer in failing. I hadn't saved the
initial mbr content, so couldn't restore it, hence mbr.bin should still be
in place and this might be what the failing laptop doesn't like.
For the diagnotics I used the dos BIOS program from UBCD, here is the output for
both laptops:
failling /// success laptops :
Q:\USR\BIOS>bios i
# Found FreeDOS 7.10 running /// same
# Found unknown BIOS /// Found
Phoenix BIOS ???
# BIOS date: 02/18/06 (month/day/year) /// 12/26/08
# State of RTC battery: Full /// same
# ROM BASIC: Not implemented /// same
Q:\USR\BIOS>bios x
# Found FreeDOS 7.10 running /// same
# Advanced Power Management not activated or not available
///
same
# Found Plug and Play-BIOS v1.0 /// same
# Found PCI-BIOS v2.10 /// same
# Found IBM/MS Int13 Extensions v0.2 /// Found IBM/MS Int13
Extensions v1.2
# Found System Management-BIOS v2.31 /// Found System
Management-BIOS v2.4
# Found Desktop Management Interface v0.0 /// Found Desktop
Management Interface v2.4
# Found VESA BIOS Extensions v2.0 /// Found VESA BIOS
Extensions v3.0
|_ # Found VBE Power Management v1.0 /// same
|_ # Found VBE Accelerator Functions not activated or not available
///
same
# PCMCIA Socket Services not activated or not available
///
same
> I used syslinux to make an external usb hard drive booting up "system rescue cd" from a FAT primary partition. > The procedure I followed was setting on the boot flag on the FAT partition and copying the content of the iso image to it and renaming isolinux to syslinux wherever needed. I then unmounted the device and ran "syslinux -d /syslinux/ -i /dev/sdxn" where sdxn is the appropriate partition. It worked nicely on both laptops i have at hand. > > Then I wanted to try the same using an ext2 partition instead and so using extlinux. For this, after creating an ext2 partition, moving the boot flag to it and copying the live linux files, I copied the file mbr.bin from the syslinux package to the hard drive mbr. Then I ran "extlinux -i /mnt/mountpoint". This time booting up "system rescue cd" failed on one of the two laptops. Afterwards even retrying to boot from the FAT partition resulted with the same computer in failing. I hadn't saved the initial mbr content, so couldn't restore it, hence mbr.bin should still be in place and this might be what the failing laptop doesn't like. >(snip) How _exactly_ did you "copy" (again) the mbr.bin file (and why again)? Which command did you use? Before you executed such command, was the filesystem volume mounted or unmounted? Please post the exact command you used for formatting the FAT volume. Please also post the command you used when creating the ext2 volume. If you repeat the _whole_ initial procedure you described (installing mbr.bin, then using FAT and the 'syslinux' installer), can you boot then? Regards, Ady.
________________________________________ From: Jethro Tull [heavytull at hotmail.com] Sent: Thursday, April 13, 2017 9:56 PM To: Ady Ady Subject: Re: [syslinux] boot fails on some system On Thu, 13 Apr, 2017, 20:27:03 +0000, Ady Ady via Syslinux wrote:> > > I used syslinux to make an external usb hard drive booting up "system rescue cd" from a FAT primary partition. > > The procedure I followed was setting on the boot flag on the FAT partition and copying the content of the iso image to it and renaming isolinux to syslinux wherever needed. I then unmounted the device and ran "syslinux -d /syslinux/ -i /dev/sdxn" where sdxn is the appropriate partition. It worked nicely on both laptops i have at hand. > > > > Then I wanted to try the same using an ext2 partition instead and so using extlinux. For this, after creating an ext2 partition, moving the boot flag to it and copying the live linux files, I copied the file mbr.bin from the syslinux package to the hard drive mbr. Then I ran "extlinux -i /mnt/mountpoint". This time booting up "system rescue cd" failed on one of the two laptops. Afterwards even retrying to boot from the FAT partition resulted with the same computer in failing. I hadn't saved the initial mbr content, so couldn't restore it, hence mbr.bin should still be in place and this might be what the failing laptop doesn't like. > > > > (snip) > > How _exactly_ did you "copy" (again) the mbr.bin file (and why again)? > Which command did you use? Before you executed such command, was the > filesystem volume mounted or unmounted? > > Please post the exact command you used for formatting the FAT volume. > Please also post the command you used when creating the ext2 volume. > > If you repeat the _whole_ initial procedure you described (installing > mbr.bin, then using FAT and the 'syslinux' installer), can you boot > then? > > Regards, > Ady.again? actually for the first test, i.e. booting from the FAT partition I didn't put mbr.bin to the hard drive's mbr. I just executed the step as I described. I paid attention to mbr.bin only when I started to be interested in bootting off an ext2/3 partition. And that's because it was mentionned in the tutorial I looked at, which this one : http://www.syslinux.org/wiki/index.php?title=EXTLINUX, and I used the exact same command i.e. "cat mbr.bin > /dev/sdx" where sdx is the master device and while no partition of the device was mounted. The FAT volume was formatted by gparted. For the ext2 partition I used '$mke2fs -t ext2 -L "sysrescd" /dev/sdxn'. I always use fdisk to toggle the boot flag. As i said this time the device is failing to boot on one of the two laptops. Maybe I should have mentionned that it meant the other booted fine for cases described in my initial email i.e. in the first test with the FAT partition before paying attention to mbr.bin, in the case of the ext2 partition after having modified the device's mbr by copying to it mbr.bin as described, and in the case I reattempted to boot off the FAT partition while the mbr of the device was modified.
If everything looks good on stick (active partition, partition ids,
etc), but one computer happilly boots and the other doesn't, obviously
the non-booting one doesn't like the mbr or the partitioning.
For the mbr liking:
The first 440 bytes can be any "normal" mbr. First take a backup of
the one you have on the USB stick/disk now with "dd if=/dev/sdx bs=440
count=1 of=mbr.not_perfect conv=sync".
Then put in any other one from a BIOS (UEFI system might be a bad
choice) booting hard drive. From your main system, from your Windows
system (although this might be a last resort), etc. And/Or use the
mbr.bin files from different syslinux versions. Make sure to not
disturb the partitioning when doing this ("bs=440 count=1").
Can you make it boot then?
If so you can compare the mbrs to see what's different if you want.
For the partitioning:
If not try partition the USB stick/disk with another partition
tool. My experiences with gparted have been bad. With sfidks and fdisk
acceptable (to add to the confusion, there were two different fdisks
in Debian: one from util-linux and one from gnu-fdisk; gnu-fdisk seems
to have disappeared in jessie).
Do zero out the partition table first so you don't "inherit" any
badness ("dd if=/dev/zero of=/dev/sdx bs=512 count=1 conv=sync").
Actually before destroying the partition table, I'd zero out the
beginning of all and any partitions ("dd if=/dev/zero bs=1024k
count=10 conv=sync of=/dev/sdxX" x Y) first, as we are in starting
from scratch mode. (If there were RAID/GPT involved I'd zero out
the end of partitions/disk respectively too.)
Further making starting first partition start on sector 2048 or 63 or
whatever new USB sticks have (I've seen really weird starting sector
on them like 8064) could make a difference. I've seen a new UEFI
system fail to BIOS boot with the partitioning of/from a new USB stick
(not relevant here).
--
MartinS