Jump to content











Photo
- - - - -

grub commands on bootable USB to completely ignore a partition


  • Please log in to reply
47 replies to this topic

#26 Zoso

Zoso

    Silver Member

  • Advanced user
  • 640 posts
  •  
    Isle of Man

Posted 08 July 2015 - 01:35 AM

hi Bill5858,

this looks very interesting! I dont use truecrypt but youre in good hands here and this thread has helped me understand more about grub4dos and partitioning for sure.

DiskCryptor is another good opensource program for encryption you may want to check into. no hidden OS with it though.


I like where this thread is going though.

thanks guys

#27 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14945 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 08 July 2015 - 08:37 AM

@Steve6375

Thanks for the news :), but in this case this solved bug (or added feature) :thumbsup: is counterproductive :w00t: as writing to a file in a NTFS will leave (obviously) traces in the $MFT, the idea (mine at least) was to have bill5858 get familiar with direct sector manipulation.

 

 @bill5858

Get to the grub4dos prompt.

 

Let's say that the hard disk is (hd0).

 

Type:

cat --hex --skip=446 --length=64 (hd0)0+1

[ENTER]

 

What are you looking at?

 

Make a copy of the MBR to sector 62:

dd if=(hd0)0+1 of=(hd0)62+1

[ENTER]

 

Copy the first entry to last entry in the MBR:

dd if=(hd0)0+1 of=(hd0)0+1 bs=1 count=16 skip=446 seek=494

[ENTER]

 

You should get the hang of it.... :)

 

Try playing with commands parttype, hide, partnew (running the cat --hex command every time), and/or try using this little batch:

http://reboot.pro/to...l-for-grub4dos/

(use the modified version by nando4 that needs not the added WENV module)

 

To restore the saved copy:

 

dd if=(hd0)62+1 of=(hd0)0+1

[ENTER]

 

 

:duff:

Wonko



#28 bill5858

bill5858

    Newbie

  • Members
  • 24 posts
  •  
    US Virgin Islands

Posted 10 July 2015 - 05:13 AM

Wonko,

 

I think I see where you are taking me.  I am not around the computer I need to be on to attempt this right now.  I know enough code to see you are asking me to copy out the partition table and then eventually play with moving the partition (16 bytes) to different slots.  If this method works it would mean there are NO marks on my drive from my use (assuming I write back the original partition table when I am finished).  All sensitive activities are on encrypted partitions.

 

I downloaded the file you linked (man you guys are in a different league with your coding skills).  I haven't tried it yet but tomorrow I should get on it.  If not, then Saturday at the latest.

 

I prepped a new grub flash with 0.4.6a and its flying along with my normal use of TrueCrypt.  I am going to dd the mbr and the partition table (separately with sfdisk) before starting so I can always get back to start with a few key strokes.  I have everything backed up many times over.

 

Should be interesting to see if TC will run with the slot three offset and extent in the number two slot.  [crossing fingers]  LOL!


Edited by bill5858, 10 July 2015 - 05:21 AM.


#29 bill5858

bill5858

    Newbie

  • Members
  • 24 posts
  •  
    US Virgin Islands

Posted 10 July 2015 - 09:02 PM

I think I might have it, but I want to verify my idea before I trash my hard drive.  I have been learning this for some time today.

First just to be clear I am going to backup the full mbr and partition tables before starting.  Accordingly:

Copy entire MBR:
dd if=/dev/sda of=mbrbackup bs=512 count=1
Restore entire MBR:
dd if=mbrbackup of=/dev/sda bs=512 count=1
Copy:
sfdisk -d /dev/sda > sda-part_table
Restore:
sfdisk /dev/sda < sda-part_table

-------------


Example:  swap partition slot 2 with partition slot 3 and mount TC

dd if=(hd0)0+1 of=slot2original bs=1 count=16 skip=462 [Enter]

dd if=(hd0)0+1 of=slot3original bs=1 count=16 skip=478 [Enter]

These two files are now saved to my grub4dos flash drive.

Time to boot up with bootable flash.  Insert flash and run menulst.

menulst:

dd if=slot3original of=(hd0)0+1 bs=1 count=16 skip=462

dd if=slot2original of=(hd0)0+1 bs=1 count=16 skip=478

continue on with menulst same as before the swap.


Obviously I will write a menu file to reverse the process returning the partition table to "original".

Do you think this will work?
 



