Multiboot usb won't boot after partition resizing

I have multiboot usb created with YUMI and i used GParted Live to resize the partition on the usb, shrinking its size, but after that the usb won't boot. My guess is that the partition table is somehow damaged during the partition resizing operation, and i didn't backup the partition table before using GParted.
Is there a way to fix the partition table on the usb? Maybe using diskpart, because my laptop has Windows 7, but i also could use other software or live cd, just don't know which.

I have multiboot usb created with YUMI and i used GParted Live to resize the partition on the usb, shrinking its size, but after that the usb won't boot. My guess is that the partition table is somehow damaged during the partition resizing operation, and i didn't backup the partition table before using GParted.
Is there a way to fix the partition table on the usb? Maybe using diskpart, because my laptop has Windows 7, but i also could use other software or live cd, just don't know which.

I am not familiar with YUMI, AFAICR it uses syslnux "under the hood" as "main" bootmanager.

 

So what may have happened is that the ldlinux.sys has "wrong" information

 

Usually it is not an issue to just re-install syslinux:

https://www.syslinux...p?title=Install

but it has to be sen which exact version of syslinux is used and possibly Yumi is using "non-standard" directory structure, so it would be better to repair the Yumi, it has to be seen as well which exact version your Yumi USB is (was) running, see here:

https://www.pendrive...ot-usb-creator/

->FAQ:

 

 

How to force a rebuild of the Syslinux MBR:

This is useful if your YUMI prepared USB drive is somehow no longer bootable.

For Newest version of YUMI:
From the multiboot folder on your flash drive, delete the hidden file ldlinux.sys and then rename the libcom32.c32 file to _libcom32.c32. Then use YUMI to install any menu item. YUMI will notice that the file is missing and will attempt to reinstall syslinux and repair the master boot record. Once finished, rename _libcom32.c32 back to libcom32.c32.

For Older versions of YUMI:
Delete the hidden ldlinux.sys file from the multiboot folder, and use YUMI to install any menu item. YUMI will notice that this file is missing and will attempt to repair it.

 

Someone must tell the good guy over there how "older" and "newest" are pointless adjectives when talking of programs, particularly if the program (rightly) uses versions, such as the current YUMI-2.0.6.1a.exe, in any case, if you can find on the USB the file libcom32.c32 it is the "newest", otherwise it is the "older".

 

Wonko

I don't think i can repair syslinux because i can't access the drive. Windows recognizes the drive, assigns a drive letter, but if i try to open it shows that i need to format the drive before using it.
The last YUMI version i used to add iso file to the drive was 2.0.6.0

 

Though in disk management Windows recognizes the partition but show the file system as RAW and not as fat32. I probably should have used Windows to resize the partition instead of gparted:

Edited by Peter80, 04 December 2018 - 12:03 PM.

I installed MiniTool Partition Wizard and it recognize the usb drive as fat32 file system which is strange:


And also, i can explore the content of the drive from inside the program, but can't edit the files:

Well, then we need to first recover the volume/partition and only later the ldlinux will be needed to be fixed.

 

Unfortunately partition wizard (while generally being a good tool) has not the "level of detail" needed to analyze the issue.

 

Can you make a backup of both the MBR and of the PBR?

 

Ideally you could use a hex/disk editor to save a copy of these two sectors.

 

Or, are you familiar with command line tools? dsfo/dsfi part of the dsfok toolkit are generally recommended by me:

http://members.ozema...ware/index.html

 

I need a copy of the MBR (first absolute sector or LBA0) and of the PBR (either sector LBA 63 if partitoned under up to XP or LBA 2048 if under Vista or later, do both as it costs nothing).

That would be:

dsfo \\.\PhysicalDrive4 0 512 C:\myfailed.mbr

dsfo \\.\PhysicalDrive4 32256 512 C:\myfailedxp.pbr

dsfo \\.\PhysicalDrive4 1048576 512 C:\myfailed7.pbr

 

Once you have the files, zip them together in an archive and either attach it to your next post or upload them to a free file hosting site and post a link to the archive.

 

Wonko

I haven't used these command line tools so far. How to list the drives with dsfo? I want to see how it list my usb drive.

I am reading some guides about using testdisk to recover partition tables. Is testdisk a good tool for recovering partition tables?

I haven't used these command line tools so far. How to list the drives with dsfo? I want to see how it list my usb drive.es?

You don't list them.
You check the disk number in diskpart (or in partition wizard) and use that disk number as \\.\Physicaldrive# (in the screenshot you posted the disk was #3 in diskpart and #4 in partition wizard, probably because you added another USB).
 

I am reading some guides about using testdisk to recover partition tables. Is testdisk a good tool for recovering partition tables?

