Jump to content











Photo
- - - - -

Booting WimPE(s) & Linux Live(s) on the PC from the Micro SD on my smartphone


  • Please log in to reply
55 replies to this topic

#26 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 15 October 2019 - 11:14 AM

That is odd! Sorry but there should be some difference.

 

Could you repeat the whole thing again? Make sure the BAD files don't boot and the SYNC files do.

 

P.S. You are switching off the system each time? You must do this on an 'unknown' system because some BIOSes only look at the USB drive geometry on power up and not on  ctrl-alt-del or warm reboot. This can cause lots of confusion!

 

 

e.g. This is what can happen on these computers with a 'bad' BIOS and it can be very confusing!

  1. Boot to Windows
  2. Reformat/partition USB drive
  3. Restart Windows
  4. >>> USB drive does not boot
  5. Ctrl-alt-Del
  6. >> USB drive does not boot
  7. Switch off power to computer
  8. Switch on power - BIOS does full Power On Self Test + look at new USB drive geometry
  9. >>> USB drive boots!

 

So ALWAYS switch off computer (not standby but power off) and on again when testing a USB drive which has just been re-partitioned or reformatted.



#27 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 15 October 2019 - 11:22 AM

I have been rebooting, I'm running Win7 now so there is no fast boot available (and on 10 It's disabled too), but will do as you said. I will reboot the phone only once before starting the test too.



#28 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 15 October 2019 - 11:53 AM

Repeated test info attached.

 

NOTE: when PC is turn OFF the mass storage is deactivated and I have to reenable it.

 

alacran

Attached Files



#29 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 15 October 2019 - 12:32 PM

hmmm - so only difference is in the 2nd sector of the VBR\PBR

 

Boots OK

03E0 00 00 00 00 72 72 41 61 - 86 DE 02 00 1D 05 00 00  ....rrAa †Þ.....

 

No Boot

03E0 00 00 00 00 72 72 41 61 - 86 DE 02 00 6F 14 00 00  ....rrAa †Þ..o..

 

I am not sure what these bytes are ??? Possibly they were changed because you booted to an OS?

 

But grub4dos 'geometry --sync (hd0)' must write something because it permanently 'fixes' the drive.

Anyone any ideas what else it might change?



#30 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 15 October 2019 - 12:49 PM

I am not sure what these bytes are ??? Possibly they were changed because you booted to an OS?

https://thestarman.p...mbr/MSWIN41.htm

 

:duff:

Wonko



#31 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 15 October 2019 - 02:58 PM

Possibly they were changed because you booted to an OS?

 

6F 14 00 00 double word Next Available Cluster

 

It could be adjusted/changed by an OS.

 

 

 

But grub4dos 'geometry --sync (hd0)' must write something because it permanently 'fixes' the drive.

Anyone any ideas what else it might change?

 

geometry --sync only changes geometry, i.e., C, H and S values. Nothing else will be changed.



#32 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 15 October 2019 - 03:14 PM

geometry where? In MBR?

Nothing appears to have changed, yet after a  geometry --sync command, the drive appears to be permanently 'fixed'



#33 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 15 October 2019 - 03:45 PM

geometry where? In MBR?

Nothing appears to have changed, yet after a  geometry --sync command, the drive appears to be permanently 'fixed'

 

Possibly changes are in MBR (partition table, starting CHS and ending CHS) or in VBR/PBR (BPB Heads / Sectors-per-track).

 

Nothing changed? Perhaps the values are already correct and need not change.

 

Edit:

 

Perhaps you need

 

geometry --tune (hd0)

 

before

 

geometry --sync (hd0)

 

 

The --tune will adjust the H and S to be the correct value, that is, the current BIOS actually uses. Then --sync will write the correct value to disk.

 

 

 

 

 

 

 

 



#34 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 15 October 2019 - 04:09 PM

See previous post

tune did not seem to do anything

sync  said it was adjusting CHS

After that, the drive would then boot to grub4dos

but before geometry --sync, the drive would not boot  to menu.lst and could not access  hd0 USB drive.



#35 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 15 October 2019 - 04:38 PM

tune will adjust the actually-used CHS values. These values are internally used by grub4dos CHS int13 call.

 

If not tuned, the internal CHS values could be wrong, ie, it might not match the ROM/BIOS ones.

 

After tuned, the CHS values will be correct, and match the current ROM BIOS.

 

The tuned value is not written to disk. It is in memory. The sync will write the tuned value(in fact ---- the functioning value, or the working value) to disk.

 



#36 steve6375

steve6375

    Platinum Member

  • Developer
  • 7566 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 15 October 2019 - 04:41 PM

yes.

 

But we had

 