#30 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14945 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 11 July 2015 - 11:59 AM

Example:  swap partition slot 2 with partition slot 3 and mount TC

dd if=(hd0)0+1 of=slot2original bs=1 count=16 skip=462 [Enter]

dd if=(hd0)0+1 of=slot3original bs=1 count=16 skip=478 [Enter]

These two files are now saved to my grub4dos flash drive.

Time to boot up with bootable flash.  Insert flash and run menulst.

menulst:

dd if=slot3original of=(hd0)0+1 bs=1 count=16 skip=462

dd if=slot2original of=(hd0)0+1 bs=1 count=16 skip=478

continue on with menulst same as before the swap.


Obviously I will write a menu file to reverse the process returning the partition table to "original".

Do you think this will work?


Yes and no. :w00t:

You normally DO NOT have "file creation" capabilities in grub4dos. :frusty:

The files slot2original, slot3original needs to be pre-existing (and you'd better use a path pointing to them AND a way to make sure that the devices involved are the "right" ones).

And, as said before, there could be issues (depending on grub4dos versions) to access files smaller than around 770 bytes on a NTFS drive.

Additionally, if the idea is to have the "saved" MBR of the hard disk on the USB stick, it would make sense to have on it also the "corrected" version, in the sense that the hard disk (and USB stick as well) are "block devices", the minimum amount of data accessible and writable is really-really 512 bytes (a block), when you directly read or write less bytes than that what really happen is that the block is accessed and copied to memory than the wanted subset is read (or written) and then (if written) the whole block is written back to block device.

 

So, it would be IMHO be smarter to have a file 1024 bytes in size on the stick, let's call it myfile.mbr, containing in the first 512 bytes the "original" MBR of the internal disk, and in the second 512 bytes the modified MBR, and simply dd either the first or the second half of the file to the hard disk MBR.

 

BUT, in the eventuality that your stick is found :w00t: :ph34r:, this file (or your two slotnoriginal ones) will also be found.

It would make (to me) much more sense to have ONLY a file "backuphd0.mbr", 512 bytes in size with the contents of the "normal" MBR of the hard disk that you can dd to restore the "normal" situation, the presence of this file can be justified any time as it is a common backup (that everyone should have) of the MBR (and could also reside on the actual hard disk, as said even not as a file but as a backup sector, written to one of the not-used "sectors before", like the suggested 62).

 

As hinted before it would be IMHO much more secure if you learned by heart a set of numbers (call it poorman's password) and used these two sequences of numbers MANUALLY TYPED with the partnew command to either enable in the hard disk MBR the relevant partiitions. (I am not entirely convinced that yu actually need to alter two partitions entries, adding/modifying one should do nicely :dubbio:)

 

Example:

http://diddy.boot-la...nds.htm#partnew

partnew (hd1,1) 0x07 127890 2589668

partnew (hd1,2) 0x07 2717558 34558880

 

Of course the numbers in the above example are arbitrary and they need to be changed to your actual partitions locations and extents, and you could use hex numbers to shorten them, 0x1F392 0x2783E4, 0x297776 0x20F53A0, or "hide them" in some known places anywhere on the disk.

 

By typing these two commands you would have access to the TC partition.

To go back to the same situation as before you would do:

dd if=(hd1)62+1 of=(hd1)0+1

 

and possibly (it depends on how exactly the booted OS behaves, tests are needed, once booted to the OS in the TC partition you may even be able to do the same from the booted OS :unsure:, i.e. it is likely that you could put up an "emergency button" that restores the original MBR and shuts down the system (or just restores the original MBR before you hit the power off button).

 

As hinted earlier, nothing that a million-dollar cluster $5 wrench cannot solve:

Spoiler

 

 

Of course you should NOT EVEN THINK of carrying the experiments on the real hard disk, use a VM or some other "expendable" device to experiment/test.

 

:duff:

Wonko



#31 bill5858

bill5858

    Newbie

  • Members
  • 24 posts
  •  
    US Virgin Islands

Posted 11 July 2015 - 06:36 PM

Couple of notes:

 

1. I forgot about the 512 byte (block minimum).  You are right in that I may as well directly write the full 512 byte mbr since its going to happen anyway!

 

2.  I am using the newest grub4dos 0.4.6a, as per Steve's recommendation, because it supposedly eliminates the ntfs small file (< 770 bytes) errors.

 

3.  I actually planned to create my files (MBR, slot N originals, etc..) using the command panel on Win 7.  I completely misworded that part of my post badly.  As far as path, I assumed that if I then copy needed MBR files to flash root, they would be found by dd.  Assuming of course the names are correctly entered.

 

4.  Because of how I use these computers and all the software encyrption, I have their full MBR's backed up numerous times on bootable recovery media already.  I can repair/rebuild oooooppppppssss stuff in my sleep.  I am the classic backup-aholic.

 

Whether I use a 1024 byte (dual mbr) single file, or two 512 byte MBR files on the flash seems to be the same thing.  In the case of "physical discovery" of the flash either instance places me in the same predicament.  That being the case I feel it would be less likely for me to make an "operator error" by naming the two mbr files meaningfully for myself.  e.g. Laptop-MBR  & Updated-MBR (could be any name of course).

 

So, lets say I have created all the MBR needed files.  In reality then it would come down to TWO 512 byte MBR files being copied to the grub4dos flash root.  All my procedure instructions and tools used to create these files, would be saved and backed up on encrypted removable media.  I could then re-create new files anytime I made a partition change of any kind.

 

Example scenario:  I am grabbing my laptop to boot it up to the hidden OS.  It was put away with the original MBR (Laptop-MBR) written on the actual disk.  So I simply grab the grub flash and power up:

 

menulst:

 

dd if=Updated-MBR of=/dev/sda bs=512 count=1

 

continue with menulst same as before project.

 

I should see the password screen and if I enter it correctly, it should be good to go.

 

I am going to go prepare those new MBR files in the next few hours.

 

 

Another thing, and you had mentioned it above too.  I was planning on testing out whether or not I would be able to just place a nifty little dd script on the desktop that would quickly return the original MBR to the disk.  I mean how difficult is it to dd a mbr file back?  Either the hardware/OS will allow it or it won't.  I will let you know how that goes IF the rest of this thing gets me booted up.

 

Don't give up on me with learning to MANUALLY enter commands either.  First I need to know this works.

 

One of the reasons I decided to alter/swap both partitions instead of one is that I think all the partitions will "show up" (WinEx) if their values are in the PBR at least somewhere.  Don't know, guess we'll see.



#32 bill5858

bill5858

    Newbie

  • Members
  • 24 posts
  •  
    US Virgin Islands

Posted 11 July 2015 - 09:19 PM

Skipped Windows using Linux Ubuntu.

 

I don't like Windows for this editing task so I decided to simply use Linux.  Connected my bootable USB external (Ubuntu) and booted it on the computer with Windows on hard drive.  Using dd and I can easily see the MBR on the Windows hard drive.  Copied out original MBR and made backup of partition table using sfdisk too.  Then I copied out slot2 and slot3 original partition code as mentioned above in this thread.  Verified both slot files are 16 bytes on my Linux system user's screen.  Saved and ready to to.  Wrote the full MBR back to confirm the process and all is working fine so far.

 

With my two saved partition slot files I decided to actually write those 16 byte files to the desired location on the physical disk.  My plan was to write those two 16 slot files to the actual MBR, and then save the NEW Updated-Mbr and test the project for workability.

 

Problems, I am assuming maybe because 16 bytes is less then a full sector.  Hmmmm?

 

Here is a copy of my dd command line - where I am attempting to write/copy the saved slot3original file into the slot 2 position:

 

sudo dd if=slot3original of=/dev/sda bs=1 count=16 skip=462

 

linux terminal:     "cannot skip to specified offset"

 

This restriction (whatever it is) does not apply when I copied the original 16 bytes directly to a file on my linux user's system.  As mentioned, both slot files are exactly 16 bytes as they should be.

 

Is there some flag or command switch I can use to allow dd to write this 16 bytes where they need to go?  A manual over-ride of sorts?  Repeating, when I write the full MBR its smooth and fast.  I have booted the Windows machine a couple of times and all is well there!

 

I know I can accomplish this in a hex editor by changing the full mbr file accordingly.  That would not be as easy and I have several computers to do this on if it works.


Edited by bill5858, 11 July 2015 - 10:10 PM.


#33 bill5858

bill5858

    Newbie

  • Members
  • 24 posts
  •  
    US Virgin Islands

Posted 11 July 2015 - 10:18 PM

You know I have been thinking about this and I am wondering if "zero'ing out slots 2 and 3 before trying to write the new table might make this work.  Think about it.  When I tried to write the slot3 info into slot 2, the original slot3 info, WITH THE EXACT SAME OFFSET AND EXTENT, was still on the disk.  I can only write one slot at a time this way.

 

I may zero those slots and try it again.  Think I may be on to something?

 

In all honesty I think its a 512 byte sector thing.  Will only take a few seconds to try it though.  I can write the original back in seconds if it flops.


Edited by bill5858, 11 July 2015 - 10:22 PM.


#34 steve6375

steve6375

    Platinum Member

  • Developer
  • 7034 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 11 July 2015 - 10:27 PM

re. dd command

Note the use of skip= and seek=

skip is used for the input stream, seek for the output stream

so try

sudo dd if=slot3original of=/dev/sda bs=1 count=16 seek=462


#35 bill5858

bill5858

    Newbie

  • Members
  • 24 posts
  •  
    US Virgin Islands

Posted 12 July 2015 - 04:01 AM

Man talk about a "brain fart". LOL! Can't even believe I missed that. Wrote like a charm after the correction.

Good news and bad news.

Bad first:
The process did not pass in that TC found the second partition offset and extent anyway. I was hoping that transpositioning offsets and ext would have worked. Because TC found that info, the hidden OS wouldn't boot. It did the search for the headers in the wrong place. Just so you know I have been using this software for years including compile and code search. I trust this software but it has its quirks.

Good news:
After thinking about a TC code peculiarity (and staying with the example I have been presenting in this thread) I decided to try another route. I wrote back the original MBR and verified it in an editor. Next I decided to experiment with /dev/zero of the #2 partition slot ONLY (16 bytes). Having done that it worked like a charm and booted immediately.

For now I have inserted quite a bit of data in the second partition. I want to see if it becomes contaminated in some way while using the hidden OS with a partition slot zero'd. Read comments below.

For those not familiar with TC code: I do use modified code on some features, however on this feature I have left the hard drive "trunk" locked as read only. TrueCrypt code (public binary) designates that all areas on the hard drive, which are outside of the hidden OS are READ ONLY. While this feature has proven to frustrate the masses, in this case it might be a super benefit. So far, I have seen absolutely nothing change on the partition that I zero'd the slot on. Of course I am not using that during hidden operation, but just the same I am monitoring and looking for any changes. In the next day or so I'll do a full text editor on the entire partition looking for any abnomalities. It might be that the READ ONLY block in the software could just prove to be a life saver for this particular process. I still have other personal ways "out" to save data, but I won't open the hard drive to writes at all.

By restoring the original MBR, which takes a split second (512 bytes), the Windows machine boots normally. I have full access to all partitions and all encryption appears to be intact since all volumes are opening just fine.

I should have NO marks on the disk anywhere that provide a forensic clue as to what I am doing here when the hidden OS is not mounted.

Wonko,
I have taken your MUCH APPRECIATED suggestions to heart. I created a grub4dos boot flash with a restore MBR on the root. I have a menu script file to simply write the mbr back as any normal user "should" have available for when problems arise. I can quickly and easily edit the menu file manually and add /dev/zero in a few seconds as line one. Just click and its written and the TC PBA screen pops up and I am ready to type. Nice so far! I am going to wipe the flash again and re-install grub4dos. Thanks to your suggestions EVEN the grub4dos flash is not going to be a forensic "loose end".

Am I correct in assuming that since I am manually editing in the /dev/zero line (but not saving it to file/flash), the flash would remain forensically clean? I think this is a valid question.

Its too late tonight, but in the next day or so I'll find out if the sda boot sector is outside TC code's READ ONLY lock. If not I'll write a quick script on the desktop to restore the original partition table as soon as I mount the hidden OS. That would make it "pull the plug" secure. Stay tuned.

Edited by bill5858, 12 July 2015 - 04:17 AM.


#36 bill5858

bill5858

    Newbie

  • Members
  • 24 posts
  •  
    US Virgin Islands

Posted 12 July 2015 - 05:43 AM

Simple question for you guys.  Sometimes there are many ways to skin a cat.

 

Using dd on my linux box I zero the 2 slot with this command:

 

sudo dd if=/dev/zero of=/dev/sda bs=1 count=1 seek=462

 

Reading around I see different ways to do this from my flash root using grub4dos.  It comes down to what is best to define the path to the boot sector.

 

In your experience what is the best command line to the boot sector from the flash root?  (hd0)0+1, (hd1,0), etc... ?  Please feel free to edit my command line above with your preferences.  Thought I would benefit from all the experience here.



#37 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14945 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 12 July 2015 - 10:25 AM

Using dd on my linux box I zero the 2 slot with this command:
 
sudo dd if=/dev/zero of=/dev/sda bs=1 count=1 seek=462

No, you don't. :w00t: :ph34r:
You are writing 1 byte with "bs=1 count=1", not 16.
 

Reading around I see different ways to do this from my flash root using grub4dos.  It comes down to what is best to define the path to the boot sector.
 
In your experience what is the best command line to the boot sector from the flash root?  (hd0)0+1, (hd1,0), etc... ?  Please feel free to edit my command line above with your preferences.  Thought I would benefit from all the experience here.

Devices have a syntax:
http://diddy.boot-la...iles/syntax.htm
This:
(hd0)0+1 means first sector of first disk (more specifically the extent of length 1 sector at offset 0 of the disk - whole thing)
represents an offset and an extent.
This:
(hd1,0) means the partition in first slot of second disk
it may represent only an offset or the whole device or the corresponding slot depending on the context of the specific command.

The MBR is first sector of a disk (whole thing).
The bootsector (or PBR or VBR) is the first sector (or first few sectors) of the partition or volume.

As you were told, try READING about grub4dos commands and experiment with them, what do you think that commands:
partnew (hd0,0) 0 0 0
partnew (hd0,1) 0 0 0
partnew (hd0,2) 0 0 0
partnew (hd0,3) 0 0 0
do? :dubbio:

:duff:
Wonko

#38 bill5858

bill5858

    Newbie

  • Members
  • 24 posts
  •  
    US Virgin Islands

Posted 13 July 2015 - 03:02 AM

You are writing 1 byte with "bs=1 count=1", not 16

 

Simple typo in my thread post, I was entering it correctly on the keyboard!

 

Sorry, but I simply must admit I can't get this for some reason!!

 

Using my Linux usb I enter: dd if=Laptop-MBR of=/dev/sda bs=1 count=512 and I can write the file all day long.  Go the the grub flash and its a different story because I just can't get the syntax correct.

 

I put the Laptop-MBR on the flash root and I can see it clear as day doing the ls command on the grub prompt.  Best I can figure after hours of trying to figure this out is that I am stuck.

 

Tried such lines (from the grub prompt on the flash) as dd if=Laptop-MBR of=(hd0,0)0+1 bs=1 count=512 and MANY other combinations but I can't seem to get the device/path correct.  Yes I have been reading.  (hd0) is the hard drive, (hd0,0) is the first partition on the hard drive, etc...

 

Error 11 "unrecognized device string, or omitted the required DEVICE part which should lead the filename"  seems to be my new mantra.

 

I guess my "mental computer" just doesn't work like back in the Vietnam era.  I'll blame "agent orange".  LOL!

 

If you can convert this --- dd if=Laptop-MBR of=/dev/sda bs=1 count=512  to the syntax I need to do the same thing from the flash root I'll be grateful.

 

So far reading is not getting it done, and for that I am embarrassed some!!



#39 steve6375

steve6375

    Platinum Member

  • Developer
  • 7034 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 13 July 2015 - 06:08 AM

You may find my grub4dos guide useful.

 

Some points when using dd in grub4dos

 

1. You must specify the device part of the path for if and of  - e.g.  if=()/somefile.txt

2. The of file MUST already exist and be large enough to hold whatever data you want to put in it

3. Use the 2015-06-05 0.4.6a version (note that many versions of both 0.4.5c and 0.4.6a have bugs!!! - e.g. the latest 0.4.6a 2015-07-12 and 09!).



#40 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14945 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 13 July 2015 - 08:57 AM

Well, of course you need some time to get familiar with the environment :)

 

Error 11 "unrecognized device string, or omitted the required DEVICE part which should lead the filename"  seems to be my new mantra.

 

 

However:

 

 

The files slot2original, slot3original needs to be pre-existing (and you'd better use a path pointing to them AND a way to make sure that the devices involved are the "right" ones).

 

:whistling:

 

Also, when making things, make them as simple as possible, if the file is 512 bytes in length, you don't need to specify block size and count .

dd if=(hd0,0)/Laptop-MBR of=(hd0,0)0+1

 

In case, and though it won't matter in this specific case, this one:

dd if=(0,0)/Laptop-MBR of=(hd0,0)0+1 bs=1 count=512 basically means "loop 512 times transferring one byte at each loop"

while this:

dd if=(0,0)/Laptop-MBR of=(hd0,0)0+1 bs=512 count=1 basically means "loop 1 time transferring 512 bytes at each loop"

 

Guess which one is faster? :dubbio:

 

The block size, if not specified on command line, is by default 512 bytes in grub4dos.

 

The () in grub4dos means "current root", i.e. it corresponds to the output of the root command.

 

:duff:

Wonko



#41 bill5858

bill5858

    Newbie

  • Members
  • 24 posts
  •  
    US Virgin Islands

Posted 15 July 2015 - 08:38 PM


Also, when making things, make them as simple as possible, if the file is 512 bytes in length, you don't need to specify block size and count .

dd if=(hd0,0)/Laptop-MBR of=(hd0,0)0+1

 

Doesn't work on my end.  Don't know why.

 

I have been approaching this for days now.  The cat --hex commands are really helpful.  I am able to view the partition tables all day long,  I can view anything I ask for.  For some reason when I do a write it doesn't go where I think I told it to go. Stepping back just to see if this looks OK to you.

 

Grub > find

(hd0,4)    note: fat32 my grub4dos flash

(hd1,0)

(hd1,1)

(hd1,2)   note:there are only three partitions on the hard drive

 

grub> root

(hd0,4)

 

looking at partition tables in grub4dos

 

cat --hex --skip=446 --length=64 (hd0)0+1

partition slot ONE filled with data, the three other slots are zero's.

I am presuming this is my grub4dos flash on one partition.

 

cat --hex --skip=446 --length=64 (hd1,0)0+1

shows a partition table filled in the first three slots, but the fourth is zero's.  This is my hard drive because the test disk I am using has three formatted partitions and the rest is unallocated.

 

Tried a few other lines (Please know I am trying).  I have rebuilt my system disk several times.  The test disk is small and restoring from backup is around 6 minutes block to block.  I am actually more comfortable this way than my VM's.

 

Suggestion pasted above:

 

dd if=(hd0,0)/Laptop-MBR of=(hd0,0)0+1

 

returns error 30 Invalid Argument

 

 

I am not using a menulst file at this point.  All commands are simply being input at the grub > prompt.

 

The Laptop-MBR file (along with several other saved files) were prepared using conventional dd on a Ubuntu USB external, which is connected to the same machine.  I know the files are valid because I can write them directly to the hard drive and fire windows up without fail.  When I write a zero table file the partitions I want to hide don't show as expected.  I write normal mbr files and they are all back.  Just trying to stress I don't think its a hardware problem because when using Ubuntu and dd I can do this until my fingers bleed and never have an issue.

 

I don't think its a grub4dos issue either because when I use a menulst file on the flash, which is up at the top of this thread, it runs fine.  I am not really writing files though I am only authenticating the TC password.

 

Just betting that if Wonko or Steve were sitting here this would be up and running in seconds flat.  It seems to me that since I can do this so easily in dd, that learning the grub4dos syntax shouldn't be this deflating.

 

Is there anyway you can think of to direct me to check for a possible hardware incompatibility of sorts?

 

For now I am "up a creek and I have NO paddle".



#42 steve6375

steve6375

    Platinum Member

  • Developer
  • 7034 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films,guitars, www.easy2boot.com
  •  
    United Kingdom

Posted 15 July 2015 - 10:15 PM

Either you have made several typo's in the previous post, or you don't understand the difference between (hd1) and (hd1,0).

 

cat --hex --skip=446 --length=64 (hd1,0)0+1
shows a partition table filled in the first three slots, but the fourth is zero's.  This is my hard drive because the test disk I am using has three formatted partitions and the rest is unallocated.

 

 

 

(hd1,0)0+1  will display the Partition Boot record of the first partition on hd1 - it does NOT display the MBR or the partition table!

 

I suggest you look at the difference between MBR and PBR's. I suggest here for a good reference.

 

As for the command

 

dd if=(hd0,0)/Laptop-MBR of=(hd0,0)0+1

returns error 30 Invalid Argument

 

 

Is this under a VM or a real system?

If you use the command  

ls (hd0,0)/Laptop-MBR

is the file listed?

 

From your description, it sounds like grub4dos is on (hd0,4) not (hd0,0) ?? - so shouldn't it be (hd0,4)/Laptop-MBR ?



#43 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14945 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 16 July 2015 - 08:12 AM

To be fair, a (good ;)) example was provided:

http://reboot.pro/to...e-2#entry193583

making use of anotherwise unused sector instead of a file and an explanation of how devices are referred to were given:

http://reboot.pro/to...ition/?p=193671

 

When in doubt, try replacing the syntax used with the meaning, like:

dd if=(hd0,0)/Laptop-MBR of=(hd0,0)0+1

means:

"copy in binary form a copy of the MBR residing on the NON EXISTING first partition of first disk :w00t:  to the PBR (first sector of first partition, still NON EXISTING) overwriting it's contents"

Allow me to doubt that this is what you really want. :dubbio:

 

Le'ts recap :)

(hdn)0+1 is the first sector of the disk n (whole thing) first absolute sector of the device or LBA0

Contains, starting at offset 446 4 slots, each 16 bytes in size:

(hdn,0) is the address registered in first slot of the MBR on disk n, (hdn,0)0+1 is the PBR/VBR (or bootsector or Partition Boot Record or Volume Boot Record)

(hdn,1) is the address registered in second slot of the MBR on disk n, etc.

(hdn,2) is the address registered in third slot of the MBR on disk n, etc.

(hdn,3) is the address registered in fourth slot of the MBR on disk n, etc.

-----------------------------------------------------------------------------------------------------------------------------------------------------

55AA <-imagine this as being the end of the MBR, basically because it is the end of it ;)

-----------------------------------------------------------------------------------------------------------------------------------------------------

(hdn,4) is the address registered in fifth slot of the MBR on disk n :w00t:, no wait :whistling:, there are no more than 4 slots in the MBR :ph34r:, if a fifth slot exists it means that one among the 4 slots (hdn,0)-(hdn,3) contains an EXTENDED PARTITION, and then (hdn,4) is FIRST SLOT in the EPBR (Extended Partition Boot record) or FIRST (logical volume) inside the Extended partition, and consequently (hdn,4)0+1 is the VBR sector.

 

 

:duff:

Wonko



#44 bill5858

bill5858

    Newbie

  • Members
  • 24 posts
  •  
    US Virgin Islands

Posted 16 July 2015 - 08:13 PM

Dual comments:

Either you have made several typo's in the previous post, or you don't understand the difference between (hd1) and (hd1,0).

Le'ts recap :)
(hdn)0+1 is the first sector of the disk n (whole thing) first absolute sector of the device or LBA0
Contains, starting at offset 446 4 slots, each 16 bytes in size:
(hdn,0) is the address registered in first slot of the MBR on disk n, (hdn,0)0+1 is the PBR/VBR (or bootsector)


Steve and Wonko I snipped these two segements from above. Thanks. I think I see it now, but I can't be certain yet.

I am going to re-do my grub4dos flash(s) because I think something is corrupted. I notice you also questioned the root being (hd0,4) instead of (hd0,0).

To be truthful I now feel I am fighting hardware. I am using the grubinst-1.1-bin that I did with all my other computers in the past. I just noticed that while launching the gui.exe (in Admin mode) on a windows 7 desktop, that I cannot see any "disks". Not even the hard drive. Never had that happen before. There is no sense in going any further of course until I can see a Disk of any kind. Hmmmm?

I am going to a friends house to try and run the flash setup there just to see. Seriously, making a grub4dos bootable flash should be child's play.

Just checking, the 64 bit OS isn't a factor is it?

Edited by bill5858, 16 July 2015 - 08:14 PM.


#45 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14945 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 17 July 2015 - 08:57 AM

Seriously, making a grub4dos bootable flash should be child's play.

It is, rest assured. :)

 

