10 replies to this topic

[matrix.rebooted]

Hello,

I forgot my stick in the usb port while trying to repair windows...   Now I have a message bootmgr missing when I try to boot to the usb.

 

It was a multiboot usb created with yumi (syslinux and grub4dos isos). Content is unchanged so I was wondering if there is a way to repair it (rebuild bcd/bootmgr/mbr, I don't know which one...), and from windows now.., without formatting or if I have to recreate it from the beginning...

Thank you

Edited by matrix.rebooted, 14 November 2017 - 07:38 PM.

[Wonko the Sane]

The message "bootmgr missing" may come from either syslinux, grub4dos or the actual "normal" bootsector/PBR/VBR of the windows (actually it is more likely from the last).

 

Basically it should mean (I am assuming BIOS or UEFI/CSM booting since you mentioned grub4dos) that the file "bootmgr" is missing from the root of the stick, but it may depend on a number of variables.

 

It is likely that what happened is the following (but no way to know without more details):

1) the USB had a MBR invoking directly another bootloader (such as grub4dos, often installed this way)

2) during the repair the MBR was replaced with the standard Windows one (that chainloads the PBR of the active parittion)

3) the previous bootloader did not chainload directly the BOOTMGR in the root of the stick but mounted an image (or however used a different path).

 

OR:

1) the USB had a normal MBR (chainloading the PBR of the active partition)

2) the PBR invoked Syslinux (this is the normal way Syslinux is installed, more rare that grub4dos was chainloaded by it)

3) during the repair the PBR was replaced by the standard Windows PBR code (invoking BOOTMGR)

 

What was the actual FIRST menu you had before?

Was it a Syslinux one or a grub4dos one?

 

Do you have a "bootmgr" file in root of the stick? (my guess is no)

If you have a "grldr" file on the stick (in root or elsewhere) you can try making a copy of it and place the copy in root, renamed as "bootmgr".

This may or may not give you access to grub4dos (depends on a number of factors).

If it does then we will find out a way to repair the setup.

 

If you have either a syslinux.cfg or a menu.lst (or both) post its (their) contents, maybe we can understand from them how your stick was setup.

 

Wonko

[matrix.rebooted]

thank you for the reply, 

 

It is likely that what happened is the following (but no way to know without more details):

What was the actual FIRST menu you had before?

Was it a Syslinux one or a grub4dos one?
 

Hard drive comes with Win7 with BIOS, it is fixed now, it works (using it right now). USB has been formatted and installed with Yumi and first menu was syslinux, then grub4dos from a menu entry, leading to win iso.

