54 replies to this topic

[Wonko the Sane]

The good Linux guys - generally speaking - are not much communicative.

They tend to put such vital info as kernel parameters and "cheatcodes":

on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'."

Additionally they tend - at each distro release - to change some of them.

So, yes, it is not easy to find them though obviously some "general rules" do exist.

That is the idea behind the already given thread:
http://reboot.pro/5041/
and of of this (hopefully successful) just born initiative:
http://reboot.pro/13246/page__st__162

More generally, any Linux distro uses more or less one of the three loaders:

• GRUB (legacy) <- (syntax compatible with grub4dos)
• Syslinux/Memdisk/etc.
• GRUB2

so they do provide a menu.lst or a syslinux.cfg, or a grub.cfg with the "right" settings.

Additionally on their specific distro's Forums there may be "hints" or "full entries" for particular configurations.

So the "job" is to examine the specific entries in one of the three configuration files, and "translate" them to the "other" loader you choose (if possible).
Then test if the translated stuff actually works.

Since the good Linux guys mostly ignore grub4dos - which is probably seen as a somehow "unauthorised fork", MS friendly, of the "real pure linux" approach and IMHO the most flexible of the lot - they traditionally also ignore full .iso booting, often putting inside their releases *something* in initrd or however inside the .iso that is hardcoded or incompatible with .iso mapping.
Hopefully now that GRUB2 allows for using .iso as loopback, these incompatibilities may decrease and most distro's will become compatible with .iso booting either with mapping (grub4dos) or memory mapping (both grub4dos and Syslinux/Memdisk) or .iso loopback (GRUB2 and BURG), but as said, instead of focusing on "which is the best loader" (as you seem like being right now) you will have more and better result by flexibly choosing the actual loader for which you can find a working syntax and use whatever is easier to get the stooopid .iso to boot with.



Wonko

[tummychow]

