[IMPORTANT] Boot loader for next release.

[fanthom]

There was a suggestion for going with one loader like grub instead of syslinux, lilo, isolinux, extlinux. After reading of this topic:
http://www.porteus.org/forum/viewtopic. ... p=477#p477
I'm getting convinced to 'grub' (grub4dos?) option as a unified solution. It would require rewriting of bootinst.bat and bootinst.sh scripts.
The deadline is March i guess, as first BETA of Porteus-v1.0 should be released then.

What do you think?
Any volunteer who could start working on this?

[brokenman]

What we have now works great (i have updated syslinux and use extlinux to boot from ext partition).
'Why was it chosen in the first place?' would be the question to explore. Grub was available then.

I vote for grub. It is more widely used and people are familiar with it.

[francois]

Grub for sure will be a bootloader a lot more convenient and compatible. Great!

[Falcony]

Yesterday I found time, look through documentation and trying several installation via grub4dos on 32-bit and 64-bit Porteus

I prepair small comparision which could be useful for making descision.

First is grub loader - (last version grub itself which have much modern possibilities ) - isn't possible to implement as we have install scripts not only for Linux but for Windows.

So compairing grub4dos and bunch of tool syslinux(syslinux, isolinux, pxelinux and extlinux)

1. Supported file systems

grub4dos - allow to bood from FAT12/FAT16/FAT32, NTFS, EXT2/EXT3 and EXT4(partly cannot install MBR to EXT4 partiton), ISO 9660

syslinux tools - allow to boot from - FAT12/FAT16/FAT32(syslinux), ISO 9660(isolinux), EXT2/EXT3/EXT4/btrfs(extlinux), pxelinux(PXE boot by network)

2. Design of usage - are different phylosophy

grub4dos - one tool for everything

syslinux tools - each tool for separate task

3. Working with Windows

grub4dos - fine. Could boot from NTFS even

syslinux tools - poor. Booting with Windows possible only if 1-st partiton is FAT, EXT or by using grub4dos or other bootloader

4. Support, code stability and future development

grub4dos - medium. The project itself based on outdated code base. Last small fixes from Aug of 2010, project deleloped but add new possibilities rare, only small fixes. Installation tools like grubinst do not updated from begin of 2008. I found one bug on 64-bit linux - grubinst binary cannot find start sector ad USB stick(FAT32). So for installatrion of bootsector I have to use bootlace.com. On 32-bit grubinst binary works well. Though grub4dos has ext4 support, its MBR code CANNOT load grldr (The main boot loader file) from an ext4 partition.


syslinux tools - good. Last release extinux in middle 2010, added not only bug fix but also add new filesystem support btrfs
Last realise of syslibux in October 2010 - bugfix.

5. Boot scripts

grub4dos - more powerful but more hard(changing menu.lst template are needed)

syslinux tools - less powerful but less hard(changing slax.cfg do not needed but limitation by 1-st partiton filesystem)


5. Boot menu design and appearance

grub4dos - looks very bad - bootsplash support only 14 colours and *.xpm images only. Only simple menu are possible

syslinux tools - looks good - bootsplash support diffirent image type(png, jpg, bmp, etc) and number of 16 colors.
Allowed also complex menu with selection see screens with complex.c32 http://syslinux.zytor.com/wiki/index.php/Screenshots

To compare bootsplashs looks please get this tar file

http://falcony.googlecode.com/files/botsplash.tar.gz

slax.jpg - original bootloaded of syslinux menu, full colour
slax.bmp - 14 colour image, done with gimp - that's how grub4dos bootsplash at bootselecting ugly looks
slax.xpm.gz - converted slax.bmp to slax.xpm and gunzipped. You could use it with grub4dos menu

[fanthom]

one problem: Windows users wont be able to install Porteus on NTFS without Grub4dos
It could be used just for Windows, while normal Grub (Grub2?) could do the job for rest of fs on linux boxes.

my 2cents

BTW - great research!

[ponce]

falcony, grub4dos is active.

http://svn.gna.org/viewcvs/grub4dos/trunk/
http://www.murga-linux.com/puppy/viewtopic.php?t=51697