Testdisk is an exceptionally good tool to recover partition tables, but it remains a tool, very likely it can solve the issue, if properly used.


Wonko

Here are the files from the dsfo tool: link

Ok, here is the data "as is":

MBR:
Entry	Type	Boot	bCyl	bHead	bSect	eCyl	eHead	eSec	StartSector	NumSectors
#0	0B	80	0	1	1	930	27	57	63		14942145	
#1	21	00	979	0	1	979	0	63	15727635	63	
#2	00	00	0	0	0	0	0	0	0		0	
#3	00	00	500	34	39	571	221	50	8034680		115240
	

PBR (the drive was partitioned under XP or earlier, in any case it is a "63 sectors before":
3      0003    OEM String:                  MSWIN4.1                
11     000B    Bytes per sector:     0200   512
13     000D    Sectors per cluster:    08   8
14     000E    Reserved sectors:     002C   44
16     0010    Number of FAT(s):       02   2
17     0011    Max ROOT entries:     0000   0
19     0013    Small type sectors:   0000   0
21     0015    Media type:             F8   248
22     0016    Secs per FAT (small): 0000   0
24     0018    Sectors per Head:     003F   63
26     001A    Number of Heads:      00FF   255
28     001C    Sectors Before:   0000003F   63
32     0020    Large Sectors:    00E3FFC1   14942145
36     0024    Sectors per FAT:  000038F2   14578
40     0028    Flags:                0000   0
66     0042    NT signature:           29   41
77     004D    Volume Serial:    20202045   538976325

The partition table in the MBR is "strange".

The partition of type 21 spanning over the last cylinder makes me think of a drive that has been used with RMPREPUSB/Easy2Boot.

 

The 4th partition entry (even if it has no partition ID) may be part of the problem or the actual problem, as it clearly overlaps the "main" partition in 1st entry.

 

Otherwise the data seems OK, the data in 1st entry is compatible with the data in the PBR.

 

While it is true that the partitioning is not respecting the "standard" of "whole" end cyl/sectors, nor the "1 MB alignment" Windows 7 should not have issues with that.

 

I would try zeroing out the 4th entry and see if Windows recognizes the volume correctly, otherwise you will need (using Gparted or Mini Tool Partition Wizard) to resize it to a cyllinder boundary.

 

To 00 the 4 th entry you can use again a hex/disk editor, or - I am attaching the corrected MBR - deploy it with dsfi:

dsfi \\.\PhysicalDrive# 0 512 myfailed_00ed4th.mbr

 

 

Wonko

I deployed the new MBR file with dsfi tool, but Windows still do not recognize the usb drive.

I also tried testdisk but it didn't find any partitions for recovering.

I think i will just format the drive and use YUMI to recreate again the multiboot usb. Just have to remember the next time before doing experiments, to create backup image of the usb drive using clonezilla or similar tool.

I deployed the new MBR file with dsfi tool, but Windows still do not recognize the usb drive.

I also tried testdisk but it didn't find any partitions for recovering.

I think i will just format the drive and use YUMI to recreate again the multiboot usb. Just have to remember the next time before doing experiments, to create backup image of the usb drive using clonezilla or similar tool.

Yep, the partition is there and is seemingly "valid", so testdisk finds nothing to worry about/to correct.

 

It remains the doubt on fractional cylinder/head, but I don't think that is the actual reason.

 

Can it not be some kind of issue with the Registry and "known" volumes? Maybe changing the disk signature would "reset" something?

 

Can you try resizing the partition with MiniTool Partition Wizard ? 

It should be able to do that,.

 

Wonko

I resized the partition with MiniTool and the operation finished successfully, but Windows still does not recognize the usb drive.

By the way, this is what testdisk shows when came to 'analyze' phase, but after this do not find any partitions to recover:
 

Disk /dev/sdd - 8054 MB / 7681 MiB - CHS 1023 248 62
Current partition structure:
     Partition                  Start        End    Size in sectors

Invalid FAT boot sector
 1 * FAT32                    0   1  2   938  59 24   14426307
 1 * FAT32                    0   1  2   938  59 24   14426307

Warning: Bad ending sector (CHS and LBA don't match)
 2 P Sys=21                1022 215 34  1022 216 34         63

Warning: Bad starting sector (CHS and LBA don't match)

Yes, but I meant resize to a cylinder boundary, I believe this can be done with the partition Wizard (but maybe I am confusing myself with some other program?)

 

The testdisk "recognizes" it with a "queer" geometry. H/S 248/62, *something* must be "throwing it off".

 

The device is surely 255/63.

 

The first partition (BTW you can simply delete the second one, it is a single cylinder type 21, as said the partition that RMPREPUSB can create) should start on 0/1/1 and end on n/254/63.

 

I would need to see the MBR data after the resizing, but 0/1/2  on a 62 sectors geometry remains 0/1/1 on a 63 one (good), and in the same "false" geometry of 248/62 the 938/59/24 does actually make 14426307 sectors., so the testdisk report that CHS and LBA don't match is curious. 

 

I am starting to believe that the stick has some "issues" and reports incorrect data intermittently.

 

Maybe you should really format it and restart from scratch .

 

Wonko

I fixed it. I used the 'advanced' option in testdisk to repair FAT boot sector following this guide https://www.cgsecuri...nced_FAT_Repair. After that Windows recognized the usb drive and i was able to make the drive bootable again following the instructions from YUMI faq page.
I don't think the problem was with the partition table. Also, it seems only Windows had issue with the drive, under linux it recognized the drive and i could mount it without problem. Probably that was caused by resizing the usb partition with gparted, instead using Windows, but i need to do more testing.

Peter80, on 05 Dec 2018 - 11:14 AM, said:

I fixed it. I used the 'advanced' option in testdisk to repair FAT boot sector following this guide https://www.cgsecuri...nced_FAT_Repair. After that Windows recognized the usb drive and i was able to make the drive bootable again following the instructions from YUMI faq page.
I don't think the problem was with the partition table. Also, it seems only Windows had issue with the drive, under linux it recognized the drive and i could mount it without problem. Probably that was caused by resizing the usb partition with gparted, instead using Windows, but i need to do more testing.

Good.
Possibly something else (besides the filesystem data) triggered the mis-recognition by windows.
Can you chek it again in testdisk?
It should see it as being 255/63.


Wonko

P.S. Now that you mentioned it I re-checked visually the "myfailedxp.pbr".

The problem was definitely there, whilst the "data" was OK, the actual "code" was way off, there is in it (besides more "binary crap" instead of the booting code) a leading B80170.
Very likely that was the basic issue, we did some experiments some time ago:
https://msfn.org/boa...&comment=987482
https://msfn.org/boa...#comment-987482
there must be a jmp short or jmp long instruction first thing, i.e. EBxx90 or E9xxxx for the filesystem to be recognized EVEN if it is not bootable r booted from.

This is what testdisk is showing:

 

This is what testdisk is showing:

 

Yep, now the geometry is "right", though the previous testdisk output remains "curious".

I updated my previous post, very likely I found the "culprit", I completely missed checking those few first bytes before.

The filesystem remains "correct" (and thus mini tool can see its contents) but Windows will find it as RAW.

 

Wonko

By the way, i can confirm that this issue is caused by gparted. I created two multiboot usb drives with YUMI, then booted from gparted live and resized the partitions of both usb drives. After that usb drives won't boot and Windows won't recognize them. So, i don't know why but gparted is causing this.

FYI + TOOLTIPP: DiskGenius is a good and detailed Windows + DOS Partitionmanger ...

 

Eassos DiskGenius (earlier Partition Guru) © 2010 Eassos Co., Ltd. @ CHINA https://www.diskgenius.com/aboutus.php

DD: Oct 2018 - ca. 53 MB - Inno Setup Installer - Englisch - Freeware Version
OS: Windows XP - 10

HP: https://www.diskgenius.com
PP: https://www.diskgeni...om/editions.php

SS: http://www.snapfiles.../diskgenius.htm

 

Edited by @thehop, 05 December 2018 - 02:28 PM.

By the way, i can confirm that this issue is caused by gparted. I created two multiboot usb drives with YUMI, then booted from gparted live and resized the partitions of both usb drives. After that usb drives won't boot and Windows won't recognize them. So, i don't know why but gparted is causing this.

 

If you still have one of those sticks you could try changing the first three bytes of the PBR to either EBxx90 or E9xxxx, and see if the Windows now can "see" them.

It is entirely possible that under Linux (like in FreeDOS) this "peculiar" check is not performed, so the good GParted guys didn't notice as the filesystem itself is correctly resized.

Also which version of GParted is it?

Some time ago (probably years ago) I used GParted successfully, but cannot remender if I actually used it to resize a FAT32 partition. it is possible both that it is a new bug or that it has been there for years.

 

 

Wonko

I already formatted the usb drives, but i did another test. I setup one of the usb drive as multiboot using YUMI and then resized the partition on the drive using MiniTool Partition Wizard and this didn't cause any issues. The drive booted normally and Windows recognized it as it should be. So, i think in the future i will avoid using GParted for that kind of operations.

 

I am using the current gparted version 0.32.0

Edited by Peter80, 05 December 2018 - 05:26 PM.