Looking at the usb stick after my mistake, I saw that the win7 dvd repair tool installed a \boot folder on it (wasn't there before), and editing the file BCD within with easybcd shown me the classical "start windows 7" menu entry that normally should have been written on the hard drive.
 

Do you have a "bootmgr" file in root of the stick?

I guess it is this BCD? (was in \boot, like windows)
 

If you have a "grldr" file on the stick (in root or elsewhere) you can try making a copy of it and place the copy in root, renamed as "bootmgr".

Deleted \boot folder of the stick and done as you said (grldr is in \HBCD): it worked! Well, at least it is bootable again.

I have several menu entries, as you can see in the files below, but now there is no more 'theme' applied (splash image, text color,..) but more importantly, it shows directly the menu of hiren's bcd, that is the first entry of the syslinux file, as if I had choosen it (pressing 1)... and strangely, without 'pre-' loading hiren's bcd (the embedded progs like dos, memtest, parted magic, etc of the cd are working)

 

EDIT: in fact this menu comes from the default isolinux.cfg and menu.lst in \HBCD where I took grldr from, that's why! but there is no other grldr. All yumi and syslinux files are in \multiboot.(I saw a file named 'wimboot', tried to do the same, but no effect). And that's the only two root folders.
 

If you have either a syslinux.cfg or a menu.lst (or both) post its (their) contents, maybe we can understand from them how your stick was setup.

\multiboot\syslinux.cfg

################## SYSLINUX menu entries# W.I.P.#################UI vesamenu.c32TIMEOUT 600MENU TITLE Universal MultiBoot LiveUSB repair discMENU BACKGROUND yumi_lazero.pngMENU TABMSG  -Y-U-M-I-MENU WIDTH 72MENU MARGIN 10MENU VSHIFT 3MENU HSHIFT 6MENU ROWS 15MENU TABMSGROW 20MENU TIMEOUTROW 22menu color title 1;36;44 #66A0FF #90D00000 nonemenu color hotsel 0;31;47 #C00000 #DDFFFFFFmenu color hotkey 31;47 #C00000 #DDFFFFFFmenu color unsel 37;44 #FFFFFF #6066A0FF nonemenu color sel 30;47 #000000 #FFFFFFFFmenu color border 30;44	#D00000 #00000000 stdmenu color scrollbar 30;44 #DDDDDDDD #00000000 noneLABEL Boot from first Hard DriveMENU LABEL  Continue to Boot from ^First HD (default)KERNEL chain.c32APPEND hd1MENU DEFAULT#start ubuntu_boot_repair_disk_32bitLABEL ubuntu_boot_repair_disk_32bitMENU LABEL ^1 Ubuntu Boot_Repair_Disk_32bitMENU INDENT 1CONFIG /multiboot/ubuntu_boot_repair_disk_32bit/isolinux/isolinux.cfgAPPEND /multiboot/ubuntu_boot_repair_disk_32bit/isolinux#end ubuntu_boot_repair_disk_32bit#start Hiren.s.BootCD.15.2.FR.KeyboardLABEL Hiren's Boot CD (Hiren.s.BootCD.15.2.FR.Keyboard)MENU LABEL ^2 Hiren's Boot CD 15.2 Kbrd FrMENU INDENT 1COM32 /HBCD/Boot/chain.c32 ntldr=/HBCD/grldr#end Hiren.s.BootCD.15.2.FR.Keyboard#start gparted_0.30.0_1_i686LABEL gparted_0.30.0_1_i686MENU LABEL ^3 Gparted 0.30.0_1_i686MENU INDENT 1CONFIG /multiboot/gparted_0.30.0_1_i686/syslinux/syslinux.cfgAPPEND /multiboot/gparted_0.30.0_1_i686/syslinux#end gparted_0.30.0_1_i686#start clonezilla-liveusb-20170905-zesty-i386LABEL clonezilla-liveusb-20170905-zesty-i386MENU LABEL ^4 Clonezilla 20170905-zesty-i386 (ubuntu alt.)MENU INDENT 1CONFIG /multiboot/clonezilla-liveusb-20170905-zesty-i386/syslinux/syslinux.cfgAPPEND /multiboot/clonezilla-liveusb-20170905-zesty-i386/syslinux#end clonezilla-liveusb-20170905-zesty-i386#start systemrescuecd_x86_5.1.2LABEL systemrescuecd_x86_5.1.2MENU LABEL ^5 SystemRescueCD x86_5.1.2MENU INDENT 1CONFIG /multiboot/systemrescuecd_x86_5.1.2/isolinux/isolinux.cfgAPPEND /multiboot/systemrescuecd_x86_5.1.2/isolinux#end systemrescuecd_x86_5.1.2label Unlisted ISOs (via GRUB) ->menu label ^6 Win ISOs via Grub (Win7RE, Malekal7PE & more)MENU INDENT 1KERNEL /multiboot/grub.exeAPPEND --config-file=/multiboot/menu/menu.lst

\multiboot\menu\menu.lst

################## Grub4dos menu entries# W.I.P.#################default 8timeout 30###################keymap azerty fr#################### set AZERTY ketyboard#[...] removed to post########theme########graphicsmode -1 640 480color normal=0x4670ba highlight=0x4670baffcf40 heading=0xead61c helptext=0xead61c border=0xead61c standard=0xFFFFFFsplashimage=/multiboot/grub_4k.jpg############menu settings############# ~80col/25ln maxset wdspace=0set lnspace=0set bdwidth=1set tophelp=24set noitems=10set topstart=4set menuw=68set rstart=7# u restore max menu grub4dos default/multiboot/menu/menusetting.gz u/multiboot/menu/menusetting.gz   %wdspace% %lnspace% %bdwidth% %tophelp% %noitems% %topstart% %menuw% %rstart%#######MENU#######title               --- Windows ISOs Bootable via GRUB ---roottitleroottitle <--- Back to Main Menuroot (hd0,0)chainloader (hd0)+1rootnoverify (hd0)#start Malekal_RepairKit#Modify the following entry if it does not boottitle Boot Malekal win7PESEfind --set-root --ignore-floppies --ignore-cd /multiboot/ISOS/Malekal_RepairKit.isomap --heads=0 --sectors-per-track=0 /multiboot/ISOS/Malekal_RepairKit.iso (hd32)map --hookchainloader (hd32)#end Malekal_RepairKit#start Windows_7_32-bit_Repair_Disc#Modify the following entry if it does not boottitle Boot Windows 7 Repair_Disc_32bitsfind --set-root --ignore-floppies --ignore-cd /multiboot/ISOS/Windows_7_32-bit_Repair_Disc.isomap --heads=0 --sectors-per-track=0 /multiboot/ISOS/Windows_7_32-bit_Repair_Disc.iso (hd32)map --hookchainloader (hd32)#end Windows_7_32-bit_Repair_Disc#start DaRT8.1x86#Modify the following entry if it does not boottitle Boot DaRT 8.1 x86 32 BITSfind --set-root --ignore-floppies --ignore-cd /multiboot/ISOS/DaRT8.1x86.isomap --heads=0 --sectors-per-track=0 /multiboot/ISOS/DaRT8.1x86.iso (hd32)map --hookchainloader (hd32)#end DaRT8.1x86#start DaRT8.1x64#Modify the following entry if it does not boottitle Boot DaRT 8.1 x64 64 BITSfind --set-root --ignore-floppies --ignore-cd /multiboot/ISOS/DaRT8.1x64.isomap --heads=0 --sectors-per-track=0 /multiboot/ISOS/DaRT8.1x64.iso (hd32)map --hookchainloader (hd32)#end DaRT8.1x64#start Win98SE_bootdisk#Modify the following entry if it does not boottitle Boot Win98SE_bootdisk.isofind --set-root --ignore-floppies --ignore-cd /multiboot/ISOS/Win98SE_bootdisk.isomap --heads=0 --sectors-per-track=0 /multiboot/ISOS/Win98SE_bootdisk.iso (hd32)map --hookchainloader (hd32)#end Win98SE_bootdisktitle Reboot the USB\n %@DATE% %@TIME%reboot

Edited by matrix.rebooted, 14 November 2017 - 11:37 PM.

[matrix.rebooted]

So, I really don't know what I am doing but found some threads and tried this if it can help:

- tested mbrview.g4b (rd)

 

Spoiler

https://imgur.com/Kofibyg

 

- tested diskpart : nothing special? the offset perhaps?

 

Spoiler

https://imgur.com/bkW2wjL

 

- tested ptedit32 :

 

Spoiler

https://imgur.com/ePiJYtc

 

Was thinking win could have created its 100Mo reserved partition, but doesn't seem to be the case...

Edited by matrix.rebooted, 15 November 2017 - 02:32 PM.

[Wonko the Sane]

Good.
So, your primary bootloader was Syslinux, and what was overwritten was the PBR (or bootsector) of the active primary partition.

Now it is a matter of replacing the current one (which is the default Windows 7 one) with the Syslinux one.

To reinstall the Syslinux PBR, you could simply run the install command from a copy of Syslinux:
http://www.syslinux....Install#Windows

In your case (let's say that the partition/volume gets drive letter "U:") that would be:
syslinux.exe -d /multiboot/syslinux/ -i U:

But you will have to check if you have anywhere on the stick a Syslinux.exe, otherwise you will need to download a new copy making sure to get the same version as the already installed one.

So, before running the above, try getting a "suitable" Syslinux.exe and run instead (still assuming that U: is the drive letter):
syslinux.exe -f -d /multiboot/syslinux/ -i U: U:\multiboot\syslinux.bin

This will create in U:\multiboot\ a new file syslinux.bin which is a copy of what would be written to the PBR if you used the "normal" install command, see also:
http://www.rmprepusb...inload-syslinux


Now, if you boot from the stick (and get to the the grub4dos menu) you can press "c" (to get to grub4dos command line) and in it issue a few commands:
root [ENTER] <- this should output the current root, likely "(hd0)"
chainloader /multiboot/syslinux.bin [ENTER] <- this chainloads Syslinux, you can press [TAB] to use command line autocompletion
boot [ENTER] <- this should boot Syslinux

If everything looks "fine" (i.e. as before), then you can run the actual install command seen earlier.

I would anyway (before anything else) make a backup copy of the current bootsector (you never know).
Depending on the filesystem in use (I presume FAT32, but could be NTFS) on the volume the procedure might be slightly different, but all in all if you copy the first 16 sectors of the volume that should be fine.

You can use *any* dd version you have or are familiar with, otherwise get the dsfo from the dsfok toolkit:
http://members.ozema...ware/index.html
http://members.ozema...eware/dsfok.zip

Open a command prompt in the directory on hard disk where you extract the dsfo.exe and run the command (still assuming that U: is the drive letter):
dsfo \\.\U: 0 8192 BSbackupU.bin
this will create in that same directory the file BSbackupU.bin 8192 (i.e. 16 sectors) in size that, in case of issues, can always be restored.

Post if you have any doubt or get any error.


Wonko

EDIT:

So, I really don't know what I am doing but found some threads and tried this if it can help:

Yep. but that is normal.

try:
mbrview.g4b (hd0)
and
mbrview.g4b (hd1)

and you will have probably better results (the "(rd)" device is a grub4dos ramdisk that you are not using at all and that is not initialized).

[matrix.rebooted]

(didn't mentioned mbrview hd0 or hd1 because it was all 0 value everywhere)

Ok, loud and clear! All things put together in the right order, here's the procedure:

 

drive is H: and syslinux.cfg is in /multiboot (no syslinux directory)

Since grldr was the one from HBCD, which boot directly to HBCD, I took a fresh one from make_e2b and copied it as \bootgmr on the usb. That gave me direct acess to grub console.

Found correct version of syslinux.exe here https://www.kernel.o...zip/bios/win32/

1st, bckup first 16 sectors, from dsfok directory:
dsfo \\.\H: 0 8192 BSbackupU.bin

2nd, re/create syslinux PBR, open cmd prompt in H:/multiboot/
syslinux.exe -f -d /multiboot/ -i H: H:\multiboot\syslinux.bin

3rd, reboot, from grub4dos cli:
root
chainloader /multiboot/syslinux.bin
boot

4th, re/install syslinux MBR. From your first link, cmd should be:
syslinux.exe --mbr --active --directory /multiboot/ --install h:

After 'access refused' msg, I quit qemu and delete the \bootmgr file created at the beginning, then it was ok!

Rebooted and ... yes, baby!.. recovered everything!

 

(edit: backup again the correct bootsector this time)

I could have rebuild the usb, but it would have been less funny

Thank you a lot for your time and the clear explanations for the nub I am, I learned some tricks:)

Edited by matrix.rebooted, 15 November 2017 - 05:02 PM.

[Wonko the Sane]

Very good .

 

A small word of warning/advice.

 

The bootsector (which is not anymore a bootsector, as it is multiple sectors) or PBR (Partition Boot Record) or more properly VBR (Volume Boot Record) on a NTFS filesystem is *always* 16 sectors or 8192 bytes.

 

On a FAT32 filesystem it can be 1 to 3 sectors depending on a number of factors, and - to further complicate the matter - some formatting utilities (including the standard MS ones) make a backup of the (3 in this case) sectors to sectors 6,7,8 and if the filesystem was created under 2K/XP and later, some code will be in the 13th sector (sector 12), and if the FAT32 was made in ReactOS  on the 15th sector (sector 14).

 

Usually (but it depends as said on a number of factors) when the FAT32 filesystem is created a number of sectors greater than 16 are marked as "reserved", and since these sectors (past sector 12 or 13th sector or in the case of ReactOS sector 14 or 15th sector) are blank, the assumption that 16 sectors do represent a restorable boot code is generally speaking "good enough".

 

Two issues are however possible in theory:

1) the backup of the boot record on sectors 6,7 and 8 is non-present or not updated to the "main,current" boot record

2) the formatting was made very "tight", with "peculiar" tools and non-standard settings and a number smaller than 16 reserved sectors was used, in this case when you image the first 16 sectors the copy may include one or more sectors from the FAT.

 

