Hi, > > I will leech you for the final > > boot loader of the emerging libburnia OS farm.
> Be my guest. You can also try grub-de...@gnu.org. The OS installations tend to overwrite each others bootloaders. Currently i am working on the FreeBSD installation which seems to be the first which did not hide the others. (Ubuntu and SuSE rather fight over the MBR.) When the farm is full and i get tired of booting via rescue discs then i will have to learn how to manage booting myself. > - System area contains GRUB core.img image > (GRUB's kernel plus a few modules like filesystem driver). So one does not have to search for it. > - core.img is instructed to search in /boot/grub/ for > grub.cfg and other modules, etc. Very convenient. > So if you'd like to create a GRUB bootable disk, you'd do something > like: > cat boot.img core.img > tmp > mkisofs --embedded-boot tmp -o grub.iso -r somedir I would be interested to learn what mkisofs does with tmp. Just copy it to the System Area ? Or is there any info to be inserted that was gained from the emerging ISO image ? To what address shall the El Torito record point ? (With ISOLINUX we patch the boot image, create the El Torito record, and eventually copy a patched MBR.) > > i deem the architecture of separate ISO generator > > and burn program quite suboptimal. > You don't like pipes? What kind of Un*x hacker are you ;-) Oh, it's not so much the pipe mkisofs -M ... -C $c_values ... | cdrecord dev=... although the libisofs output fifo is better adapted to the situation than a pipe. It is rather the method to obtain the parameter for -C c_values=$(cdrecord dev=... -msinfo 2>/dev/null) and the way how it is applied blindly to the device of the burn run. There is a lot of room for mishaps with this architecture. Not to forget the fundamental problem, that mkisofs uses the Linux block device driver for reading the -M device, whereas the burn programs use the generic SCSI driver to write. This is a peculiar mix which makes necessary the drive tray ballet of growisofs. (Many systems cannot read via block device what they just wrote via generic.) Here i deem the libisoburn architecture superior. Under its control, libisofs uses libburn for reading and for writing. libburn does all its drive operations via the generic SCSI interface. With our main write of "growing", reading and writing is guaranteed to happen on the same media. (We also have a media-to-media copy method "modifying" and the cdrtools method of "blind growing" with separates processes for reading and writing.) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org