it supports ext4 and you can boot also .iso images saved on the usb/flash filesystem (I'm using like this on my pendrive to boot different live distros or slackware/debian/ubuntu mini iso installers).
once you create the template for booting slax (or whatever) you can add different options simply editing menu.lst, it's very handy, I'll post mine (on the first vfat partition of my usb drive) as an example

Code: Select all

default /default

title Boot from Hard Drive - Windows XP (NTLDR)
fallback 1
find --set-root --ignore-floppies --ignore-cd /ntldr
map () (hd0)
map (hd0) ()
map --rehook
find --set-root --ignore-floppies --ignore-cd /ntldr
chainloader /ntldr
savedefault --wait=2

title Boot from Hard Drive - Windows Vista/7 (BOOTMGR)
fallback 2
find --set-root --ignore-floppies --ignore-cd /bootmgr
map () (hd0)
map (hd0) ()
map --rehook
find --set-root --ignore-floppies --ignore-cd /bootmgr
chainloader /bootmgr
savedefault --wait=2

title --------------------
root

title Start Hiren's BootCD
find --set-root /HBCD/boot.gz
map --mem /HBCD/boot.gz (fd0)
map --hook
chainloader (fd0)+1
rootnoverify (fd0)
map --floppies=1
boot

# If you have any problem loading the above grub4dos map commands then try using memdisk kernel
# title Start Hiren's BootCD
# find --set-root /HBCD/boot.gz
# kernel /HBCD/memdisk
# initrd /HBCD/boot.gz

title Mini Windows Xp
find --set-root /HBCD/XPLOADER.BIN
chainloader /HBCD/XPLOADER.BIN

title --------------------
root

#title Debian squeeze 64bit 20101019
#find --set-root /ISO/debian-testing-amd64-netinst.iso
#map /ISO/debian-testing-amd64-netinst.iso (0xff)
#map --hook
#root (0xff)
#kernel /install.amd/vmlinuz boot=/install.amd/vmlinuz iso-scan/filename=/ISO/debian-testing-amd64-netinst.iso vga=788 --
#initrd /install.amd/initrd.gz
#boot

#title Debian squeeze 64bit 20101019
#kernel /debian-installer/amd64/linux
#append priority=low vga=788 initrd=debian-installer/amd64/initrd.gz --
#boot

title Ubuntu 64 mini
find --set-root /ISO/ubuntu-64-mini.iso
map /ISO/ubuntu-64-mini.iso (0xff)
map --hook
root (0xff)
kernel /linux boot=linux iso-scan/filename=/ISO/ubuntu-64-mini.iso quiet splash --
initrd /initrd.gz
boot

title Ubuntu 32 desktop
find --set-root /ISO/ubuntu-10.10-desktop-i386.iso
map /ISO/ubuntu-10.10-desktop-i386.iso (0xff)
map --hook
root (0xff)
kernel /linux boot=linux iso-scan/filename=/ISO/ubuntu-10.10-desktop-i386.iso quiet splash --
initrd /initrd.gz
boot

title Slackware 64 current mini iso
map (hd0,0)/ISO/slackware64-current-mini-install-new.iso (hd33)
map --hook
chainloader (hd33)
boot

#title Slackware current mini iso
#map (hd0,0)/ISO/13.1-mini.iso (hd33)
#map --hook
#chainloader (hd33)
#boot

title Slax remix v0.9 x86_64
map (hd0,0)/ISO/slax-remix-v09-x86_64.iso (hd33)
map --hook
chainloader (hd33)
boot

title Slax remix v0.9 i486
map (hd0,0)/ISO/slax-remix-v09-i486.iso (hd33)
map --hook
chainloader (hd33)
boot

for the bootsplash I personally doesn't care.

[Ahau]

@Falcony - great job! Thank you for setting that up!

@Ponce - thank you for the info, especially your menu.lst! I just put grub4dos on a USB drive, and was about to tackle the menu.lst. Now, all I have to figure out is how to set it up to boot Porteus when extracted.

@fanthom - since most drives are FAT by default, or could be reformatted to FAT from within windows, the lack of NTFS support in SYSLINUX would only seem to be a limitation if someone has a drive that they don't want to reformat or repartition for some reason. Could you elaborate some more on why this is an issue?

@all - does anyone know if grub, grub2 or grub4dos supports pxe? If not, then moving away from SYSLINUX tools would require a custom setup for someone who wishes to use pxe.

Also, does anyone know if it would be possible to install grub4dos in windows, with a setting that would immediately chainload into grub? If so, could we then move to grub (or grub2) as a universal bootloader, with the added (but virtually invisible) step of grub4dos as a cheat for those installing from windows? This would allow more unified configuration and feel, as well as a nicer bootsplash. I guess what I don't know is whether or not grub would have to be installed (other than just having the files present) in order to work.

I will be playing with this some more in the coming days

I'm pretty far outside my understanding here, so forgive me if I'm speaking in gibberish.

[ponce]

Now, all I have to figure out is how to set it up to boot Porteus when extracted.

looking at what markds posted here an entry like

Code: Select all

title porteus
root (hd0,0)
kernel /boot/vmlinuz from=/slax/ ramdisk_size=6666 root=/dev/ram0 rw copy2ram autoexec=xconf;startx
initrd /boot/initrd.lz

should suffice

http://slackbuilds.org/repository/13.1/system/grub4dos/

the only problem is the bootlace.com

Code: Select all

$ file /usr/sbin/bootlace.com 
/usr/sbin/bootlace.com: ELF 32-bit
$ ldd /usr/sbin/bootlace.com 
        not a dynamic executable

but 32bit elf support in kernel can be enough

[Falcony]

one problem: Windows users wont be able to install Porteus on NTFS without Grub4dos

Sure that won't L)

It could be used just for Windows, while normal Grub (Grub2?) could do the job for rest of fs on linux boxes.

May be grub2 - but only from Linux, from Windows -other way. You may try out this way.

For me personnally - for next release I would keep isolinux/isolinux/extlinux and may be update to last version
This is way of booting I know well
grub4dos already is currently- as option for HDD installation - may be rewrite scripts

falcony, grub4dos is active.

http://svn.gna.org/viewcvs/grub4dos/trunk/

Yep, minor bug fixing at 12 Aug 2010
And no code change for one year.
It seems I read old readme on sourcforge.

[ponce]

poor activity can mean also that's pretty stable

[Falcony]

poor activity can mean also that's pretty stable

And no development

the only problem is the bootlace.com

Not only one - grubinst on 64-bit buggy

but 32bit elf support in kernel can be enough

Does it mean that Porteus 0.9 has that support?
Yesterday I set grub4dos to usb on 64-bit Porteus

[fanthom]

@fanthom - since most drives are FAT by default, or could be reformatted to FAT from within windows, the lack of NTFS support in SYSLINUX would only seem to be a limitation if someone has a drive that they don't want to reformat or repartition for some reason. Could you elaborate some more on why this is an issue?

it is an issue for those who want to set up porteus on 80GB (or 320GB) external hd formatted with NTFS (don't think that anybody would use FAT there). They wont be able to do it from Windows.

@all - does anyone know if grub, grub2 or grub4dos supports pxe? If not, then moving away from SYSLINUX tools would require a custom setup for someone who wishes to use pxe.

don't know any bootloader which would allow PXE boot. AFAIK - PXE client must be included in the PC firmware (probably NIC).

Also, does anyone know if it would be possible to install grub4dos in windows, with a setting that would immediately chainload into grub? If so, could we then move to grub (or grub2) as a universal bootloader, with the added (but virtually invisible) step of grub4dos as a cheat for those installing from windows? This would allow more unified configuration and feel, as well as a nicer bootsplash. I guess what I don't know is whether or not grub would have to be installed (other than just having the files present) in order to work.

i think it's not possible as Windows user wont be able to execute linux code of normal grub, so it wont be possible to add it to the MBR. Windows users must rely on Grub4dos in this case.

@ponce
if bootlace.com is compiled statically (and probably is) the we shouldn't have a problem on 64bit box.

For me personnally - for next release I would keep isolinux/isolinux/extlinux and may be update to last version
This is way of booting I know well

We still have 3 months left to 1.0 release so can try some experiments

Does it mean that Porteus 0.9 has that support?

yes - 64bit version of Porteus currently uses 32bit /sbin/init as we need statically compiled executable for proper shutdown procedure (otherwise aufs will be 'busy').
64bit, compiled statically /sbin/init gives segfaults so i decided to go with 32bit and works nice

[Ahau]

i think it's not possible as Windows user wont be able to execute linux code of normal grub, so it wont be possible to add it to the MBR. Windows users must rely on Grub4dos in this case.

Ok--my thought was that we might be able to avoid writing grub to the MBR altogether, in the case of windows install. Grub would sit in the /boot folder, and only run when Grub4dos invoked it.

Of course, folks installing from linux could just install grub to the MBR directly.

I'm still very curious about this.

Posted after 2 hours 2 minutes 19 seconds:
@ponce-

Do you have to keep the menu.lst and grldr files in the device's root directory, or have you found a way to put them into /boot?

Just trying to keep this clean.

Thanks!

[Falcony]

We still have 3 months left to 1.0 release so can try some experiments

Sure.

i done enough experiments to understand that on 64-bit grub4dos is buggy and developers have not time to update code from 32 to 64-bit.
In my opinion - grub4dos may use as option but is not good as one uniform solution for all paltform

64bit, compiled statically /sbin/init gives segfaults so i decided to go with 32bit and works nice

That's reason why L)

[brokenman]

Ahau ... easy BCD chains to grub i think. It places a menu.lst in c:\NST