1. SD card booted to grub4dos prompt - would not load menu.lst - just gave grub4dos prompt - no hd0 accessible

2, In grub4dos prompt,  geometry --sync (hd0) was  done  (--tune did not appear to do anything?)

3. Now SD card will boot to grub4dos and load menu.lst (permanent fix)

 

BUT

 

There seems to be no difference in MBR or PBR after  --sync command ?



#37 tinybit

tinybit

    Gold Member

  • Developer
  • 1175 posts
  •  
    China

Posted 15 October 2019 - 04:57 PM

Perhaps it changed MBR/PBR, but the user goes into Windows or Android to capture the sector data, which might have been re-adjusted / restored / re-changed by the OS.



#38 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 16 October 2019 - 01:23 AM

@ tinybit

 

Perhaps it changed MBR/PBR, but the user goes into Windows or Android to capture the sector data, which might have been re-adjusted / restored / re-changed by the OS.

 

In fact to run RMPrepUSB as suggested, I did it from the PC OS.

 

@steve6375

 

This C/H/S is not tipical when formated by Win or by RMPrepUSB as I did first time, before using this SD.

 

I start remembering during the past 2 or 3 years of use Android said the SD was corrupt and required to be reformated, giving the option to do it, and I acepted it (not sure it was this phone or my wife's phone or both), but this may explain the non Win usual C/H/S it has (or at least when seen from the phone), because when seen it from Win with BootIce it is still XXX/255/63

 

Anyway as far as now PC is booting fine from the phone SD and finds menu.lst always, I will thake this as Problem Solved.

 

Thanks very much to both of you.

 

alacran



#39 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 16 October 2019 - 08:25 AM

Anyway as far as now PC is booting fine from the phone SD and finds menu.lst always, I will thake this as Problem Solved.

Though your problem is solved, the actual problem (which is - or should be - to understand what happened, how and why) isn't :(.

:duff:
Wonko



#40 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 16 October 2019 - 05:54 PM

The damn hardware and software of the phone is the answer to that question.



#41 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 16 October 2019 - 07:07 PM

The damn hardware and software of the phone is the answer to that question.

No, it isn't, or if you prefer they represent a non-answer, but if you like to believe that, be my guest and feel free to buzz over to the next flower :)

 

:duff:

Wonko



#42 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 October 2019 - 07:47 AM

Well, of course I respect your opinion, as you should respect mine, but let me tell you I didn't like your comment, it has no bases:

 

No, it isn't, or if you prefer they represent a non-answer, but if you like to believe that, be my guest and feel free to buzz over to the next flower :)

 

:duff:

Wonko

 

Steve fix rewrote to SD MBR the C/H/S (uncommon XXXX/4/16) the phone sees or likes to use and since then no more isues to find menu.lst

 

And if it is booting fine now, and from Windows the partition is still seen by BootIce as XXXX/255/63 (maybe because it can't believe the strange values, and then replace the reading with the usual values) and from inside the phone when booting it is still seen as  XXXX/4/16 my statement has solid support and you can't prove my statement is wrong or not valid:

 

The damn hardware and software of the phone is the answer to that question.

 

And there is nothing we can do to fix the internal hardware and software code of the phone unless rewriting or patching the Android version on the phone.

 

Also remember what is said to alcoholics, my own understanding of the sentence is: If you can't fix it, let it be.

 

Still your friend.

(even getting from you not respectful comments sometimes).

 

alacran



#43 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 17 October 2019 - 10:21 AM

The whole point is that there is no evidence of any change in the MBR (nor any meaningful one in the PBR),

 

http://reboot.pro/to...phone/?p=213052

 

So it is *sheer magic* or *voodoo*.

 

As said, if you are happy with this explanation (which is a non-explanation) is fine :), but you shouldn't call that an explanation or the problem "solved".

 

About geometry, as I already tried telling you:

http://reboot.pro/to...phone/?p=212994

it may well depend on the Windows system and BOOTICE (which is a very good tool BTW) is very likely misleading you providing the geometry that windows senses (which is not the device geometry used in the partitioning/formatting) because BOOTICE is simply NOT the "right" tool for this kind of checks.

 

BTW we had - at the same time - a very similar issue with the libreelec image that actually needed a small fix in the PBR (that in that case the commands geometry --bios, --tune or --sync could not resolve), but this fix is permanent, and as well if geometry --sync actually wrote something somewhere the change should be "permanent" and "findable".

 

:duff:

Wonko



#44 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 October 2019 - 11:11 AM

The way I see it is:

 

The first time I ran:   (and reported results on Post: http://reboot.pro/to...e/#entry213017)

 

geometry --sync (hd0) >>> A message appeared saying:

Writing MBR for drive 0X80 ...sucess.

Partition num: 0, active, file system Fat 32, partition type 0X0C ...

Then I pressed ESC key and the menu.lst was visible finally.

 

Rebooted the PC twice and menu.lst appeared inmediatly as it usually does.

 

Then it is a fact geometry (XXXX/4/16) was written to MBR of SD, since now menu.lst is found on every subsequent boot.

 

Then when all other tests that were made latter running again (as per steve request) geometry --sync (hd0)

 

Didn't change anything since they were rewriting to MBR same geometry again and again.

 

IMHO with all due respect to steve6375 the subsecuent test http://reboot.pro/to...ne/#entry213021Should be made BEFORE running geometry --sync (hd0) the first time and then we will find significative differences having the info before applying the change and after applying the change to compare.

 

Now you see how I annaliced it, perhaps you didn't think in this detail.

 

alacran



#45 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 October 2019 - 11:46 AM

About BootIce info in this scenario let's put it out of the equation, as we both seem to be agree, that for whatever reason, it is giving wrong info on this case.

 

But nevertheless is good to know it is not trustable on cases like this.

 

alacran



#46 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 17 October 2019 - 12:23 PM

About BootIce info in this scenario let's put it out of the equation, as we both seem to be agree, that for whatever reason, it is giving wrong info on this case.
 
But nevertheless is good to know it is not trustable on cases like this.
 
alacran

No, it is not "wrong" info, the info is "right", only it is "different info".
 
 
The way you see it is because of mis-communication/mis-understandings, seemingly (from your last post) you didn't follow (to the letter) steve6375's instructions:
http://reboot.pro/to...phone/?p=213021
 
 

BootIce does not give a complete picture.
 
1. Make a 'bad' SD card
2. Run RMPrepUSB - DriveInfo - 0  and save notepad file as BAD0.txt
3. Run RMPrepUSB - DriveInfo - P1 and save notepad file as BADP1.txt
4. Boot it and run geometry --sync (hd0) and quit
5. Run RMPrepUSB - DriveInfo - 0  and save notepad file as SYNC0.txt
6. Run RMPrepUSB - DriveInfo - P1 and save notepad file as SYNCP1.txt
 
Now you can use WinMerge or similar tool to compare the files.
Please attach 4 files in next post.


If - like you seem to be reporting now, and for any reason - you didn't make step 1, and you used the same SD card where you ALREADY had run geometry --sync, is it so surprising that No differences can be found after re-executing the same command?
What sense has doing steps 2-6 if you didn't do #1?

Why (the heck) did you perform them and post the resulting file? (without specifying that you didn't - because you couldn't or for whatever other reason - perform step #1)?

 

Now that you cleared that you don't have a reference copy of the thingy when it didn't work but only copies made AFTER the geometry --sync (actually as tinybit correctly stated a geometry --tune followed by a geometry --sync) corrected some values and that as such there is no sense in comparing "before the cure" against "after the cure" because we have not a "before the cure" and we have been (pointlessly) comparing till now "after the cure" against "after the cure", the problem is solved.
 
:duff:
Wonko



#47 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 October 2019 - 02:28 PM

Make a 'bad' SD card it is not clear enougt, he could said format the SD card, use a different SD card or whatever is the meanning he was trying to transmit. I made a 'bad' SD card folder to keep the info.

 

But one way or the other as grub4dos on the SD card was working fine after the geometry --sync (hd0) command it is evident this fixed it.

 

alacran



#48 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 17 October 2019 - 03:21 PM

Yep, as said it was a case of mis-communication/mis-understanding, it can happen all the time :), even between native English speaking and very expert people, but - as I suggested to you before - if something is not clear, you should ask for clarifications, before going ahead doing something you didn't fully grasp.

 

Maybe it was Steve6375 not clear enough, maybe it was you not understanding what he meant, it doesn't matter, talking/asking would have removed the doubt and we would have saved a lot of posts/time, but all in all it was not wasted time if it helps for better future communication.   :thumbsup:

 

:duff:

Wonko



#49 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 17 October 2019 - 03:55 PM

It seems to be contagious my friend as you also don't clarify to me the expresion Make a 'bad' SD card

 

Now we are tree with same disease.

 

As you can see I'm following your advice to the letter.

 

alacran



#50 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 17 October 2019 - 04:30 PM

No problem :) I will gladly translate for you from Steve6375's jargon (as I personally understood it):

 

Make a 'bad' SD card=re-create (re-partition/re-format/re-whatever) the SD card so that it is in the SAME condition as it was before running the the geometry --tune geometry --sync commands (i.e. with grub4dos not finding the volume/menu.lst), or repeat the EXACT, SAME steps you originally did to obtain such a  status.

 

Spoiler

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users