help editing grub.d/40_custom file

[P5music]

Hello,
I am going to put tinycore along with linux mint on sda1 hard disk.
I want tinycore not to interfere with mint so I ask if persistent home can overwrite some mint file.
I have to edit the above mentioned file and want to say tinycore boot two things:
1- where is tce (it's on sda1)
2- where is home (it's on sda1 too); is it safe to say home=sda1 or it is better to say home=sda1/tinycore, for example?

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "TinyCore (/dev/sda1)" --class linuxmint --class gnu-linux --class gnu --class os {
recordfail
insmod ext2
set root='(hd0,1)'
search --no-floppy --fs-uuid --set a9c54082-bd17-42b9-84d4-eadaba81475e
linux   /boot/bzImage root=UUID=a9c54082-bd17-42b9-84d4-eadaba81475e ro   quiet splash
initrd   /boot/tinycore.gz tce=sda1 home=sda1/tinycore
}
Is it right? I see the
set root='(hd0,1)'
command that worries me.
Can you help on this?
Thanks

[SamK]

If you are doubtful about the affects your experiments may have on your system it might be wise to consider some defensive measures and increased preparation.

Establish a fall-back position
Before making any changes, consider protecting your system by taking a disk image.  This will give an ability to roll-back to a known good position.

Isolate the operating systems
If you are apprehensive that TC may corrupt Mint, consider creating a new partition and place TC in it.

Research
If you are uncertain of the way to construct the GRUB2 menu entries a little more study may be beneficial.  The TC on-line documents and grub2.tcz.info files are good places to start. They offer pointers towards construction of menu entries and how GRUB2 counts disks and partitions.  The GRUB2 support mechanisms may also be worth a look.

I am unfamiliar with Mint and the goal you have set and therefore am unable to offer other than general advice.  Taken together, the suggestions may help you recover if things do go wrong, and may also increase the likelihood of achieving a successful outcome.

Good luck.
   

[roberts]

I typically run Tiny Core embedded. For a grub2 Ubuntu hard drive system the easiest method that I use is:

Boot up Ubuntu, become root user
Make directories /tce/boot
Download from distribution files http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/3.x/release/distribution_files/
bzImage and tinycore.gz into the /tce/boot/ directory.
Next edit /etc/grub.d/40_custom
At the bottom of this file add the following

menuentry "Tiny Core Linux" {
set root='(hd0,1)'
linux /tce/boot/bzImage quiet
initrd /tce/boot/tinycore.gz
}

Then run update-grub

Note: That grub2 counts devices from 0 but partitions from 1.
So in the example above points to hda1. This is where Ubuntu is installed.
Once succesfully booted the remaining directories that Tiny Core needs are automatic. Everything Tiny Core needs is one single directory!
This, of course, requires base supported file systems.

[grandma]

Not sure if this helps...but thanks to insight I got here (at TC)
I was able to actually create a grub4 bootloader product
with research done mostly using TC.

The first step to understanding the grub4dos system is
all about BOOT LOADERS...learning about the Windows
NTLDR and Linux LILO, Syslinux, Grub and Grub4DOS
evolution; grub4dos being the most reliable in my tests,
but every now and then I find a system wants syslinux.

Each has its own method of getting the bootloader
installed to the boot sector - the first 512 bytes of
every hard drive, USB drive etc. And in the case
of USB drives its actually the first 446 bytes.

For example syslinux has a utility you can run at
a MS DOS prompt that writes to this region and when
you boot the BIOS reads this and figures out what
to do next. Grub4dos has a bootlace.exe utility and
when you are running MSDOS you can use this to
create this 446 byte region and make a USB drive
bootable.

Thereafter your menu.lst file and grldr file work
together to give a user choices on which operating
system to boot. Syslinux also has a cfg file for customizing
these options, and configuring menu.lst for grub4dos
is what often throws folks for a loop.

What I use is something Lee taught me - the FIND
command; so my very simple menu.lst has this:

timeout=1
default=0

title TC Linux USB
find --set-root /tce/onload.sh
kernel /tce/ver3.52/bzImage quiet norestore waitusb=10 xvesa=1024x768x32
initrd /tce/ver3.52/tinycore.gz

(Yes, I run a very old TC that I love very much)

My folder structure is:

ROOT contains grldr and menu.lst -
i.e. /mnt/sda1/grldr and /mnt/sda1/menu.lst

ROOT /tce / contains onboot.lst and some other files like onload.sh

ROOT / tce / ver3.52 /  where bzImage and tinycore.gz reside

Therefore the FIND command in menu.lst could simply be

find --set-root /tce/onboot.lst

and with that grub4dos would be able to find find everything else to boot.

I could also add

title Another Linux USB
find --set-root /puppy/boot/somefile
kernel /puppy/boot/bzImage quiet norestore waitusb=10 xvesa=1024x768x32
initrd /puppy/boot/puppylx.gz

or whatever flavor you want to run.

Another method I have used which is more common these days
for users who have newer versions of Windows is relying on the
Windows bootloader.  This is because Windows insists on controlling
the partition (drive letter) or it stops working and that includes the
boot sector. For newer Windows users this means messing with
the 446 bytes can make the C: windows stop functioning.

With XP it was easy; you added a line to BOOT.INI and
let Windows handle the job and you would get a menu
that let you boot Linux on the same drive

At the bottom of boot.ini I would add
C:\grldr="Grub Boot Menu"

With Vista, 7 and 8 this changed and now you have
to use the BCDEDIT command which I frequently do
for clients. BCDEDIT is started at a MSDOS Admin Prompt
and its a multi-step process;

bcdedit /create /d "GRUBMENU" /application BOOTSECTOR
This will create a long GUID you need to write down or
pipe to a file with
bcdedit /create /d "GRUBMENU" /application BOOTSECTOR >saveanid.txt

If the example GUID was 12345 this number must be inserted into
the next set of commands:

set bcdid=12345
bcdedit /set {%bcdid%} device partition=C:
bcdedit /set {%bcdid%} path \\grldr.mbr
bcdedit /displayorder {%bcdid%} /addlast
bcdedit /default {%bcdid%}

The last line would make the grub menu the default
and some of my clients like that - it goes right into TC.
Others prefer I leave that line out so Windows remains
the default OS.

To get familiar with the GRUB4DOS MENU.LST files
I started with just ONE OS and would add a new
one after that one worked...eventually the find command
in menu.lst made it much easier since it pointed grldr
right to the files required to boot any OS.

I do suggest everyone become familiar with syslinus
as well - it was the bread and butter for a long time and
usually works - but grub4dos has proven more reliable
for most folks.

One small problem - sometimes you run bootlace which
stitches in those 446 bytes and it throws all kinds of errors
or doesn't run at all. There is a specific step-by-step that
seems to work for me and usually it starts with an fdisk and
wiping out the partition, install a new partition as type B and active
and then write the new partition and use mkdosfs to format it
then run bootlace.

If I deviate at any step it doesn't work as reliably or not at all.

I realize this is an ANCIENT 2010 post - but knowing XP and Vista
are vastly different in terms of adding to the Windows Boot Menu,
as well as knowing you can use either syslinux or grub4usb
to get it done...and playing with both as well as the find command

...altogether helped me figure out how to nail it every time.