中国DOS联盟

Sorry, the first line was sent less, now make up.
33C08ED0BC007CFB5007501FFCBE1B7C

Ask the master: How can I embed menu commands under the DOS command line (or in AUTOEXEC.BAT)? Can you specify it specifically?
As for config.sys, since you gave the sample, I know it.
The menu I require is very simple:
1. Can start the IMG file on the USB flash drive;
2. Can start the ISO file on a partition on the hard disk (non-WIN or non-WIN PE ISO files).

I want the output result of cat --hex (fd0)+1 or cat --hex (fd1)+1 under GRUB. Can you ensure that the result you gave above is basically consistent with the output of cat? If yes, continue to look below; if not, don't continue, just post the result of cat.

From the result you posted, the USB flash drive is a hard disk format with a partition table, so there is a problem when GRUB handles such an unconventional floppy disk format. This may indeed be a problem with GRUB, because GRUB has never handled such a situation. You wait for one or two days, wait for me to study it, and then give you a reply. However, I think the possibility that GRUB simply crashes because of this is also not very high.

You'd better clone the entire USB flash drive completely with a certain hexadecimal tool and upload it somewhere for me to study.

You do the following test: simulate the entire USB flash drive as a hard disk and see if you can access the files in it. The steps are as follows:

map (fd0) (hd2)
map --hook

Then,

geometry (hd2)

See how many partitions are in hd2. Further see if there are files in the USB flash drive, you can operate it yourself, no need for me to explain in detail.

====================

It's very simple to embed a menu in the DOS command line, which is as exemplified just now:

grub.exe --config-file="Fill in the content of menu.lst here"

The double quotes should be included, and fill in the content of menu.lst in the middle. menu.lst has many lines, and originally there are carriage returns and line feeds between lines. Now in the DOS command line, carriage returns and line feeds cannot be embedded, so change all carriage returns and line feeds to semicolons (;).

You can understand it by looking at the example file config.sys. In the case of device=, up to 4000 bytes of commands can be embedded within double quotes. And in the DOS command line, the total length of the command line cannot exceed 127 characters, so the embedded menu should be very small.

Last edited by 不点 on 2006-7-23 at 18:45 ]

I'm very sorry. I used WINHEX to take the first sector of the USB flash drive. After your guidance, running cat --hex (fd0)+1 shows that it's actually the DOS boot sector. I compared it in WINHEX with the absolute 63rd sector (total sectors 128000 sectors), and they are exactly the same:
EB3C904D5357494E342E310002020600
0200020000F8F9003F00FF003F000000
C1F30100800029772550AC4E4F204E41
4D45202020204641543136202020FA33
C98ED1BCFC7B1607BD7800C576001E56
1655BF2205897E00894E02B10BFCF3A4
061FBD007CC645FE0F8B46188845F938
4E247D228BC199E87701721A83EB3A66
A11C7C663B078A57FC750680CA028856
0280C31073ED33C98A461098F7661603
461C13561E03460E13D18B7611608946
FC8956FEB82000F7E68B5E0B03C348F7
F30146FC114EFE61BF0007E823017239
382D741760B10BBED87DF3A66174394E
740983C7203BFB72E7EBDDBE7F7DAC98
03F0AC84C074173CFF7409B40EBB0700
CD10EBEEBE827DEBE5BE807DEBE098CD
165E1F668F04CD19BE817D8B7D1A8D45
FE8A4E0DF7E10346FC1356FEB104E8C1
0072D6EA00027000B442EB2D60666A00
525006536A016A108BF474EC919233D2
F7761891F776184287CAF7761A8AF28A
E8C0CC020ACCB801028A5624CD138D64
1061720A40750142035E0B497577C303
1801270D0A496E76616C696420737973
74656D206469736BFF0D0A4469736B20
492F4F206572726F72FF0D0A5265706C
61636520746865206469736B2C20616E
64207468656E20707265737320616E79
206B65790D0A0000494F202020202020
5359534D53444F532020205359537F01
0041BB0007807E020EE940FF000055AA

By the way, I'm using a Teclast 64M USB flash drive. I used HPUSBFW.zip to make it USB_ZIP. Please take a look again. If necessary, I'll make a ghost for you. But the file is very large and needs to be sent to you by email in multiple parts. I'll try other things slowly. You should also take a rest. Don't rush, take care of your health. Take care!