Alright, that explains it. (So this, for example, would be the kernel options for ubuntu https://help.ubuntu....on Boot Options ?) What about the images that are based on DOS?

[Wonko the Sane]

Alright, that explains it. (So this, for example, would be the kernel options for ubuntu https://help.ubuntu....on Boot Options ?) What about the images that are based on DOS?

Why don't you READ first the available documentation and what you have already been pointed to?

Memdisk can boot *any* dos based image:
http://syslinux.zyto...dex.php/MEMDISK
http://syslinux.zyto..._13h_BIOS_calls

Syslinux can use .bss chainloading:
http://syslinux.zyto...NUX#KERNEL_file

And again, grub4dos is more flexible, as it can by-pass the bootsector and directly chainload most common DOS kernel files (IO.SYS of DOS 7.x and FreeDOS kernel.sys)


Wonko

[sbaeder]

Syslinux can use .bss chainloading:
http://syslinux.zyto...NUX#KERNEL_file

And again, grub4dos is more flexible, as it can by-pass the bootsector and directly chainload most common DOS kernel files (IO.SYS of DOS 7.x and FreeDOS kernel.sys)

Actually it can do pretty much the same things (as you did say above :-) See All options as available in chain.c32 of Syslinux 3.85: for the latest on using an indirect chaining module...

BUT, to me, having choice is a GOOD THING...I tend to like syslinux because it was what I first learned, BUT I agree 100% with the comment of use the one you like best for the MAIN loader, and chain to the other if/when you need to do something else...

[Wonko the Sane]

Actually it can do pretty much the same things....

Yep though noone will ever be able to find the COMBOOT/Chain.c32 info unless he/she already knows what COMBOOT is/what chain.c32 is .

I mean, noone landing here:
http://syslinux.zyto...ex.php/SYSLINUX
will ever be able to get to the COMBOOT/Chain.c32 page you mentioned:
http://syslinux.zyto...mboot/chain.c32

So, I didn't expect tummychow to be able to find it starting from there, whilst he may have been able to starting from the actual boot-land reboot.pro forum, sticky:
http://reboot.pro/8545/
which leads to here:
http://reboot.pro/8457/
(where anyway no link to the mentioned http://syslinux.zyto...mboot/chain.c32 page is given).

In other words, available info IS scattered all over the place and not properly linked/referenced , but the very basics of :

What about the images that are based on DOS?

are actually easily available, and one should be familiar with the "basic" and "traditional" ways before venturing into the "advanced" realm.

Or if you prefer, I would have better appreciated questions like :

I already tested DOS images with Memdisk booting and chianloading their bootsector images .bss files with Syslinux, are there other alternative ways?

or:

I cannot understand from the threads I'have seen what chain.c32 does, where can I get some more info?

Wonko

[sbaeder]

Wonko -

No offense meant, and yes, it took me quite a while to find that info, and it's not easy to locate...Wish more things had a more "open" wikipedia like process to improve how the docs are managed...

Sometimes in the age of IMs, Twitter, etc. we tend to just be short, which is often taken as a bit "rude"...And reading it back, I can see that, and will TRY (but we are all human here - at least I hope so)...

You are a master at a lot of this - including taking the time to answer a LOT of questions!!!!

#1 in my book!

Scott

[Wonko the Sane]

Wonko -

No offense meant, ...

And no offence not only taken but not even "detected".


Wonko

[tummychow]

Alright, I've been experimenting with both grub4dos and syslinux on an interim drive while I was waiting for my RMA, and it's finally come in. I have some new questions raised from messing with grub4dos.

1. What's the difference between booting from an ISO or image file, and booting from an extracted file system of that image file?
I was reading about booting systemrescuecd, and how you have to extract its file system to the USB key to make sure that the bootloader can find it. This seems rather inefficient to me since now I have the ISO, plus a big file that was originally part of the ISO. It would make rather more sense to me if I just unpacked the whole ISO into the USB key's file system, and then booted out of that folder into which I put the ISO. How do I switch from one system to the other? Is it simpler than I'm guessing?

2. Based on what I understand of the grub4dos menu.lst configuration syntax, find --set-root FILE locates the first disk to contain a given file, and then sets it as the root disk. I also roughly understand the map command (it targets a disk or folder and remaps it to another emulated disk, and the hook action forces all pending disk mappings to take place immediately). What are the parallels of these commands in the syslinux.cfg file, and for the various grub4dos commands in general what are their equivalents? I can see some parallels in the basic structure, but based on the commands listed here http://syslinux.zyto...ex.php/SYSLINUX, I can't find parallels for some commands in grub4dos, etc.

[sambul61]

Why would you need to unpack ISO files to begin with? Having a large easily pointed to and fast found ISO files collection delivers great opportunity to serve all your PC service needs from one folder.

Syslinux and Grub4DOS are developed by entirely different groups of programmers. I wouldn't make such assumption that all their command sets fully overlap and are easily convertible, and that there're ppl in-depth familiar with both who will drive you personally through the whole thing. It was suggested to you earlier try to master Grub4DOS first, and then see if it covered your needs. When you face a practical boot problem that can't be resolved in Grub4DOS, try Syslinux instead. Otherwise see if you can decipher more from available web references.

[tummychow]

The reason I want to unpack ISOs is exactly as noted. Let's say I'm working with a linux kernel like SystemRescueCD. I was reading the Grub4DOS working configurations, which had a working configuration for SystemRescueCD. The problem is that, for some reason or other, the bootloader fails to get the filesystem built into the kernel loaded quite right. To fix this problem, you have to unpack the entire file system (stored in the ISO as a dat file) to your UFD. This file takes up the majority of the space inside the ISO; I think it was around 200MB. At the same time, I have to keep the whole ISO on hand so that I can pick up any other bits that the bootloader would need to complete the boot process. This ISO still contains the 200MB file.
I am basically storing the same 200MBfile on my flash drive, but twice. Some other Linux kernels seem to behave the same way. I am facing the possibility of storing large 200+ MB files multiple times on one flash drive. I went for a 16GB drive on purpose because it has a large storage ceiling, but there will come a point where it's full, and I don't see the point of storing the same file over and over unnecessarily. In addition, it sounds to me like generally, there are more issues with booting from a live ISO than from a direct file system.
Isn't there a way to instead unload the contents of the ISO into a folder on the USB key, and then map the folder as the root drive to boot from? (Have I stumbled upon the solution in describing my question?)

As for the second question I asked, I wasn't expecting that the whole command sets would overlap. I had a feeling they wouldn't just by looking at them. But I am curious to know what commands do overlap and serve similar purposes to one another.

EDIT: Here's the post I'm referring to for the sysrescd thing: http://reboot.pro/50...dpost__p__79885

Edited by tummychow, 08 January 2011 - 01:57 AM.

[sambul61]

When booting Linux based ISOs, one needs to pass any relevant kernel and initrd parameters to either Grub4DOS or Syslinux. That's why you were given links to apps that automate preparing bootloader config files. It was also mentioned, you may chainload one bootloader from another as a menu item thus making such boot system very flexible.

The post you referred to shows a workaround aimed at avoiding customized menu items in Grub4DOS at booting Linux Distros. A link was also given earlier to the thread explaining more systemic approach at booting Linux Distros with Grub4DOS. Thus you don't have to follow that workaround demanding bigger drive space. Instead, search for tested menu & config examples for booting most popular Linux Distros. There is NO other generalized approach that would fit ANY Distro you may want to boot.

Understand that all the work is mostly done by volunteers, and there are very few out there willing to prepare detail documentation and comprehensive teaching methodology to make this learning process an easy journey. Its quite involving and demanding yet rewarding at the end. Both these tools are valuable IMHO. But there is NO comparative introduction to Syslinux (apart from such user sharing threads ) or many other tools that would ideally require such introduction and survey.

[tummychow]

You mean this for "more systemic", right? http://reboot.pro/13...page__p__117656

The problem, from that thread (I looked at it earlier), is that the kernel, once it takes over the boot process, ignores the disk mapping commands performed in grub4DOS, which means that it has to find those files on the partition, rather than in the ISO. But I'm not sure I understand the advised workarounds. They're just going over my head. I suspect it has something to do with the kernel and initrd commands right on the end in the menu.lst?
For example, http://www.sysresccd...ting_the_CD-ROM
What commands here would be the ones I'd need to make it work? Or are those not even the commands I'm looking for?

Edited by tummychow, 08 January 2011 - 11:08 PM.

[sambul61]

An obvious workaround would be to try using already tested menu examples for various Linux images. Over the time you will get a better grip on handling similar tasks when a suitable example is not found. Don't be a maximalist... Did you try to find tested menu & cfg examples for Sysresccd here on Reboot and other similar forums? If not found, may be some guys working daily with Syslinux can help...

[tummychow]

That was the only one I could find. I looked through the rest of the thread, and here's another one I found:

#SystemRescueCd is extracted the whole iso to usbroot/sysrcd

title SystemRescueCd

kernel /sysrcd/isolinux/rescuecd subdir=sysrcd setkmap=de

initrd /sysrcd/isolinux/initram.igz

Which involves extracting the whole thing. That's why I was asking how to boot an extracted ISO.

[sambul61]

If you google a bit more, sure you can find various options to boot SystemRescueCD ISO in Windows. If you want to simply add this CD image to service ISO collection on your HD, one way to boot it without any unpacking is to chainload Grub24DOS (a Win port of newer Linux bootloader Grub2) from Grub4DOS (or simply replace Grub4DOS with Grub24DOS altogether), and then use Grub2 cfg example for SystemRescueCD to boot the ISO.

In fact, special Loopback.cfg file is included in current SystemRescueCD. "With a loopback.cfg you get the full menu of options at boot and don't have to worry about differences between different distributions." Read more about notable advantages of using Loopback.cfg in SuperGrub(2)Disk Wiki.

Look also through Converting isolinux.cfg to G4D menu.lst and similar "menu conversion" threads for more ideas allowing to boot the same images with either Grub4DOS or Syslinux as you choose. For some distros you might not need Grub24DOS in this scenario.

[tummychow]

The explanation on the sysrescd wiki actually worked for me when I unpacked the whole 2.0.0 iso. I'm going to start looking into some other stuff now to try something bigger on my new 16gb, thanks for all the help so far.

[sambul61]

You don't need to unpack any ISO when using Grub2 Loopback command. As mentioned above, a special Loopback.cfg file is included with Sysrescd by default. Look through all above links again. Keep in mind, Grub2 is not Grub4DOS.

[tummychow]

That's the thing though; I don't want to chainload grub2 when I can just extract the whole ISO.

[sambul61]

Of course if your sole purpose is to boot a single ISO - Sysrescd, having no other ISOs on your rescue drive, including DOS and WinPE based, you just use Grub2 thus eliminating the need to chainload anything, or simply install Sysrescd as explained in its docs. In case of a multiboot thumb with some WinPE or DOS based ISOs you may still need to chainload (say add Grub24DOS as a menu item on Grub4DOS Menu.lst) to save some disk space used by the unpacked ISO files (as you complained above ). In fact, hugely popular EasyBCD Boot Manager is a leaving proof of high demand for building a Windows Boot Menu allowing to choose one of several bootloaders each addressing its own scope of tasks. Hence, consider chainloading be a routing component of building a Multiboot Thumb.

[tummychow]

Out of curiosity, do ISOs still have to be contiguous for grub2 and grub24dos? I've read in a lot of places that it's a problem for loading straight from ISO in grub4dos.
In any case, I actually really get it (the whole multiboot business I'm going into), big thanks for all your help so far!

[Icecube]

Out of curiosity, do ISOs still have to be contiguous for grub2 and grub24dos? I've read in a lot of places that it's a problem for loading straight from ISO in grub4dos.

No. grub2 just sees the ISO as an archive and extracts the kernel and initramfs out of the ISO. It doesn't really "mount" the ISO like a CD, like grub4dos does.

[sambul61]

But once the distro kernel is extracted from ISO and run, doesn't it look for its root in the mounted ISO file? Or mounting ISO at that time is done after mapping & loading it to RAM?

tummychow

You're not done yet, until you scrap everything you did so far, and use your fresh earned experience to install Burg as your main (and possibly only) bootloader. Its a Grub2 fork with some Grub4DOS features installable in Windows and supporting boot of Linux, DOS and WinPE based images.

[tummychow]

Which one should I stick to, BURG or Grub24DOS? They sound rather similar to me, grub24DOS being a port of Grub2 to windows, and burg having some grub4dos features.

[sambul61]

It seems like Burg is a Grub2 fork being developed by a former Grub4DOS developer, hence its leaning towards implementing current Grub4DOS features supporting WinPE boot and others in addition to Grub2 offered enhanced Linux boot features. Other Grub4DOS developers may joint Burg bandwagon soon or later as a continuation project to Grub4DOS.

On the other hand Grub24DOS is compiled using pure Grub2 binaries, its suited to try using Grub2 in Windows, but less interesting feature wise. Btw, bootloaders like Grub4DOS can boot not only ISO images, but also all kind of other images, which makes them quite attractive to use for PC service tasks. Yet they can't boot some images so far like virtual drive images. For that purpose VMLite Vboot may be a good chainloading option, since it allows to boot VHD/VMDK/VDI/Raw images.

[tummychow]

I'm not sure I understand how to install BURG onto a flash drive. It's done with fbinst to put a loader file into the MBR (like grldr for grub4DOS), right? But I need other parts, don't I? Are there any precompiled packages of all the stuff I need to install BURG to a flash drive?
(This http://code.google.c.../InstallWindows for example discusses installing BURG to your main HDD, which I'd rather not do. This http://reboot.pro/12474/ tells me what files I need, but I don't know where to find those buldr files.)