Making boot options automatic

[meo]

Hi again SamK!

I get your point now. This gives me another option to achieve what I want. I'm more than happy the way it works now but it is always good to have another option. Thanks for your input I appreciate it.

Have fun with TC,
meo

[vitex]

At the time of that post, TC would not boot using the direct mapping method of GRUB4DOS and required the memory mapping mode to be used.  Subsequent releases of the TC ISO (up to 3.8.4) are able to use the direct mapping method.  To do so (in the code box) replace   map --mem ...   with   map ....

Since grub4dos commands return an error code and grub4dos implements logical operators, you can use a single command line that will try direct mapping first and fall back to emulation in case of failure:

    map /tinycore.iso (hd32) || map --mem /tinycore.iso (hd32)


Do you know what change was made to TC to support direct mapping?  I know that an ISO must be stored in contiguous blocks on disk, but I am unaware of additional requirements for direct mapping to work.  I am also unaware of any method to force an ISO to be stored in contiguous blocks on an ext2-based file system.

[SamK]

Hi vitex,

...you can use a single command line that will try direct mapping first and fall back to emulation in case of failure:

Thanks for this suggestion.  I was aware of it but tend to reserve its use to testing the suitability of new ISOs.  In view of the OP having some difficulty in understanding the advice offered, it seemed prudent to indicate how the existing menu.lst might be amended using the most simple changes.

Do you know what change was made to TC to support direct mapping?

The short answer is, no.  In the last paragraph of reply #10 in:
http://forum.tinycorelinux.net/index.php/topic,10430.msg57531.html#msg57531
The problem was outlined to the Core team and shortly afterwards direct mapping became usable.  If the reason was announced I must have missed it.

I am also unaware of any method to force an ISO to be stored in contiguous blocks on an ext2-based file system.

Again referring to reply #10 of the previous topic, note [6] alludes to the original developer indicating that ext2 may not be a good choice when using GRUB4DOS to boot an ISO directly.  This was a primary driver behind my use of two partitions on the flash drive.

The first partition uses FAT, the second ext2. 

A FAT partition allows the ISO(s) to be made contiguous.  Additionally, when used in this way the matter of maintaining permissions does not arise as the TC file system is entirely in RAM (equivalent to booting from CD).  In such circumstances the ISO(s) can be made contiguous by moving everything in the FAT partition to an alternative drive then moving them back again.  This may not be the most elegant of solutions but is practical and reliable.

An ext2 partition is used to store TC data such as /home /opt /tce.  Again this avoids problems with permissions and enables TC to be used in the usual manner.  It is similar to a frugal install on a hard disk.

This combination of partitions overcomes many of the problems arising when a single partition used for both the ISO and data storage.

Once the above had been achieved, the framework for a bootable USB drive capable of directly booting multiple ISOs had been obtained.  In turn this led to the posting of reply #10 in the previous topic.
   

[vitex]

SamK,

Thanks for all of the information that you have provided.

Do you know what change was made to TC to support direct mapping?

The short answer is, no.  In the last paragraph of reply #10 in:
http://forum.tinycorelinux.net/index.php/topic,10430.msg57531.html#msg57531
The problem was outlined to the Core team and shortly afterwards direct mapping became usable.  If the reason was announced I must have missed it.

My curiosity was motivated by not understanding why an ISO would work with memory mapping but not with direct mapping.  (I understand why there are ISOs that work with neither type of mapping.)  To clarify the current situation in my mind, I performed the following experiment:

* Built a qemu virtual disk with the raw image format.  (Direct mapping seems to fail with other formats.)

* Partitioned the virtual disk with a single vfat-formatted partition. 

* Installed grub4dos from the TC repository on that partition.

* Copied ISOs for TC versions 3.0, 3.6, and 3.8.4 onto the partition as well as a version of 3.8.4 that was remastered with qremaster.

* Built a menu.lst file to boot each ISO using chainloading and using explicit kernel and initrd specifications.  All eight boot stanzas used direct, not memory, mapping.

* Booted each boot stanza using qemu from the TC repository.

* All eight combinations booted successfully with direct mapping.

It appears that the format of the ISO may not have been the cause of previous problems with direct mapping;  an older version of grub4dos may have been. 

[SamK]

To clarify the current situation in my mind, I performed the following experiment:

...

It appears that the format of the ISO may not have been the cause of previous problems with direct mapping;  an older version of grub4dos may have been.

I did not make any detailed notes of the experiments I conducted to arrive at the working framework so I am now relying on my fallible memory.  I have a good recollection of a few points:

• I used actual hardware rather than virtual
• Downloaded TC ISOs are normally checked via md5sum
• Care was taken to rule out a non-contiguous TC ISO
• A single GRUB4DOS version was used throughout and remains in use now
• The Multi-boot USB drive would boot a range of ISOs via direct mapping (and does so now) but at that time TC required memory mapping
• The TC ISO was directly substituted with a later release when it became available (all other conditions remained unchanged) and worked via direct mapping

It is difficult to see what might account for our differing results.  It may be of academic interest to try and establish the cause, however, as we both now have consistent, repeatable, and working set-ups I am content to accept the present position.