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

#51 alacran

alacran

    Gold Member

  • .script developer
  • 1122 posts
  •  
    Mexico

Posted 3 weeks ago

I apologize for my misunderstanding, of course I didn't make it intentionally.

 

Anyway, after fighting with the additional protective plastic cover of the phone, I was finally able to remove it and extracted the Micro-SD and by means of a USB card reader connected it to the PC and made a copy of all the content and formated it as Fat-32 single partition using RMPrepUSB and installed grub4dos on MBR, also cheked it for bad zones and all was fine, verified C/H/S with BootIce and it was XXXX/255/63 as it is usual, copied only grld and menu.lst to its root and rebooted, no problem to find menu.lst as spected, also cheked it for bad zones and all was fine.

Copied all previous content back to the Micro-SD and put it bach on the phone and rebooted from it, no problem to find menu.lst, cheked C/H/S using geometry command on grub4dos and it was XXXX/255/63, so all was normal,
 


@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.....

Then this very well explains the non standard XXXX/4/16 (C/H/S) values found before.

 

Mistery solved, and as I said before:

 

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

 

alacran



#52 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 3 weeks ago

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.


verified C/H/S with BootIce

OK, I now see that this is a lost battle. :(
 
No problem, however,  I have so many other battles to fight :).
 
:duff:
Wonko

#53 alacran

alacran

    Gold Member

  • .script developer
  • 1122 posts
  •  
    Mexico

Posted 3 weeks ago

As the SD was located, repartitioned and formated outside of the phone by a Windows program (RMPrepUSB), and without any influence of software and hardware from the phone, then I wanted to know BootIce info to compare with the value get from grub4dos geometry command latter (when booting from the phone), and now both match:

 

---verified C/H/S with BootIce and it was XXXX/255/63....

... put it bach on the phone and rebooted from it, no problem to find menu.lst, cheked C/H/S using geometry command on grub4dos and it was XXXX/255/63,...

 

 

And plese omit comments like this:

 

 

OK, I now see that this is a lost battle. :(
 
No problem, however,  I have so many other battles to fight :).
 
:duff:
Wonko

 

This do not contribute to the subject.

 

alacran



#54 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 3 weeks ago

Very good :).

But have you tried "verifying" the CHS geometry with BootICE (and with grub4dos) after having completely blanked (written 00's) to - say - the first 2000 sectors of the SD card?

This way neither Bootice nor grub4dos can use any data from the MBR partition table or from any PBR, or - if you prefer - since those data are 00's the result cannot be influenced by reading any of the info related to geometry actually written to the device, so the result will be either "a suffusion of yellow" or the actual geometry of the device as seen by the one or the other.

:duff:
Wonko

#55 alacran

alacran

    Gold Member

  • .script developer
  • 1122 posts
  •  
    Mexico

Posted 3 weeks ago

No need as before formatting it with RMPrepUSB I ran diskpart clean all on disk No. 1, and this command writes zeros to every single sector.

 

I'm sorry I omited that.

 

alacran



#56 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 3 weeks ago

No need as before formatting it with RMPrepUSB I ran diskpart clean all on disk No. 1, and this command writes zeros to every single sector.
 
I'm sorry I omited that.
 
alacran

Well there is still some mis-communication going on.

I was suggesting that a meaningful test would have been "verifying" geometry both with BootICE and grub4dos at a time when the SD was zeroed.

In your report you seemingly did that after having the thingy re-partitioned/re-formatted, so the fact that it was previously zeroed is irrelevant.

IF some values *somewhere* do actually influence the results of the verification through grub4dos or through BootICE, having all accessible data on the SD zeroed might (or might not) change the results (in one or the other tool).


:duff:
Wonko




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users