Only, you are somehow mixing two things:

1) partition and formatting properly the USB stick <- that may be in some cases be non-trivial

2) replace the MBR Code with the grub4dos one on the MBR +  a few hidden sectors.

 

From what you report you have no issues with #2 but most probably some issues with #1, now be nice, forget about anything else (temporarily), simply get RMPREPUSB and use it to do BOTH #1 and #2 in a single step:

http://www.rmprepusb...ick-start-guide

You want to select HDD C: 2PTNS, probably NTFS, and WinPE V2 ... etc, then press the install grub4dos button.

 

This will produce an "as working as possible" USB stick, with one large partition and a tiny (invisible) partition.

Later, once you will have become more familiar with grub4dos, we will talk on how to re-partition and re-format it (if needed).

 

:duff:

Wonko 



#46 bill5858

bill5858

    Newbie

  • Members
  • 24 posts
  •  
    US Virgin Islands

Posted 17 July 2015 - 05:13 PM

Ok I am back.  I just downloaded the stuff from Steve's site.  I elected to use the portable version for now.  I am currently on my linux box so I can use a Windows VM shortly.

 

1. I did do a "clean all" on ONE 2 gig flash and then created a simple volume and formatted it Fat32.  I did that on a Windows 7 VM and I was easily able to install grub4dos using the install gui.exe.  The grub4dos flash is showing root (hd0,0), which is what it should show.  Process is very painless.

 

