Without a filesystem
#1
Posted 29 June 2011 - 09:43 AM
I'm trying to build a system in which the mbr, grub4dos and an iso-image is written onto the beginning of the disk. This is executed with WinPE, after which the computer is rebooted and the grub4dos should start up. Looking at the documentation it seems that I have to take out the searching of the grldr from the filesystem and instead replace it with a sector number from which the grub4dos is loaded. After it's loaded, a script should continue to mount an iso-image (map it) and start running it.
So, what do you think ? Easy, quick changes or a rewrite ?
Any and all help is appreciated
#2
Posted 29 June 2011 - 10:06 AM
1. Boot from (what?)
2. Run WinPE - which version XP WinPE, Vista WinPE or WIn 7 WinPE (1,2, or 3)
3. If running WinPE, why not use diskpart to create mbr & ptns? How many ptn do you want?
4. What ISO exactly? Can ISO exist as a file on a filesystem? What do you mean by 'ISO on beginning of disk? Do you mean using a technique similar to http://sites.google....torials/pclinux - if so then you could use dd.exe to 'blat' on the ISO contents? Grubinst and touchdrv should (??) run under WinPE.
#3
Posted 29 June 2011 - 10:13 AM
Have a look at WEE :
http://reboot.pro/11751/page__st__5
http://reboot.pro/14/page__st__26
it may be what you need.
Check this also:
http://reboot.pro/9916/
and this:
http://reboot.pro/12436/
as they may contain something useful.
Wonko
#4
Posted 29 June 2011 - 10:22 AM
Can you explain the sequence please
1. Boot from (what?)
2. Run WinPE - which version XP WinPE, Vista WinPE or WIn 7 WinPE (1,2, or 3)
3. If running WinPE, why not use diskpart to create mbr & ptns? How many ptn do you want?
4. What ISO exactly? Can ISO exist as a file on a filesystem? What do you mean by 'ISO on beginning of disk? Do you mean using a technique similar to http://sites.google....torials/pclinux - if so then you could use dd.exe to 'blat' on the ISO contents? Grubinst and touchdrv should (??) run under WinPE.
1. Boot the computer just like any other. The mbr has been rewritten to startup grub4dos.
2. WinPE version isn't significant, so the answer is all of them.
3. There are some complications expected with creating mbr and partitions with WinPE so for now, I'm avoiding it. The plan is to not have any partitions at all but to merely use grub4dos to startup the cd-image which resides on the iso-image written earlier on the hdd with WinPE.
4. The cd-image (ISO) will exist on the hdd and its position and length will be written somewhere, possibly straight into the grldr configuration. More precisely, directly to the mapping command (possibly).
Edited by denarced, 29 June 2011 - 10:24 AM.
#5
Posted 29 June 2011 - 11:37 AM
@denarced
Have a look at WEE :
http://reboot.pro/11751/page__st__5
http://reboot.pro/14/page__st__26
it may be what you need.
Check this also:
http://reboot.pro/9916/
and this:
http://reboot.pro/12436/
as they may contain something useful.
Wonko
Thanks for these suggestions.
I didn't see anything suitable for my purposes thou ..
#6
Posted 29 June 2011 - 11:42 AM
The purpose is to set up the hdd in a way that it can be booted up and it will load the cd-image just like booting up a live linux distribution. I'm already using WinPE so I'll use it merely for writing the binaries on the hdd and for that reason, its version is insignificant. Grub4dos is almost perfect, but it tries to find grldr from existing filesystems and I wish to bypass that behavior. The same goes for the configuration, meaning the commands to map the cd-image. I wanna write them directly to the grldr-binary. I understand that's possible.
I hope this clears my intention.
Cheers.
#7
Posted 29 June 2011 - 11:52 AM
Maybe you didn't find them , but basically WEE is a "self-contained" grldr.mbr+grldr, intended to be stored in one chunk on the hard disk (can be put entirely in the hidden sectors).Thanks for these suggestions.
I didn't see anything suitable for my purposes thou ..
Right now you have normally:
- grldr.mbr in the first 18 sectors of the disk.
- grldr on *any* partition on the disk <-disk needs to be partitioned
With WEE you have:
- the whole wee in the first 63 sectors of the disk <-disk needs NOT to be partitioned
Wonko
#8
Posted 30 June 2011 - 03:57 AM
Maybe you didn't find them , but basically WEE is a "self-contained" grldr.mbr+grldr, intended to be stored in one chunk on the hard disk (can be put entirely in the hidden sectors).
Right now you have normally:
- grldr.mbr in the first 18 sectors of the disk.
- grldr on *any* partition on the disk <-disk needs to be partitioned
With WEE you have:
- the whole wee in the first 63 sectors of the disk <-disk needs NOT to be partitioned
Wonko
My mistake, that looks perfect for me. Thanks for clearing things up for me, I appreciate that.
cheers
#9
Posted 30 June 2011 - 05:37 AM
#10
Posted 30 June 2011 - 06:30 AM
Since it is a "mini-grub4dos" it needs to be checked/tested.
Also, as you can see, there is a "micro" version that fits in 63 sectors and a "mini" one that fits in 127.
If you partition the disk with the new offset Vista or 7 use by default, you have plenty of room for the second version too, but since anyway right after the WEE you probably want to store the .iso, you simply need to have first partition (if any) start at a suitable offset after both the WEE and the .iso.
What I would do:
- partition the disk leaving enough space at the beginning for your .iso image
- create one primary active partition with a grub4dos PBR
- add to it grldr, menu.lst and a copy of WEE itself
- copy to the MBR+hidden sectors the WEE making use of the "backup MBR on second sector
Then boot "normally" to the partition (using the backup MBR on second sector) and start experimenting with the "full" grldr (and a "normal" menu.lst).
Once you are satisfied with the result, try the same things with the WEE inside the partition (chainloaded through the "full" grldr and with the edited menu.lst "embedded" in it).
Once it (hopefully) works, replicate the settings from the WEE on the partition to the WEE on hidden sectors.
Even if WEE has not .iso mapping support, probably it has "plain floppy" one , so if the "direct" approach does not work, you may want to experiment with WEE loading *somehow* a floppy image through RAW sectors, with the floppy image containing a "full" grldr that, still *somehow*, maps the .iso from RAW sectors and then loads and boots from it.
Wonko
#11
Posted 30 June 2011 - 07:03 AM
Cannot say.
Since it is a "mini-grub4dos" it needs to be checked/tested.
Also, as you can see, there is a "micro" version that fits in 63 sectors and a "mini" one that fits in 127.
If you partition the disk with the new offset Vista or 7 use by default, you have plenty of room for the second version too, but since anyway right after the WEE you probably want to store the .iso, you simply need to have first partition (if any) start at a suitable offset after both the WEE and the .iso.
What I would do:
- partition the disk leaving enough space at the beginning for your .iso image
- create one primary active partition with a grub4dos PBR
- add to it grldr, menu.lst and a copy of WEE itself
- copy to the MBR+hidden sectors the WEE making use of the "backup MBR on second sector
Then boot "normally" to the partition (using the backup MBR on second sector) and start experimenting with the "full" grldr (and a "normal" menu.lst.
Once you are satisfied with the result, try the same things with the WEE inside the partition (chainloaded through the "full" grldr and with the edited menu.lst "embedded" in it).
Once it (hopefully) works, replicate the settings from the WEE on the partition to the WEE on hidden sectors.
Even if WEE has not .iso mapping support, probably it has "plain floppy" one , so if the "direct" approach does not work, you may want to experiment with WEE loading *somehow* a floppy image through RAW sectors, with the floppy image containing a "full" grldr that, still *somehow*, maps the .iso from RAW sectors and then loads and boots from it.
Wonko
Definitely worth considering. In line with my original plan, I'll have to check if I can do without the filesystem. Which means:
- Map cd-image from certain sectors.
- hook it
- boot it up.
Mapping the image from a known sectors is suppose to be possible in grub4dos, maybe it's in the micro wee as well.
#12
Posted 30 June 2011 - 07:19 AM
#13
Posted 30 June 2011 - 08:08 AM
-----------------
You may try this:
1. install the 63-sector version of wee on the first track of the disk.
2. from the second track, you may place a full copy of GRLDR.
3. after GRLDR, you may place your ISO image
4. after ISO image, you may place your first partition, and then second partion,...
When WEE get booted, let it run the GRLDR using command (hd0)XXXXXX+YYYYYY where XXXXXX is the start sector number of GRLDR and YYYYYY is the number of total sectors occupied by GRLDR.
You can embed your menu.lst in GRLDR. Then GRLDR would map your cd-image and boot it up. The map line can be something like this:
map (hd0)MMMMMMMM+NNNNNNNN (0xFF)
where (hd0)MMMMMMMM+NNNNNNNN is for your cd-image.
#14
Posted 30 June 2011 - 08:55 AM
Nice.You may try this:
Assuming that grldr 0.4.5 28-06-2011 is used, it's size is 253,676 bytes, i.e. 253,676/512=495,4609375 which we round to 496When WEE get booted, let it run the GRLDR using command (hd0)XXXXXX+YYYYYY where XXXXXX is the start sector number of GRLDR and YYYYYY is the number of total sectors occupied by GRLDR.
If it's on second track (of first disk), it will start at LBA sector 63, so the above should be:
(hd0)63+496Right?
And the complete menu.lst to be embedded in grldr is actually (with M and N's to be replaced by the actual values):
map (hd0)MMMMMMMM+NNNNNNNN (0xFF) map --hook root (0xFF) chainloaderRight?
To change the embedded menu in grldr, is still grubmenu.exe the "right " tool?
http://reboot.pro/12591/
Wonko
#15
Posted 30 June 2011 - 09:16 AM
wee has no iso9660 support. you cannot map cd-image and boot it up.
-----------------
You may try this:
1. install the 63-sector version of wee on the first track of the disk.
2. from the second track, you may place a full copy of GRLDR.
3. after GRLDR, you may place your ISO image
4. after ISO image, you may place your first partition, and then second partion,...
When WEE get booted, let it run the GRLDR using command (hd0)XXXXXX+YYYYYY where XXXXXX is the start sector number of GRLDR and YYYYYY is the number of total sectors occupied by GRLDR.
You can embed your menu.lst in GRLDR. Then GRLDR would map your cd-image and boot it up. The map line can be something like this:
map (hd0)MMMMMMMM+NNNNNNNN (0xFF)
where (hd0)MMMMMMMM+NNNNNNNN is for your cd-image.
Nice
This should do it.
Much thanks !
#16
Posted 30 June 2011 - 10:35 AM
Nice.
Assuming that grldr 0.4.5 28-06-2011 is used, it's size is 253,676 bytes, i.e. 253,676/512=495,4609375 which we round to 496
If it's on second track (of first disk), it will start at LBA sector 63, so the above should be:(hd0)63+496Right?
And the complete menu.lst to be embedded in grldr is actually (with M and N's to be replaced by the actual values):map (hd0)MMMMMMMM+NNNNNNNN (0xFF) map --hook root (0xFF) chainloaderRight?
All right. I mean both are OK.
To change the embedded menu in grldr, is still grubmenu.exe the "right " tool?
http://reboot.pro/12591/
Sorry I am not sure. One can use a hexedit tool to do it manually.
-------------------------
If the image were not for CDROM but for floppy or harddrive, then the 127-sector version of WEE would do it(GRLDR is not needed).
Assuming the image is for harddrive, here is the script for wee127.mbr:
map (hd0)MMMMMMMM+NNNNNNNN (hd0) map --hook rootnoverify (hd0) (hd0)+1
or equivalently:
map (hd0)MMMMMMMM+NNNNNNNN (hd0) map --hook root (hd0) +1
#17
Posted 30 June 2011 - 06:13 PM
Sorry if it already works, but would:
()XXXXXX+YYYYYYwork?
Or, if not, could be possible to add a "symbolic device" (or whatever) like:
(wee)so that something like:
(wee)XXXXXX+YYYYYYcould be possible?
Where the pseudo-device "(wee)" would mean "whatever is now booting wee", and thus wotrk the same on (hd0), (hd1) or (fd0), etc.?
Wonko
#18
Posted 01 July 2011 - 02:31 AM
one can set the root device by using one of "root", "rootnoverify" or "find --set-root" commands.
so "()XXXXXX+YYYYYY" will be OK after the root device is properly set.
-----------
About the booting device of wee, if I remember correctly...
If there is no booting script, the root device will be (hd0) or (fd0).
As it should be, the booting script would change the root device.
#19
Posted 08 August 2014 - 06:37 PM
#20
Posted 08 August 2014 - 08:42 PM
Stealth.
#21
Posted 09 August 2014 - 09:28 AM
Why not use a BIOS Boot Partition to store your raw code exactly the way you want? Better than random sectors in gaps on disk ..... which is EXACTLY what bootsector viruses end up doing.
You can easily jump to it using (grub)
chainloader +1
or equivalent syntax.
#22
Posted 12 August 2014 - 12:50 PM
Isn't the problem that whatever you boot to, it will want to see a filesystem to get it's 2nd stage boot files (e.g. squashfs)? Some small linux's don't have this 2nd stage but most do.
Which is why I asked what exactly you are trying to boot to.
You can use the partnew trick to boot almost any linux live CD.
This creates a partition in the partition table but it is of type 0 so will only be seen by linux OS's.
assuming your ISO is at (hd1)0xaaaaa and is 0xbbbbb sectors and is contiguous...
This way 2nd stage squashfs should work.
partnew (hd1,3) 0x0 (hd1)0xaaaaaa+0xbbbbb map (hd1)0xaaaaaa+0xbbbbb (0xff) map --hook root (0xff) chainloader +1 boot
#23
Posted 12 August 2014 - 01:39 PM
Which is why I asked what exactly you are trying to boot to.
- TO WHOM you asked it?
- WHEN did you ask it?
Quick recap (in case of need):
OP (denarced) asked in 2011 a question.
A suggestion that hopefully could help him in his goal was given (according to the resources/knowledge available at the time, in 2011).
OP never came back.
3 (three) years later milindsmart resurrected the topic and asked a (possibly rhetorical) question, then, without waiting for a reply by the OP (reply that BTW is very unlikely to ever come form him) he provided the one solution of which he is fond (reserved ONLY to GPT disks) that the good GRUB2 guys put together (which is used ONLY by GRUB2), citing vaguely "bootsector viruses (which are entirely another thing) and "RAW code" and that won't in any way solve the OP problem.
Wonko
#24
Posted 12 August 2014 - 02:22 PM
I didn't look at the date! Maybe threads should be locked after a long period if inactivity?
#25
Posted 12 August 2014 - 05:30 PM
Naah, it is a good thing that threads remain "open" as often something "new" (AND "pertaining") is found/discovered and/or other members may ask meaningful and related questions or need help/support to develop the suggested method or however something related to the topic (and not any other one) and/or need help/support to replicate this (and not anything else).I didn't look at the date! Maybe threads should be locked after a long period if inactivity?
But we could adopt a form of mild punishment for those that either post meaningless or unrelated things or don't check the dates of previous posts, or don't quote the post to which they reply to or address the poster to whom they are replying ....
I don't know ...
http://www.imdb.com/...?item=qt0471984
Wonko
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users