Other Restoring first 1MB of disk

B

balanga

In the process of changing the format of my Ventoy partitions I screwed something up and wondered about copy the first 1MB of a working Ventoy installation to the other one.

If that sounds as though it might work could I do that with dd as in

dd if=/dev/da0 of=/dev/da1 bs=1024b count=1000


I'm referring to the 1MB protective area in this:
1707128396151.png
 
There's nothing there, besides the partition table. Why are you adamant it contains information that needs to be copied? It's just empty space.
 
SirDice said:
There's nothing there, besides the partition table. Why are you adamant it contains information that needs to be copied? It's just empty space.
Click to expand...
When I try booting, the system just displays:-

VTVTVTVTVTVT

and stops. This originates from the Ventoy boot loader.

The area between the start of the disk after the partition table and the first partition is something, I've never understood properly, but AFAIU Ventoy puts its magic in there.
 
First block on the disk contains the master boot record (and the pMBR; 'fake' MBR partition). There's only 400something bytes space for the boot code, so it's possible they've put the rest of the boot code in that first 1MB of the disk.

Care must be taken when copying that first 1MB though, it also contains the partition table, you probably don't want to copy that.
 
I'd create a hexdump of that first 1MB. The first block should contain a partition table and the master boot record. The next couple of blocks can contain the GPT partition table entries. That additional boot code has to be somewhere between block 34 and 2048 (1MB mark), the rest of it should be empty. Find out where exactly it lives and only copy those blocks.

en.wikipedia.org

GUID Partition Table - Wikipedia

en.wikipedia.org en.wikipedia.org
 
sko said:
what are you trying to boot? maybe just cut out ventoy as an additional layer and instead directly use the usbdisk image?
Click to expand...
I have a 300GB Ventoy disk with 11 partitions where I've screwed up the Ventoy boot system. I want to figure out how to copy the first 1MB from another Ventoy disk, but I'm afraid of losing access to the partiitions installed.
 
SirDice said:
I'd create a hexdump of that first 1MB. The first block should contain a partition table and the master boot record. The next couple of blocks can contain the GPT partition table entries. That additional boot code has to be somewhere between block 34 and 2048 (1MB mark), the rest of it should be empty. Find out where exactly it lives and only copy those blocks.
Click to expand...

I'm not really familar with what hexdump can do...

How does this sound?

Code: 
dd if=/dev/da0 of=first-1MB bs=512 count=1024
hexdump first-1MB
 
Looks good. I'd add -C to hexdump(1), that'll make it easier to see where there's data.

Code: 
       -C      Canonical hex+ASCII display.  Display the input offset in hexa-
	       decimal,	followed by sixteen space-separated, two column, hexa-
	       decimal bytes, followed by the same sixteen bytes in %_p	format
	       enclosed	in ``|'' characters.
 
Oh, with bs=512 count=1024 you're going to get 512*1024 = 524288 bytes. That's only half of what you wanted. bs isn't that important, it doesn't need to relate to the block size of the disk, it's the block size dd(1) uses to transfer the data. You typically increase the block size for better performance. Performance isn't going to be much of an issue with a fairly small amount of data. So just use bs=1024 count=1024 to get the first 1 MB of the disk, bs=1m count=1 would work too.
 
balanga said:
In the process of changing the format of my Ventoy partitions I screwed something up and wondered about copy the first 1MB of a working Ventoy installation to the other one.
Click to expand...

Are you just cloning the 'working' one, or does this one have different data?

balanga said:
If that sounds as though it might work could I do that with dd as in

dd if=/dev/da0 of=/dev/da1 bs=1024b count=1000
Click to expand...

From dd(1): "Where sizes or speed are specified, a decimal, octal, or hexadecimal number of bytes is expected. If the number ends with a "b", "k", "m" [...] the number is multiplied by 512, 1024 (1K), 1048576 (1M) [...]

So 'bs=1024b' is 1024*512 i.e. 512k, * 1000 is 500 MiB.

balanga said:
I'm referring to the 1MB protective area in this:
Click to expand...

bs=512 (default) count=2048, or bs=1024 count=1024

But yes, that still clobbers the (dummy) MBR and the GPT, likely not what you want, though gpart recover might bail you out if the secondary is good.

What do you really want to do?
 
SirDice said:
So just use bs=1024 count=1024 to get the first 1 MB of the disk, bs=1m count=1 would work too.
Click to expand...