In following your guidance I ALSO downloaded the zip from Steve's place (you linked above).

 

2.  I am going to create another grub4dos FLASH using Steve's stuff and then I can compare the process as I go forward.

 

When I come back I'll have both flash drives ready to proceed.  Back shortly.



#47 bill5858

bill5858

    Newbie

  • Members
  • 24 posts
  •  
    US Virgin Islands

Posted 17 July 2015 - 07:42 PM

I am back and I have both flash devices ready to go, or so I think.  Both are showing root as (hd0,0).  The device I prepared using the older 1.1 grubinst exe (which works great and is simple) is formatted as fat32.  rmprepusb, which also was easy to navigate and is sooooooo professional looking, shows the stick as being FAT, even though I selected Fat32.  I did select the config options you suggested otherwise.

 

 

I have something that is jumping off the page as WRONG/amiss with my actual hard disk.  I used a 7 VM on my linux machine to create these flash sticks.  In the past everything has gone smoothly, just as today with preparing these devices.  I mean, it is easy ---- usually.  NOW  take these flash sticks over to my ACTUAL laptop, which is using 7 Pro normal/unencrypted, and we have something going on.  I inserted them to "act" like I was going to prepare them again just to test something.  BOTH rmprepusb portable, and the gui exe older script don't see the flash devices.  The older script doesn't even see the hard drive in DISK, let alone seeing the flash drive.  rmprepusb calls them RMPARTUSB.  Running both of these "programs/scripts" from the 7 system disk desktop yields results that are not looking friendly.  I need to insert that this not seeing the flash sticks was happening even on fresh "clean all"/create partition/format using windows scenario.

 

 

