1396 replies to this topic

[steve6375]

Try this.

 

 

set ME=%0

 

if "%2"=="" goto :endloop

set FILEPATH=
# look for a file with a .iso extension - param1=start folder   param2=extension
(bd)/grub/FindFileExt.g4b /_ISO/Linux/Default .iso
if not "%FILEPATH%"=="" echo FILE FOUND AT %FILEPATH%
if "%FILEPATH%"==""  echo No file with matching extension found!
if "%FILEPATH%"==""  goto nodefiso
echo timeout 5 >> (md)0x3000+0x50
echo default 0 >> (md)0x3000+0x50
echo -e -n \r\n >> (md)0x3000+0x50
set hlp=\nDefault Boot ISO is %FILENAME% (mapped to USB drive - partition 4)
echo title %FILENAME% %hlp% >> (md)0x3000+0x50
echo partnew (hd0,3) 0x00 %FILEPATH% >> (md)0x3000+0x50
echo map  %FILEPATH% (0xff) >> (md)0x3000+0x50
echo map --hook >> (md)0x3000+0x50
echo root (0xff) >> (md)0x3000+0x50
echo chainloader (0xff) >> (md)0x3000+0x50
echo -e -n \n >> (md)0x3000+0x50
:nodefiso

set DIR=%2

echo Using %DIR% as main folder for .iso  files

 

[steve6375]

P.S. If the directory does not exist, FindFileExt.g4b will stop at an error if errorcheck is on. You can either turn errorcheck off or patch the FindFileExt.g4b like this:


:cpa
if "%DD%"=="1" echo @CPA: Current Root: %DIR% - Changing source root to ()%DIR%/
if not exist ()%DIR%/ errorcheck off
root ()%DIR%/
ls | call :copyfiles
goto :EOF

[Scooby]

Okay, changed USB stick seems to function now

 

There is some strangeness going on. I fooled around with splashimages and changed LINUXAUTOMENU to Background.bmp.gz

It worked, But when I changed back to Bluelight.xpm.gz it was still the other one?

 

How can this be?

 

Since splash command is last in LinuxUser.mnu I want be sure there is no problem with our approach above?

That it interferes with splash command.

 

What do you think.

 

Will patch FindFIleExt tomorrow when I got a clear head

 

Thanks for your help

Edited by Scooby, 27 January 2013 - 08:28 PM.

[Scooby]

I solved it.

 

The call to FindFileExt somehow resets memory pointers

so when I write the default menu it overwrites the text from LINUXUSER.mnu

 

so I moved the call to FindFileExt before the output of LINUXUSER.mnu.

 

and now everything works.

 

I'm going to check out your suggestion about patching FindFileExt.

 

Maybe it's better to check if dir exist in AUTOLINUXMENU.bat

 

 

if exist /_ISO/Linux/Default (bd)/grub/FindFileExt.g4b /_ISO/Linux/Default .iso

 

 

and further down the check  FILEPATH == "" will take care of 
the outputting of default menu

Edited by Scooby, 28 January 2013 - 01:43 PM.

[Scooby]

Hi steve,T

 

Thanks for all help, I really really like easy2boot.

 

I went with your patching of FindFileExt.g4b.

 

To your earlier question, I am using puppy linux 99% of the time but now and again I will boot into the market leading OS

so I want the funtionality of easy2boot but want to go straight to AUTO booting feature.

 

So I set my sytem up with menu.1st which will boot up /grub/autolinuxmenu.bat .automenu /_ISO/Linux/AUTO

and menu2,1st who will boot up /grub/automenu.bat .automenu /_ISO

 

menu2.1st is called from back to main menu.

 

This is how I like it

 

Question,

 

I get a lot of debug prints about "file size", can this be turned off?

 

I will share this Default folder on puppy linux forum

 

Thanks again

[steve6375]

Try adding debug off

 

e.g.

 

echo -e -n \n >> (md)0x3000+0x50

debug off

:nodefiso

 

 

The correct way would be to add  > nul to the offending lines

[steve6375]

I have updated the FindFile.zip files so that debug does not need to be turned off and I also added the test for root.

Please try the new version.

[Scooby]

Tried the new version, it works great.

 

Its been a learning experience, can't say I'm feeling comfortable with DOS programming, the goto's and so on

 

 

Any new plans for further development of Easy2boot or rmprepusb?

[steve6375]

Nothing planned. The project was really intended to get beginners started in making a multiboot USB drive. If you are good enough to modify batch files and menu files then you don't really need Easy2Boot!

If you want a more sophisticated version, then it is best to make your own menu.lst using iftitle menu entries and modify it to suit your own needs.

Try reading the grub4dos tutorial on my site for more details or try tutorial 63 (which has a large menu.lst containing iftitle menu entries for you to try).

[Scooby]

Yeah its great for beginners!

 

Of course I will hack around with it, cant help myself

 

 

Steve I'm thinking of making a video tutorial for easy2boot maybe its get even more users with a successful result? What do you think?

[steve6375]

