Re: Announcing mkisofs 1.13
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
Re: Announcing a fork from mkisofs
Robert Millan r...@aybabtu.com wrote: 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 Of course, if you put together all the details (like building core.img and filling up /boot/grub structure), it gets a bit hairy, so grub-mkrescue utility is provided with GRUB: There is no need to implement such a nonstandard thing as mkisofs allows you to call: mkisofs -V $volid -o xxx.iso -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table somedir What benefit do you see from using your proposal? What benefit do you see from not collaborating with the cdrtools project? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Linux, ISOFS, multi-extent files: what's the status?
On Sat, 09 Jan 2010 16:35:04 +0100, joerg.schill...@fokus.fraunhofer.de (Joerg Schilling) wrote: Well, if you can read files 4 GB correctly, it may be that the problem has been fixed in a different way. is there any patch related to iso9660 in your kernel? I unpacked the RHEL5 kernel src.rpm. The only patch applied to the vanilla 2.6.18 kernel for the isofs/ dir is the elimination of any reference to the inode-i_blksize struct member, but this is something they did across the board for all the file systems (it was an official patch applied to the kernel.org kernel a few days after 2.6.18) and has nothing to do with actual isofs issues. I made the same test (multi-extent 4.3 GB file) on kernel 2.4.33 and it passed OK on that too. So far I only tested loop-mounted isofs image files, not real DVD/BD-RE media. I'll do more test next week. If someone has a procedure to get the multi-extent Linux problem to manifest itself, please post it. Thanks -- giul...@pobox.com -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Linux, ISOFS, multi-extent files: what's the status?
Hi, If someone has a procedure to get the multi-extent Linux problem to manifest itself, please post it. I tried yours and i seem to have the original plague with i/o error and all. (Unclear why i cannot remember of the error back in 2008.) $ dd if=/dev/urandom of=filetest bs=100 count=4300 $ mkisofs -quiet --iso-level 3 -o test.iso filetest # mount -o loop /dvdbuffer/test.iso /mnt/ $ wc /mnt/filetest wc: /mnt/filetest: Input/output error 16802026 97698513 427184 /mnt/filetest 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