btw  ---- both of these flash devices boot to grub > and are fast and smooth during the process.

 

I placed the TC iso on a menulst file and I can easily boot TC from either of these sticks.  The issue comes when I try to use grub4dos to write anything instead of read it (seems to me) only.

 

So I am contending that something is "jacked" on my actual hard disk config.

 

I cannot imagine why BOTH programs do not see ANY disks.  Something is wrong there, and I think that is why I am beating my brains out here.  It would literally only take me a couple of hours to scrub and re-write the hard drive.  I have "point and click" clean backups.  I would entertain any thoughts before doing so.  To the naked eye this machine is lightning fast and is running like a new machine.  I see no evidence that anything is amiss, but something gives.


Edited by bill5858, 17 July 2015 - 07:44 PM.


#48 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 14945 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 18 July 2015 - 09:42 AM

What you report is confusing. (or you are confused ;)).

 

Two completely different and separated issues.

 

#1 Windows 7 install not "seeing" the USB stick:

Likely you have *somehow* a botched setting somewhere in the Registry, in a booted Windows the moment you insert a USB stick it should popup on the taskbar the "new device connected" baloon and the "Safely Remove Hardware", in which you should see both the device and the volumes found in it (auto mounted to a drive letter) and if you go to Disk Manger you should see a PhysicalDrive or "Disk" added.

Often, but not always, this can be solved by cleaning the Registry iof the excessive bloat caused by connecting a zillion USB devices, see:

http://www.msfn.org/...sconnect-delay/

 

#2 This has nothing to do with the above, if you boot to grub4dos your (minimal) running OS is grub4dos and *anything* on the actual hard disk has NOTHING to do with its workings (or failure to work).

Reports like "I try to use grub4dos to write anything instead of read it (seems to me) only." are meaningless, post the commands you issue, the result you obtain and what would have been instead the result you expected, Standard Litany, please:

http://homepage.ntlw...ard-litany.html

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users