Good idea! Go for it  

[Scooby]

I have been trying to do the "prepare USB drive" part of rmrepusb on Linux.

 

I tried the tutorial 50 of your site and had moderate success with the first one

the second one broke my USB it seems. Asks for geometry and misbehaves.

 

Can you brake a USB stick with a lot of dd and so on?

Or is it just broken physically?

 

I saw someone compiled fbinst for linux, I tried it and failed,

 

Do you have any input on How to do it on Linux?

[steve6375]

Sorry, I am not 'Linuxy'. The instructions came from others.

If you do a Clean in RMPrepUSB and unplug, it should remove any bad data. I don't think linux can permanently kn@cker a USB drive unless you run a manufacturers tool or special s/w??.

[Wonko the Sane]

Sorry, I am not 'Linuxy'. The instructions came from others.

If you do a Clean in RMPrepUSB and unplug, it should remove any bad data. I don't think linux can permanently kn@cker a USB drive unless you run a manufacturers tool or special s/w??.

NO software (exception made for the manufacturer tool or any *special* software to the same scope) can damage *permanently* a USB stick (and most probably even a bad use of the manufacturer tool can be fixed, restoring the device to functional state - as a matter of fact I have used tens of times a manufacturer tool to revive a "botched" USB sticks).

 

Known example:

http://www.msfn.org/...up-a-usb-drive/

 

USB sticks can "lock" themselves (for *whatever* reason) and become unaccessible.

 

This can happen for physical reasons (and then you can do nothing about it if not check solder joints and the like, maybe replace the quartz, etc.) let's call these "hardware issues".

But it can happen also for other reasons, let's call these "software issues" (and in these cases the Manufacturer tool may be able to fix the issue).

 

The fact is that both (hardware and software) may happen "instantly" (and for *any* reason) and then the user is led to believe that last action is the cause.

 

Typical example 1:

 

 

