Jump to content











Photo
- - - - -

WinPE Black Screen After Boot Logo


  • Please log in to reply
44 replies to this topic

#26 Uneitohr

Uneitohr

    Frequent Member

  • Advanced user
  • 219 posts

Posted 11 April 2016 - 05:30 PM

...and when I try the versions one-by-one (0.4.5a/b/c , 0.4.6a) do I have to edit the boot code as well? I mean will a simple grldr overwrite be enough?



#27 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 April 2016 - 06:06 PM

...and when I try the versions one-by-one (0.4.5a/b/c , 0.4.6a) do I have to edit the boot code as well? I mean will a simple grldr overwrite be enough?

Sure, that would be normally enough, if the grub4dos is "installed" to hard disk the grldr.mbr is usually capable of loading *any* (recent or recent enough) grub4dos, but you may also want to use an indirect grldr loading method (such as using NTLDR or BOOTMGR and a BOOT.INI).

 

Also there are two "levels" of possible causes.

One is something in the way the specific grub4dos versions which is not 0.4.6a vs. 0.4.5c "series" only, BUT also (example) grub4dos-0.4.6a-2016-04-11 vs.  grub4dos-0.4.6a-2016-01-19 and between a (roughly same version) of a DIFFERENT "series", (again example) 0.4.6a-2016-01-19 vs. grub4dos-0.4.5c-2016-01-18 interact with the BIOS.

 

 

 

The other one is the possibility that the commands in the menu.lst entry you are using are incompatible with the BIOS and need to be specifically adapted, as a matter of fact writing a menu.lst entry should be the LAST thing one does as when experimenting or debugging an issue one should use command line and command line only, as this allows for interactively get form the system the currently available devices, their mapping, etc.

 

Of course is not "easy" and takes a lot of time and tests to pinpoint such an elusive issue as the one you are having. :(

 

BEFORE blaming grub4dos and/or starting that kind of debugging,  it is not clear to me if the issue you are having happens ONLY when you add those packages:

http://reboot.pro/to...-logo/?p=198367

or does it happen when you add *any* package or does it happen also with an "untouched" .iso?

I mean could it be *something* in the exact way you modify/create the .iso that affects the (failing) booting?

(be it the actual method or the actual specific packages)?

 

:duff:

Wonko



#28 Uneitohr

Uneitohr

    Frequent Member

  • Advanced user
  • 219 posts

Posted 12 April 2016 - 06:39 AM

Which, in your opinion, is the best version for compatibility with most devices (computers, laptops)? Yesterday I tested all major versions (0.4.5a, 0.4.5b, 0.4.5c, 0.4.6a) from chenall builds and none of them worked. I'll have to start with year-builds.



#29 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 12 April 2016 - 07:58 AM

As said, BEFORE doing that "blind testing" I would rather try to find what the issue is, however a 0.4.5c-2015-05-18 is usually good in my experience.

(soon Steve6375 will post telling you how you should instead use the 0.4.6a modified for RMPREPUSB or Easy2boot use, giving you a number of reasons for that)

 

:duff:

Wonko



#30 Uneitohr

Uneitohr

    Frequent Member

  • Advanced user
  • 219 posts

Posted 13 April 2016 - 08:23 AM

  1. will it work when mapping to --mem? 
  2. or mapping to (0xff) drive instead of (hd32)? 
  3. is there a need (if possible at all) to do some re-mapping or forced mapping of the disk(s) with that particular DELL Bios?
  4. could it be a quirk of the "advanced/latest" GENERIC 0.4.6a series (that counts NUMBERLESS versions)?
  5. would one of the "more conservative" versions of the generic 0.4.5c series work?
  6. other?  :w00t:

 

 

1. no

2. no

3. I don't know but I could try provided you'll help me do this remapping

4. I have to test it one-by-one

5. tried all major versions, last update of them --no



#31 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 13 April 2016 - 09:19 AM

You are seemingly two steps behind :w00t:.

 

FIRST THING:

If windows "setup" boots on the given machine and "your PE" doesn't, it is more probable that it is "your" PE that has *something* wrong.

Can you confirm that on one of the problematic machines an UNTOUCHED Windows 7 install .iso image works fine and on that same machine, using the same grub4dos version and menu.lst entry "your" .iso fails?

 

:duff:

Wonko 



#32 Uneitohr

Uneitohr

    Frequent Member

  • Advanced user
  • 219 posts

Posted 19 April 2016 - 04:24 PM

I've finally fixed the error by using grub4dos-0.4.5b-2010-12-31. This is the only version that works, tried all of them.

The images affected were standalone WinPE images but also Windows Installer Disks (tried 7, 8.1, 10). All of them were freezing at the exact point: the boot logo. Using the above version all of them worked.

 

Now, I have a new question and hopefully you will be able to advise on the matter. I'd like to use two versions of Grub4DOS on demand. Like say one does not work, boot the other, manually of course. Can this be done by chainloading grldr from one another? If not possible, care to share a possible way to this?

I'd like to use grub4dos-0.4.5b-2010-12-31 and grub4dos-0.4.5c-2015-05-18.

 

Thank you



#33 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 19 April 2016 - 05:15 PM

Yep :), you can directly chainload another grldr with (say):
chainloader /my045b/grldr