I'm on the 'hoarder spectrum' so keep copies of MBRs and yes, first meg of disks. Of course you only need backups you've neglected to make ;-)

I often use such as
dd if=$diskorpartition skip=$skip count=$count | hd | less
where $skip is optional but handy for locating sections.

Then it's easy to spot code sections, text bits etc. That's how I explored Ventoy anyway, albeit on MBR memsticks.

I gather Ventoy uses grub to boot its .iso and .img files, but don't know where it is on disk.
 
smithi said:
But yes, that still clobbers the (dummy) MBR and the GPT, likely not what you want, though gpart recover might bail you out if the secondary is good.

What do you really want to do?
Click to expand...
I'm just trying to recover the Ventoy system partition, or rather the bootloader which exists in the first 1MB of the disk. I want to retain all the partitions.
 
According to they website the bootloader is located at LBA34-2047.
What is the current status of the disk? Can you connect it to FreeBSD and show the output of gpart show
 
VladiBG said:
According to they website the bootloader is located at LBA34-2047.
What is the current status of the disk? Can you connect it to FreeBSD and show the output of gpart show
Click to expand...
gpart show -l da0:
Code: 
root@M73:/media# gpart show -l da0
=>       34  625142381  da0  GPT  (298G)
         34  100788838       - free -  (48G)
  100788872      65536    2  VTOYEFI  (32M)
  100854408    1048576    3  mfsBSD  (512M)
  101902984    1048576    4  OpenWrt  (512M)
  102951560   10485760    5  FreeBSD  (5.0G)
  113437320   20971520    6  (null)  (10G)
  134408840       1400       - free -  (700K)
  134410240   10485760    7  (null)  (5.0G)
  144896000   20971520    8  (null)  (10G)
  165867520    2097152    9  mfsLinux  (1.0G)
  167964672   10485760   10  OpenWrt2  (5.0G)
  178450432  446691976   11  save-area  (213G)
  625142408          7       - free -  (3.5K)

The 48G free area at the start was for ISO's was originally NTFS (or ExFAT) which I wanted to convert to Ext4, but it didn't work out like I planned.

As far as I can make out the boot loader is in the file /ventoy-1.0.97/boot/core.img.xz here:


github.com

Build software better, together

GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 420 million projects.
github.com github.com
 
Your GPT and bootloader are working fine. You do not need to copy the first 1MB or so as it won't change anything in fact it will damage the entire GPT partition and you will wipe the partition information for the rest of the disk then you will have a bigger problem because you will need to use the backup GPT at LBA -33 from the end of the disk to recover the partition information.

So you will need to recover the first partition (Part1) which hold the iso files.

Ventoy

Ventoy is an open source tool to create bootable USB drive for ISO files. With ventoy, you don't need to format the disk again and again, you just need to copy the iso file to the USB drive and boot it.
www.ventoy.net www.ventoy.net

You can create a new ExFAT partition !ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 (ms-basic-data) from 34 to 100788838 then format it as ExFAT and copy the data from another working installation.
 
VladiBG said:
Your GPT and bootloader are working fine. You do not need to copy the first 1MB or so as it won't change anything in fact it will damage the entire GPT partition and you will wipe the partition information for the rest of the disk then you will have a bigger problem because you will need to use the backup GPT at LBA -33 from the end of the disk to recover the partition information.

So you will need to recover the first partition (Part1) which hold the iso files.

Ventoy

Ventoy is an open source tool to create bootable USB drive for ISO files. With ventoy, you don't need to format the disk again and again, you just need to copy the iso file to the USB drive and boot it.
www.ventoy.net www.ventoy.net
Click to expand...

The first partition is no problem. I prefer ext4 rather than ExFat.

This 'should' work unless there are some typos...

Bash: 
gpart add -t linux-data -s 48G -l  Ventoy -b 2048 da0
mkfs.ext4 /dev/da0p1
mount -t ext2fs /dev/da0p1 /mnt
cp /media/*.iso /mnt

VladiBG said:
You can create a new ExFAT partition !ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 (ms-basic-data) from 34 to 100788838 then format it as ExFAT and copy the data from another working installation.
Click to expand...
 
I don't know how did you try to convert the partition at the first so it may still contain the original data in it. You can try testdisk to restore it to ExFAT and see if you can read something from it. If this fails then you can remove it and try to recreate and restore the data from other installation.
 
You must log in or register to reply here.
Back
Top