Tiny Core Linux
Tiny Core Base => TCB Q&A Forum => Topic started by: meo on September 14, 2011, 03:38:08 PM
-
Hi all!
Have tried to find out in the wiki etc. but no luck. Would like to make following boot codes to be issued automatic: noicons tce=sdb1 xvesa=1024x600x32 . Any hints will be appreciated. Thanks beforehand!!!
Have fun with TC,
meo
-
You need to edit the config file for the boot-loader you are using.
-
Hi!
Have done that with the ones that I have bootloaders on. This is regarding a usb stick that is made bootable with bootlace. Would a change to the menu.lst do the trick?
Have fun with TC,
meo
-
Never heard of bootlace.
-
Have done that with the ones that I have bootloaders on. This is regarding a usb stick that is made bootable with bootlace. Would a change to the menu.lst do the trick?
Add whatever bootcodes you need to the "kernel" line of your grub4dos menu.lst.
-
Hi again vitex!
Thanks a lot, will try tomorrow.
Have fun helping us selflearned enthusiasts,
meo
-
Hi!
This is my menu.lst:
find --set-root /tinycore.iso
map --mem /tinycore.iso (hd32)
map --hook
root (hd32)
chainloader (hd32)
Where should I put the boot options? Thankful for any hints.
Have fun fooling around with TC,
meo
-
You are chainloading a different bootloader.
You need to configure the one you are chainloading.
-
This is my menu.lst:
find --set-root /tinycore.iso
map --mem /tinycore.iso (hd32)
map --hook
root (hd32)
chainloader (hd32)
Where should I put the boot options? Thankful for any hints.
I thought that you had unpacked the Tiny Core ISO and were booting with an explicit kernel command line. Instead you are booting the TC ISO directly using grub4dos ISO emulation, and the kernel parameters are still in the isolinux configuration file on the ISO.
The simplest way that I know to change those parameters is to use qremaster
http://forum.tinycorelinux.net/index.php/topic,8522.msg45715.html#msg45715 (http://forum.tinycorelinux.net/index.php/topic,8522.msg45715.html#msg45715)
Boot a Tiny Core system, download qremaster and the ISO to which you want to add the bootcodes, and then execute:
./qremaster tinycore.iso test.iso noicons= tce=sdb1 xvesa=1024x600x32
to build the new ISO test.iso from tinycore.iso with your bootcodes added. (Of course qremaster can also be used to add extensions and files to the ISO as well.)
-
Hi for the last time this night vitex!
Thanks a lot for your help!!! Now I don't have to use any boot codes. The reason for this setup is that it is so easy to upgrade. I just have to replace the old iso-file with the most recent. So this setup I use with alfa and rc releases to try them out. Thanks again! Now i know what to do when the next update in the 4.0 series comes.
Have fun helping out in the TC community,
meo
-
Is replacing 2 files that much harder than replacing 1 file?
-
Is replacing 2 files that much harder than replacing 1 file?
In particular if one considers that in the case of the TC 3.x series where the kernel (i.e. 'bzImage') IIRC never changed.
So someone else might need to check my "complex" calculation: It meant that for the case where I just wanted to upgrade from one TC 3.x release to another one I ended up replacing a single ca. 8 MBytes file (i.e. 'tinycore.gz') with a different one (instead of replacing a ca. 11 MBytes ISO file with a different one).
OOPS, was that even a smaller download requirement for the former approach ??
-
Would like to make following boot codes to be issued automatic: noicons tce=sdb1 xvesa=1024x600x32 . Any hints will be appreciated.
This is my menu.lst:
find --set-root /tinycore.iso
map --mem /tinycore.iso (hd32)
map --hook
root (hd32)
chainloader (hd32)
If I understand your question correctly reply #10 of this topic may help:
http://forum.tinycorelinux.net/index.php/topic,10430.msg57531.html#msg57531 (http://forum.tinycorelinux.net/index.php/topic,10430.msg57531.html#msg57531)
The basic idea was to provide a generic method that illustrates how to create a bootable usb flash drive having multiple partitions. It boots various distros directly from their ISOs stored in the root directory, and also has a separate data partition. One by-product of this was a means of automatically passing boot codes to TC rather than manually entering them at each boot-up. Have a look at the code box.
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 ....
-
Hi SamK!
You might be right but I only use an old usb stick (Sandisk titanium 512 MB) for the single purpose of trying out alfa and rc releases. I'm using the same media for extensions so there isn't much space left when I have downloaded (or installed with a script) the ones I want to use. Thanks for your suggestion! Will look in to it a little further when I got some more time.
Have fun tweaking TC,
meo
-
...I only use an old usb stick (Sandisk titanium 512 MB) for the single purpose of trying out alfa and rc releases. I'm using the same media for extensions so there isn't much space left when I have downloaded (or installed with a script) the ones I want to use.
I'm not sure I understand your meaning and may be missing the point you are making.
The reference to the previous post was not to suggest you change your current USB set-up to a multi-boot device, rather it was to provide a working example of how to automatically supply the boot codes when using bootlace+GRUB4DOS to directly boot a TC ISO. Is this not your objective? The principle will work just as well on a single partition bootable USB drive.
All that is required are small amendments to your menu.lst which will not occupy much space.
Current menu.lst
This is my menu.lst:
find --set-root /tinycore.iso
map --mem /tinycore.iso (hd32)
map --hook
root (hd32)
chainloader (hd32)
Where should I put the boot options?
Change it to something like this:
find --set-root /tinycore.iso
map --mem /tinycore.iso (hd32)
map --hook
root (hd32)
kernel /boot/bzImage quiet waitusb=5 noicons tce=sdb1 xvesa=1024x600x32
initrd /boot/tinycore.gz
OR - if it a recent stable version of TC
find --set-root /tinycore.iso
map /tinycore.iso (hd32)
map --hook
root (hd32)
kernel /boot/bzImage quiet waitusb=5 noicons tce=sdb1 xvesa=1024x600x32
initrd /boot/tinycore.gz
-
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
-
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.
-
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 (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.
-
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 (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.
-
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.