I used geometry (hd2) to check and there are 4 partitions, but no files from the USB drive are displayed. The display is as follows:
drive 0x82:c/h/s=80/2/18,The number of sectors=2880,CHS Bytes per Sector=512
partition num:0,Filesystem type unknown,partition type 0x74
partition num:1,Filesystem type unknown,partition type 0x65
partition num:2,Filesystem type unknown,partition type 0x53
partition num:3,Filesystem type unknown,partition type 0xbb
The last four lines are the same as what was displayed after I used cat (fd0, earlier in the afternoon. In addition, there is one more line:
partition num:0,Filesystem type unknown,using whole disk

I found that the displayed C/H/S number is different from the 7/255/63 shown by WINHEX.

In addition, I used the following command under DOS on the USB drive:
grub.exe --config-file="map --mem (hd0,5)/diskedit.img;map --hook;chainloader (fd0)+1;rootneverity (fd0);"
Then I pressed Enter, the USB drive light flashed for a while, and the screen showed
grub -
But there was no crash, but the img file was not started. Is my writing format correct? Why didn't it execute?

There is another typo! It should be rootnoverity!

grub.exe --config-file="map --mem (hd0,5)/diskedit.img (fd0);map --hook;chainloader (fd0)+1;rootnoverity (fd0);"

Originally posted by fastslz at 2006-7-23 22:35:
grub.exe --config-file="map --mem (hd0,5)/diskedit.img (fd0);map --hook;chainloader (fd0)+1;rootnoverity (fd0);"

It was a mistake when I posted.
For reliability, I tried again to make sure the writing was correct, and the result was still:
grub> -

However, having said that, I don't know if there is any prompt after an error with this method. If there is no prompt in case of an error under normal circumstances, then it is not very easy to use.

I also tried 4 loading methods and now report the results as follows:

Method 1
grub.exe --config-file="find --set-root /boot/zzcl/slzbootj.img;map --mem /boot/zzcl/slzbootj.img (fd0);map --hook;chainloader (fd0)+1;rootnoverity (fd0);"
:: Can boot

Method 2
grub.exe --config-file="map --mem /boot/zzcl/slzbootj.img (fd0);map --hook;chainloader (fd0)+1;rootnoverity (fd0);"
:: Can boot

Method 3
grub.exe --config-file="map --mem (hd0,7)/boot/zzcl/slzbootj.img (fd0);map --hook;chainloader (fd0)+1;rootnoverity (fd0);"
:: Cannot boot (cursor stays at grub>- prompt)

In the above 3 methods, the img position is all (hd0,7)/boot/zzcl/slzbootj.img

Method 4
grub.exe --config-file="map --mem (hd0,5)/grub/288.img (fd0);map --hook;chainloader (fd0)+1;rootnoverity (fd0);"
:: Can boot

Grub version is grub_for_dos-2006-07-23 package, and both (hd0,5) and (hd0,7) disk types are FAT32

Description: It's really a bit strange. According to reason, method 3 is the standard loading method but cannot boot, and method 2 was also said before to be a non-standard loading method (virtual path) I explored in practice and can boot instead. What's stranger is that method 3 and method 2 are actually the same loading method but can boot.
Continue testing tomorrow......

I did an experiment again today. First, I made a batch file with grub.exe --config-file="map --mem (hd0,5)/diskedit.img (fd0);map --hook;chainloader (fd0)+1;rootnoverity (fd0);" so that it's easier to find errors if there are any. Using this batch file on the USB drive, it was successful! Then I typed the same command again in the DOS command line of the USB drive, and it was successful this time—so was my test last night still wrong? But I checked it many times repeatedly! It's really strange!

Then, I used the following command to read the IMG file in the USB drive: grub.exe --config-file="map --mem (fd0)/diskedit.img (fd0);map (fd0) (fd1);map --floppies=2;map --hook;chainloader (fd0)+1;rootnoverity (fd0);" Whether making it into a batch file or directly typing and executing it in DOS, it freezes at map --mem (fd0)/diskedit.img (fd0)! Later, I removed map (fd0) (fd1);map --floppies=2 and it was still unsuccessful.

I estimate this might be because "after entering the GRUB environment, there should be no actions accessing the USB drive (menu commands should also not have actions accessing the USB drive), otherwise it will still inevitably freeze."

It's still a typo. What you wrote in the top post was correct, but now it's wrong: rootnoveri(t)y should be rootnoveri(f)y.

Now it's clearer: Accessing files on the USB flash drive causes a system crash. At this time, we can't say that accessing any file on the USB flash drive will definitely cause a system crash, but we can be certain that accessing some files will cause a system crash. You can record which files cause a system crash, then use the quit command to return to DOS, and in DOS use a certain tool (such as EDIT) to open the same file, and remember to read to the end of the file to see if the same system crash occurs. If a system crash also occurs under DOS, then it can be confirmed that it's a BIOS bug, and there's no doubt about it. If these files are opened smoothly under DOS and the results are all correct, then it means there's some unknown problem between GRUB and the BIOS of the USB flash drive, and we still have hope to continue tracking the real reason.

But now I seem to have discovered some problems. The description is as follows:

1. From the output result of geometry (fd0) being C/H/S=80/2/18 and the total number of sectors being 2880, it can be seen that the capacity of this (fd0) is the capacity of a standard 1.44M floppy disk. However, your diskedit.img file is actually in this floppy disk, and I guess this IMG file is also 1.44M in size. This is contradictory! It's impossible to fit a 1.44M IMG file (and many other files) in a 1.44M floppy disk.

2. From the first sector you cat out, it's found that H=255, S=63, the total number of sectors=127937, and C=127937/255/63=7.9637 (rounded up, equal to 8). So its geometry parameters are C/H/S=8/255/63, and the total capacity is close to 64M. Therefore, this disk can certainly hold the 1.44M IMG. But the problem is that the BIOS's INT13 disk interface accesses this disk with C/H/S=80/2/18, and can only access 2880 sectors at most, that is, the first 1.44M of content. If part of the file is in the position after 1.44M, it may cause a system crash (the system crash itself is a BIOS bug, because you can read incorrectly or return an error number, but it shouldn't cause a system crash).

From the above analysis, it can be assumed that if this partition on your USB flash drive is only 1.44M in size (precisely, 2880 sectors), then you will no longer encounter any problems. You can re-partition your USB flash drive to confirm this assumption. In a word, it all comes down to the defect of the BIOS. If the BIOS allows reading floppy disks larger than 1.44M, there won't be such problems. You can reflect this requirement to the motherboard manufacturer, asking them not to limit the boot capacity of the USB flash drive and not to let the USB flash drive crash, truly thinking about users.

Although your confirmation hasn't been received yet, the situation should be like this.

According to your requirements, the following experiment has been completed, and the report is as follows:
1. I specially used WinImage to make a standard 720KB diskgen.img image file, and it can start and run normally after trial;
2. Make a batch processing, the content is:
grub.exe --config-file="map --mem (fd0)/diskgen.img (fd0);map (fd0) (fd1);map --floppies=2;map --hook;chainloader (fd0)+1;rootnoverify (fd0);"
It is still the same as before. When the screen displays map --mem (fd0)/diskgen.img (fd0), it crashes;
3. Restart from the USB flash drive to DOS, first run GRUB, enter the GRUB command line, then use quit to return to DOS, run Edit.com, open the above image file, and can be completely opened (the percentage of the reading progress can be displayed), the file has a total of 4091 lines.

I don't want you to make an IMG smaller than 1.44M, but to reduce the partition size of the USB drive to 1.44M.

If the partition is large, a small file may also be allocated to a sector after 1.44M, which will cause a crash when opening.

EDIT cannot open a binary IMG file, only a part of it. You need to use a hex editor to open it, and this test will be valid.

Please confirm again whether the IO.SYS file on the USB drive can be opened under GRUB (which is read during DOS startup).

If it also fails and crashes, prepare a DEBUG program (this program is available in DOS), and I want you to do further tests under DOS (test int 13 /AH=8, DL=0 return result).

Also, now you can do the following tests:

cat --hex (fd0)2878+1
cat --hex (fd0)2879+1
cat --hex (fd0)2880+1
cat --hex (fd0)2881+1
cat --hex (fd0)5000+1
cat --hex (fd0)127935+1

See which ones will crash?

Last edited by 不点 on 2006-7-24 at 12:09 ]

Typo! I was also mistakenly included. After correction, the 3rd method on floor 25 can still be started.