you can also rename one of the two grldr's to something else (though there are some strings attached in theory with the renaming, in practice it works nicely).

 

But it is possible that around that time something changed in some "defaults" so that it is entirely possible that a later version works as well but needs some additional command.

 

I quickly checked the changelog and at first sight I cannot see anything around december 2010/january 2011 that can be related to your issue.

Are you positive that (say) this one:
http://grub4dos.chen....5b-2011-01-01/

doesn't work?

 

If you can pinpoint the exact very last version that works and the very first one that doesn't, maybe we can understand what the cause of the issue is.

Also (additionally, I know) would a slightly earlier version work?

 

:duff:

Wonko



#34 Uneitohr

Uneitohr

    Frequent Member

  • Advanced user
  • 219 posts

Posted 21 April 2016 - 07:54 PM

So I've done many tests on grub4dos and found that grub4dos-0.4.5b-2011-07-14.7z is the last working version on my machines.

Maybe you could do some investigating and reveal what has changed from this version and up. I'm really curious.



#35 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 22 April 2016 - 09:43 AM

It could be something connected with changes to the --e820 cycles:

2011-08-05 (tinybit)added a map option --e820cycles for Dell Laptop N4030.
2011-07-27 (tinybit)fixed a careless mistake in clean_entry().
2011-07-21 (tinybit)added a map option --int15nolow. Some changes on handler.

 

Try experimenting with a later version, adding a "map --e820cycles=0" before the "map --hook", see:
http://reboot.pro/to...45b-2011-07-14/

 

For some strange reasons the DELL Bios have been troublesome since the dawn of time, and it is very possible that the same issue affects various models, but are you using on them the Corsair USB 3.0 stick you mentioned?

(cannot find the related post, since the board had some issues in the last few days maybe it was lost)

 

There has been also this report:
http://reboot.pro/to...gt-didn-t-work/

 

It could also be a combination of BIOS with specific stick.

 

:duff:

Wonko



#36 Uneitohr

Uneitohr

    Frequent Member

  • Advanced user
  • 219 posts

Posted 22 April 2016 - 03:30 PM

I'll try the map --e820cycles=0 option on monday and say for sure. But what I know right now is that the latest grub4dos grub4dos-0.4.6a-2016-04-13.7z does not boot at all. It only shows a black screen, and does not load the grub4dos menu.

Show I will be forced to use multiple versions of grub4dos.

 

LE:

Also, I created an entry in menu.lst that chainloads grldr but it does not work. I'm booting grub4dos-0.4.5c-2015-05-18 and trying to chainload grub4dos-0.4.5b-2011-07-14 from it. I have renamed the grldr file as follows:

title Grub4DOS 0.4.5b 2011-07-14
find --set-root /boot_disk
chainloader /grldr_045b_2011_07_14

And the outputted error:

Will boot GRLDR from drive=0x80, partition=0x0(hidden sectors=0x800)
boot