Issue #1 is not a real issue, since the backup of the boot record is never used if not in some very rare case of filesystem recovery.

Issue #2 is generally not an issue on "populated by automatic tools" USB sticks, as the FAT present in the very first few sectors is normally never modified (but you never know).

 

So, for FAT32 to make sure that your copy/image of the boot record is actually "100% restorable" you should check that the field at offset 14 (0x0E), two bytes, is equal to or bigger than 0x0010 (the field is the one corresponding to "reserved sectors".

 

You can use a hex/disk editor (or grub4dos or any bootsector viewer) to check the file, 99.99% of cases the value will be bigger, I just checked a similar USB stick and the value is in hex view 22 00 that is read as 0x022=34 decimal.

 

If you want to perform this check and don't know how to do it, post and I'll give you instructions.

 

Wonko

[matrix.rebooted]

wow! a bit advanced for me
 
so, I see this

 

https://imgur.com/yAN9wXL

 

could it be BA 08? (0x8ba=2234) ?

 

[Wonko the Sane]

wow! a bit advanced for me
 
so, I see this

 

https://imgur.com/yAN9wXL

 

could it be BA 08? (0x8ba=2234) ?

 

Yes, that is correct.   

 

Everything is fine and dandy. .

 

As a side-side note and JFYI, conventionally hex viewers are used setting a width of 16 bytes (this way positions or offsets on the left are multiples of 16 and read in hex 0x00, 0x10, 0x20, etc.), I am so much in the habit of looking at bootsectors and MBR's in that view that at first sight I couldn't interpret the screenshot  as in the "usual" view the wanted bytes are the last two bytes in first row (and thus easy to spot).

 

Wonko

[matrix.rebooted]

ok,

 

thank you again!

 

[solved]

[Wonko the Sane]

ok,

 

thank you again!

 

[solved]

Not only , you also showed that after all it wasn't too advanced for you (or for anyone, the limit is the sky).

 

Wonko