I formatted the stick with (say) RMPREPUSB and it stopped responding (and in Explorer I can see it's size reported as 0), hence RMPREPUSB (still say) damaged my device.

 

Typical example 2:

 

I took my USB stick to my friend's place, and I inserted it in his Mac but could not access the data on it. When I went back home my windows could not recognize the device anymore, hence my friends Mac ruined my device.

 

Another example of the false assumption:

http://www.msfn.org/...usb-stick-dead/

 

REAL cause

http://www.imdb.com/...es?qt=qt0373705

 

 

Wonko

[steve6375]

If the said USB stick was a known good brand from a known good retailer then there would be grounds for suspicion (after visual inspection of the solder joints and PCB).  

If the USB stick is an unbranded no-name piece of trash from $Bay and it happened to go to meet it's maker whilst using RMPrepUSB, then all bets are off!  

[Scooby]

I want to be clear: It was not RmPrepUSB that killed my USB stick.

 

I itried to do what RMPrepUSB does in Linux, and failed.

And if wonko are right it wasnt my excessive dd-ing to stick that killed it.

 

BTW it was a Lexar. Are they crap?

 

I got fbinst compiled now on Linux.

 

Can it do some of the things RmPrepUSB?

Do you think it would function with Easy2Boot.

 

I'm gonna read up on fbinst myself but if you are willing to comment it would be great 

Edited by Scooby, 11 February 2013 - 11:32 AM.

[steve6375]

I have had a few sticks apparent;y 'killed' by RMPrepUSB, but these have been cheap unbranded ones which have failed the size test (i.e. fake size ones) which have finally died whilst in use.

 

Easy2Boot just needs a formatted drive + grub4dos - nothing special is required. The MBR will be the grub4dos MBR code (but RMPrepUSB uses a modified version of that which should boot on a wider variety of systems).

[Scooby]

*EDIT* I did have another missthinking so there was no problem with using the same 0x3000 file

           But it would still be interesting if you said some about (md) and how to calculate adressess? *EDIT*

 

 

 

I have a problem with Easy2Boot

 

I added submenu using the same configfile

 

(md)0x3000+0x50

 

When I go back and forth a few times entries from one submenu appears in another.

 

 

Can you erase memory file?

 

Or can you create a new one? How do you calculcate?

 

is  0x3000 startaddress and 0x50 the length?

 

I tested with

 

 

(md)0x5000+0x50
and
(md)0x7000+0x50

 

 

 

Which works but I dont know exactly what I'm doin? I dont want to limit users with little memory.

 

I know, I dont get this at all, help please?

Edited by Scooby, 14 February 2013 - 12:53 PM.

[steve6375]

How did you add a submenu?

If you used >  (md)0x3000+0x50 then it will make a new menu

If you used >> (md)0x3000+0x50 then it will add to the end of the current menu

 

(md) is memory drive starting at the beginning of system memory - it has 'sectors' of 512 bytes per sector. (md)0 is first sector, (md)0x3000 starts  512*0x3000 bytes in from start of memory.  0x3000+0x50 means start at 0x3000 'sector' in memory, size is 0x50 sectors (512*0x50 = 0x25K = 37K).

 

so 0x3000 is at 6MB in memory  (0x3000 = 12288 sectors x 512 bytes = 6291456 = 6MB.

 

You don't want to write to (md)1+50 for instance, as these are where the systems interrupt vectors live and it would crash the system!

e.g. try help > (md)1+100  in grub4dos shell under QEMU!

 

See a very good   tutorial here.

 

[steve6375]

YouTube video added to post #1.

[Rootman]

Well this is a SWEET find, I noticed this thread a while back but never looked at it.  I just downloaded it and am pretty excited about it.  I'm always downloading and messing around with new distros or other bootable ISO's so this is right up my alley.

 

A tip that may help others: to speed things along setting things up on my Windows machine I used Virtualbox with a 32GB virtual hard disk disk.  I used a Windows PE disk to prep it and install GRUB, copied Easy2Boot to it and but my ISOs on it and went to town. Seemed to work real well for me, generally FASTER than a USB drive and I can stay in Windows the entire time without rebooting.  QEMU never has worked well for me.  I then copied the whole thing to my USB stick and there it was all setup the way I wanted it.

 

One question:  Why use the title LINUX in the menus when Esy2Boot can automatically boot dang near anything just by placing teh ISO in the _ISO\Linux\AUTO folder?  I've thrown a few WIndows PE and DOS based ISO's in there and they all booted fine. Or better yet how about an AUTO folder for ALL the other OS types? MSDOS, UTILITY, WINDOWS, Etc.?

 

I look forward to further developments.

Edited by Rootman, 09 March 2013 - 02:35 AM.

[steve6375]

Hi

The AutoLinux grub4dos menu uses two techniques.

The first is just to map an ISO file to device (0xff) and then boot from the device. This works with bootable ISO files such as linux, WinPE and DOS, etc with a poor success rate. There is nothing new about this method and it has always been in grub4dos. However, if the OS boots and then expects to see some more files on the 'boot disk' it will fail to find them because the files are inside the ISO. So ISOs such as over 50% of linux ISOs, Hirens, BartPE, XPLive, ERD, many modified WinPE versions and Windows install ISOs, etc. will not work. Usually cheat codes and other tricks have to be employed or some files have to be extracted from the ISO and placed on the boot drive outside of the ISO. In other cases (e.g. MSDart) we need to swap around the hd0/hd1 devices. Also DOS ISOs will not work if they expect to find a CD device and load CD drivers to access the rest of the ISO.

The new technique used by the AutoLinux menu entries is to use the partnew command to also map partition 4 to the start of the ISO file, so it looks like there is a disk partition that contains all the files that are in the ISO. The partition 4 table entry has type 0 - this does not matter to linux as it looks at all partitions regardless of the type number. However, DOS and Windows will ignore the partition as it is type 0. When linux boots to protected mode and loses the ISO-to-ff device mapping, it needs to get more files (e.g. sqashfs) and so it mounts all filesystems (including the type 0 partition we mapped to the start of the ISO) and so can see and load the required 2nd stage boot files.

 

 

So although the AutoLinux folder may well work for some DOS, WinPE and other non-linux ISOs, the success rate will be much lower. The point is that nearly all linux ISOs will work using the partnew technique (first mentioned on reboot by cdob I believe  ) .

 

 

[Wonko the Sane]

 The point is that nearly all linux ISOs will work using the partnew technique (first mentioned on reboot by cdob I believe  ) .

Just for the record:

http://reboot.pro/to...os-isohybrided/

http://reboot.pro/to...brided/?p=88531

 

Wonko

[Rootman]

I guess that I should clarify my thoughts, why not move the AUTO directory UP on level since it can auto boot so many things BESIDES Linux, either that or create an AUTO folder under each of the other subheadings?  It just seems more logical for the menu's arrangement that way.  It has booted every ISO I've put under it with the exception of an old Windows XP based PE that needed to be mapped to memory with the --mem setting and a simple menu entry copied from an example using one of the other PE ones on the development page worked that out. I've used the AUTO folder for WIndows PE, old DOS, weird little propriatary stuff on ISO's and it works a charm.
 

It's amazing how it boot even Linux or utility ISOs that previously needed to be disassembled and a special GRUB menu created for them.  This way is SO much cleaner and simpler. Again, excellent work!

Edited by Rootman, 09 March 2013 - 11:50 PM.

[steve6375]

The \_ISO\Linux\Auto\AUTO_MENU.mnu file controls the listing of the files, etc.

You could move this up a level and edit it if you wish

the command /grub/autolinuxmenu.bat .automenu /_ISO/Linux/Auto   specifies the folder to enumerate so it is easily changed and you can change the titles by editing the files in \grub.

 

However, there are many non-linux ISOs that do not work - Hirens, DLC, all Windows install ISOs, ERD Commander 2005, Diag504fCD.iso WD diag (needs --mem), MSDart (needs hd0/hd1 swap), many linux iso with persistence (file needs to be specified using cheat codes) and many others that I can't remember...