Error 21: (http://grub4dos.chenall.net/e/21)
Selected disk does not exist

Please advise.

Thank you



#37 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 22 April 2016 - 05:18 PM

Strange.

Maybe is part of the same issue with a specific (flawed) BIOS. :unsure:

 

Try with a floppy image.

Get (yeah, I know) 0.4.2 from here:
https://sourceforge....grub4dos 0.4.2/

Open it in 7-zip (or whatever tool you use) and get out of it the file fat12grldr.img, mount it in (say) IMDISK and replace the grldr with the version you want to try.

Should be bootable with:
find --set-root /fat12grldr.img

map --mem /fat12grldr.img (fd0)

map --hook

chainloader (fd0)0+1

boot

 

:duff:

Wonko



#38 Uneitohr

Uneitohr

    Frequent Member

  • Advanced user
  • 219 posts

Posted 22 April 2016 - 06:38 PM

Perfect. Thank you so much.

Next update: monday, with the tests, oh boy :frusty:



#39 Uneitohr

Uneitohr

    Frequent Member

  • Advanced user
  • 219 posts

Posted 28 April 2016 - 08:26 AM

I'm back with my test results.

 

First the command map --e820cycles=0 works on my old machines using grub4dos 0.4.5c and 0.4.6a. But I'll still be using the floppy image created of the older grub4dos just for safety.

 

 

The other issue is that on my DELL 6320 laptop, the 0.4.6a series of grub4dos only works untill and including version grub4dos-0.4.6a-2016-02-26. Version grub4dos-0.4.6a-2016-03-03 displays the following error:

GRUB4DOS 0.4.6a 2016-03-03, root is (0x80,0)
Precessing the preset-menu...
GRUB4DOS 0.4.6a 2016-03-03, root is (0x80,0)
Precessing menu file /menu.lst...

And it freezes at that point. No matter what entries I write in the file, it still freezes. I left only the basic HALT and REBOOT entries in it and still froze. All other G4D versions after 2016-03-03 just display a black screen, not even an error code or message. Probably is related to the above error.



#40 ashfor

ashfor
  • Members
  • 4 posts

Posted 07 July 2016 - 10:40 AM

have same problem. black screen, when making WIM build model.
but all work fine, when making Normal build model.
 
all this with Standart boot manager - BOOTMGR
trick with "nx AlwaysOff" - did not help

 

video: https://youtu.be/8dE2N0IEK0M

 

how to log&debug WIM booting process?



#41 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 07 July 2016 - 11:59 AM

Try explaining to use what do you mean by "WIM build model" and what you mean by "Normal Build Model", ideally if you could describe (EXACTLY) the steps you perform while making th eone and the other build, which specific PE version is it, if you are using a "standard" copyPE cmd, which source media are you using, on which hardware you are trying it, how (very EXACTLY) you are trying to boot it, etc. you would be giving us the informations needed to try and help you.
The "effects" viewable in the video could be caused by several different things, including badly configured startup scripts (winpshl.ini, etc.).

:duff:
Wonko

#42 ashfor

ashfor
  • Members
  • 4 posts

Posted 08 July 2016 - 07:26 AM

sorry, i mean this settings "Build model"

 

jA1Obac.png

 

but on other computer (home), same the WinBuilder config, makes good ISO with "In RAM" model.
both computers with Win7 Pro x64 RUS and last updates from MS, UAC disabled.

I think better to give both .iso files for inspection.



#43 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 08 July 2016 - 08:07 AM

Yep, now I understand.

You need some support from someone more familiar with Winbuilder and with the specific project.

In any case you should provide the two logs (the one that works and the one that doesn't).

See on the right of the image you posted the "Create Support Log".

 

Loosely, what is happening is that the "in RAM" is wholly loaded in RAM, so once it is loaded it works, whilst the "other" needs a later access to the media and (for *whatever* reasons it doesn't work.

http://preview.tinyurl.com/jcd5zku

 

Very likely you will get better assistance on the (I cannot post the name) board in the title of your posted image, tinyurl to the rescue:

 

which is the (new) home of that Win7PE_SE project.

 

:duff:

Wonko



#44 ashfor

ashfor
  • Members
  • 4 posts

Posted 08 July 2016 - 10:33 AM

i see. anyway, if someone wish to investigate:
https://yadi.sk/d/E0D0jQ3et7cVD

same winbuilder config, same w7x32 as source, win7x64 as host


Edited by ashfor, 08 July 2016 - 11:04 AM.


#45 ashfor

ashfor
  • Members
  • 4 posts

Posted 08 July 2016 - 08:36 PM

SOLVED:
my disk D:\ have NTFS permissions with inheritance ONLY for my account:Change, for administrators:Full and system:Full
when i added read permission to Users group for source dir and winbuilder dir - problem gone.






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users