Re: Announcing mkisofs 1.13
[Robert Millan] In 2006, the cdrtools version of mkisofs spawned another fork: genisoimage, which was included as part of cdrkit package in the Debian GNU/Linux distribution. I don't know if this is any use, but: my humble contributions to the cdrkit project, past and future, may be distributed under the terms of the GNU General Public License, version 2 or (at your option) any later version. The same for any non-humble contributions in the future. I note that I do not have copyright assignment paperwork on file with the FSF. (Did Eric Youngdale or Yggdrasil Computing?) In the cdrkit/debburn Subversion repository, my contributions are under the usernames 'peters-guest' and 'peters'. Peter Samuelson signature.asc Description: Digital signature
Re: GNU isofsmk (was: Re: Announcing mkisofs 1.13)
Robert Millan r...@aybabtu.com wrote: On Sun, Jan 10, 2010 at 12:09:50AM +0100, Joerg Schilling wrote: If you really like to take the outdated mkisofs and play with it, I urge you not to use the name mkisofs for this Next release will be renamed to GNU isofsmk to make sure users won't get confused. You still confuse people by publishing a file called mkisofs-1.13.tar.gz that does not match the checksum from the original at: ftp://ftp.berlios.de/pub/cdrecord/mkisofs/old/mkisofs-1.13.tar.gz Please remove this file from ftp.gnu.org. Note that your tar archive contains a file NEWS that makes incorrect claims: - The software you published does not support files = 4 GB The original mkisofs supports files 4 GB (implemented by me) since 3.5 years. This claim isn't incorrect, but perhaps isn't clear enough: It refers to a limit in the size of the filesystem image itself, rather than its content. Mkisofs supports large files for the file system image since 9 years. Claiming that you added this now does not look like a valid statement. 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
GNU isofsmk (was: Re: Announcing mkisofs 1.13)
Hi, On Sun, Jan 10, 2010 at 12:09:50AM +0100, Joerg Schilling wrote: If you really like to take the outdated mkisofs and play with it, I urge you not to use the name mkisofs for this Next release will be renamed to GNU isofsmk to make sure users won't get confused. Note that your tar archive contains a file NEWS that makes incorrect claims: - The software you published does not support files = 4 GB The original mkisofs supports files 4 GB (implemented by me) since 3.5 years. This claim isn't incorrect, but perhaps isn't clear enough: It refers to a limit in the size of the filesystem image itself, rather than its content. -- Robert Millan Be the change you want to see in the world -- Gandhi -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
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 mkisofs 1.13
On Fri, Jan 08, 2010 at 11:49:33PM +0100, Thomas Schmitt wrote: Hi, * Support for creating large images ( 4 GiB). You are aware that even quite young Linux kernels have problems to read multi-extent files ? I didn't know about this. Thanks for noting it. * Support for El Torito without floppy emulation. (this is the default now; --eltorito-emul-floppy brings back the old behaviour) Do you have experience with El Torito pointing to something other than ISOLINUX ? I happen to be maintainer of GNU GRUB, so yes ;-) (Nothing against ISOLINUX. I just wonder whether there are other El Torito bootable systems and how to bring them into an ISO image.) GRUB supports booting from an ISO in three different ways: 1- El Torito (for CD media) 2- Traditional disk-based boot (for ISO in disk media) 3- Multiboot (for coreboot+GRUB platforms, but may be used anywhere) The third one is a legacy-free boot protocol based on the Multiboot specification. Basically, firmware loads a Multiboot image from the ISO filesystem, and that image is capable of figuring out the disk in which it was installed, then load the rest of stuff from it. * Support for embedding bootloader code for disk boot on PC/BIOS platforms (--embedded-boot option). Do you have specs for that ? libisofs does the isohybrid MBR trick of ISOLINUX but cannot install MBRs in general. (The question is about how one has to patch the boot image and/or the MBR after the block address of the boot image is determined.) I don't understand your question. First 32 kiBs are used to embed a chunk of arbitrary data. mkisofs is agnostic to its meaning, but from BIOS POV this includes an MBR (first 512 bytes), which will usually load the remaining 32256 bytes, but that's really up to bootloader implementation (in the case of GRUB, it loads the second sector which in turn loads the rest of core.img based on its pre-encoded size, which in turn will search for /boot/grub/ in the filesystem). --protective-msdos-label option may be used to patch a protective MSDOS label into the MBR. Do you have plans for UDF ? (Problem seems to develop a proper model of how the components of ECMA-167 form an UDF compliant graph that implements multi-session.) I'm considering appliing for GSoC under the GNU umbrella this summer to get UDF kicked out. The ideal would be if someone who's got good understanding of this standard will be interested in mentoring this project. -- Robert Millan Be the change you want to see in the world -- Gandhi -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing mkisofs 1.13
Do you have plans for UDF ? (Problem seems to develop a proper model of how the components of ECMA-167 form an UDF compliant graph that implements multi-session.) I'm considering appliing for GSoC under the GNU umbrella this summer to get UDF kicked out. The ideal would be if someone who's got good understanding of this standard will be interested in mentoring this project. -- Robert Millan While I really can't promise much this year, if I can be of any help with this I will try. I don't have a thorough understanding of the UDF standard, but know a bit or two about it because I studied it when I wrote an enchantment ticket against new libisofs we were designing. Also, I'd encourage working on UDF inside libisofs and eventual genisofs (CLI-compatible mkisofs-alike tool based on libisofs, but that's probably a long shot because you seem to want mkisofs :) And after all this, thank you for all your work, valuable contributions and insights. Cheers, Mario Be the change you want to see in the world -- Gandhi -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing mkisofs 1.13
On Sat, Jan 09, 2010 at 09:26:33PM +0100, Mario Đanić wrote: I'm considering appliing for GSoC under the GNU umbrella this summer to get UDF kicked out. The ideal would be if someone who's got good understanding of this standard will be interested in mentoring this project. While I really can't promise much this year, if I can be of any help with this I will try. I don't have a thorough understanding of the UDF standard, but know a bit or two about it because I studied it when I wrote an enchantment ticket against new libisofs we were designing. Hi Mario! Thanks for your offer, it's very kind of you. I'm not sure if you've been a mentor in GSoC before, but it's not a tough task IMO and you get a nice tshirt! ;-) Also, I'd encourage working on UDF inside libisofs and eventual genisofs (CLI-compatible mkisofs-alike tool based on libisofs, but that's probably a long shot because you seem to want mkisofs :) What is libisofs main purpose? Is it meant to be used by filesystem code in OS kernels, by some specific class of applications... ? -- Robert Millan Be the change you want to see in the world -- Gandhi -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing mkisofs 1.13
On Sat, Jan 9, 2010 at 21:55, Robert Millan r...@aybabtu.com wrote: On Sat, Jan 09, 2010 at 09:26:33PM +0100, Mario Đanić wrote: I'm considering appliing for GSoC under the GNU umbrella this summer to get UDF kicked out. The ideal would be if someone who's got good understanding of this standard will be interested in mentoring this project. While I really can't promise much this year, if I can be of any help with this I will try. I don't have a thorough understanding of the UDF standard, but know a bit or two about it because I studied it when I wrote an enchantment ticket against new libisofs we were designing. Hi Mario! Thanks for your offer, it's very kind of you. I'm not sure if you've been a mentor in GSoC before, but it's not a tough task IMO and you get a nice tshirt! ;-) Both a mentor and a student, and an unofficial admin (reading all applications, and ranking them *sigh*). Being part of the program is very rewarding, and subsequently its a great privilege to work with a great student. Also, I'd encourage working on UDF inside libisofs and eventual genisofs (CLI-compatible mkisofs-alike tool based on libisofs, but that's probably a long shot because you seem to want mkisofs :) What is libisofs main purpose? Is it meant to be used by filesystem code in OS kernels, by some specific class of applications... ? Lemme do some c/p: libisofs is a library to create an ISO-9660 filesystem with extensions like RockRidge or Joliet. It is also a full featured ISO-9660 editor, allowing you to modify an ISO image or multisession disc, including file addition/removal, change of file names and attributes, etc. libisofs supports the extension AAIP which allows to store ACLs and xattr in ISO-9660 filesystems. If linked with zlib then it supports zisofs compression which is transparently uncompressed by some Linux kernels. It is possible to have data file content compressed to gzip format or to have it filtered by an external process. So ummm, I'd say its supposed to be used for whatever fits the stated purpose and feature-set? :) Cheers, Mario -- Robert Millan Be the change you want to see in the world -- Gandhi -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing mkisofs 1.13
Hi, I happen to be maintainer of GNU GRUB, so yes ;-) Nice incidence. I will leech you for the final boot loader of the emerging libburnia OS farm. (The question is about how one has to patch the boot image and/or the MBR after the block address of the boot image is determined.) I don't understand your question. First 32 kiBs are used to embed a chunk of arbitrary data. The System Area as of ECMA-119. The first 512 bytes can be used as MBR. So depending on the media the BIOS can either boot via the El Torito block or via the MBR. With ISOLINUX/isohybrid i have to tell the MBR where the boot image isolinux.bin is located on the media. The method and the MBR template stems from syslinux-3.72/utils/isohybrid which operates on a El Torito enhanced ISO 9660 image in a disk file. libisofs does this on-the-fly during image generation, if desired by the application. The ideal would be if someone who's got good understanding of this standard will be interested in mentoring this project. A person who understands ECMA-167.pdf and udf260.pdf, and can sketch out a multi-session layout for sequential media ... yes, that would be ideal. :)) Mario wrote: genisofs That one lies unprogrammed since only 3.5 years. We'll have to wait a while until its decade of hibernation is full. (I have escaped into xorriso and am not to blame.) (Also i build up the OS farm and am not to blame for not doing UDF in the next time.) What is libisofs main purpose? Is it meant to be used by filesystem code in OS kernels, by some specific class of applications... ? I see Mario answered already. Nevertheless my two cents: It shall be a complete ISO 9660 Rock Ridge manipulator in userspace. An alternative to the kernel for reading and especially an opportunity for generating images. Rock Ridge is quite essential for multi-session because ISO 9660 namespace allows no decent name mapping from a disk filesystem. My personal goal is give it backup-grade fidelity. See the filesystem oriented capabilities of http://scdbackup.sourceforge.net/xorriso_eng.html (genisofs would be our mkisofs emulator. But i deem the architecture of separate ISO generator and burn program quite suboptimal. So i rather started an integrated ISO+burn tool.) 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 mkisofs 1.13
On Sat, Jan 09, 2010 at 10:27:20PM +0100, Mario Đanić wrote: Both a mentor and a student, and an unofficial admin (reading all applications, and ranking them *sigh*). Being part of the program is very rewarding, and subsequently its a great privilege to work with a great student. :-) Lemme do some c/p: libisofs is a library to create an ISO-9660 filesystem with extensions like RockRidge or Joliet. It is also a full featured ISO-9660 editor, allowing you to modify an ISO image or multisession disc, including file addition/removal, change of file names and attributes, etc. libisofs supports the extension AAIP which allows to store ACLs and xattr in ISO-9660 filesystems. If linked with zlib then it supports zisofs compression which is transparently uncompressed by some Linux kernels. It is possible to have data file content compressed to gzip format or to have it filtered by an external process. Thanks for the explanation. Something to keep an eye on! -- Robert Millan Be the change you want to see in the world -- Gandhi -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing mkisofs 1.13
Robert Millan r...@aybabtu.com wrote: On Fri, Jan 08, 2010 at 05:30:09PM +0100, Joerg Schilling wrote: You also do not mention that the even outdated version of mkisofs you are using contains code from me. This is true (at least for files prototyp.h, fctldefs.h, statdefs.h and mconfig.h where your name appears). It's not my intention at all to neglect your contribution, it just happens that I didn't have all the information. If you're so kind to provide a short summary of your improvements in that version, I'll be glad to add your name in AUTHORS file and give proper recognition. What is the reason for creating a fork from a completely outdated and extremely buggy historic version of mkisofs? Please note that I am constantly contributing to the mkisofs project since Spring 1996 and that the first mkisofs version published by Eric Youngdale with a contribution from me was mkisofs-1.10b7-no_ac from February 1997. I remember that my first contribution (in Spring 1996) was the correction of the timezone offset and that e.g. the option -print-size is from me. As many years have past since then, I of course cannot name _all_ contributions anymore. Since Autumn 1999, I am the official primary maintainer and for this reason, the mkisofs that comes with cdrtools is _no_ fork but the original version. There was an official mkisofs-1.13 publishec in June 2000 and you obviously created a clash. If you really like to take the outdated mkisofs and play with it, I urge you not to use the name mkisofs for this and I urge you to withdraw your tar archive from the ftp server as long as you use the original name mkisofs. Note that your tar archive contains a file NEWS that makes incorrect claims: - The software you published does not support files = 4 GB The original mkisofs supports files 4 GB (implemented by me) since 3.5 years. - The software you published contains an extremely outdated Eltorito support. The original mkisofs supports nearly all Eltorito featues (implemented by me) and this is what people today use to create bootable CDs (e.g. for GRUB). If you believe that the current original mkisofs (see ftp://ftp.berlios.de/pub/cdrecord/alpha/) is missing important features, please collaborate with the cdrtools project. The cdrtools project is open for everyone and this is one of the reasons why cdrtools ports to 30 different platforms (not counting different CPUs as different platform). From looking at your tar archive, it seems that you may have some skills with localization (text ranslations) or that you know translators. As the next development cycle of cdrtools will very soon introduce localized strings for all commands, I am looking for translators So are you interested to contribute and to collaborate? 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: Announcing mkisofs 1.13
On Sat, Jan 09, 2010 at 11:03:39PM +0100, Thomas Schmitt wrote: Hi, I happen to be maintainer of GNU GRUB, so yes ;-) Nice incidence. 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 question is about how one has to patch the boot image and/or the MBR after the block address of the boot image is determined.) I don't understand your question. First 32 kiBs are used to embed a chunk of arbitrary data. The System Area as of ECMA-119. The first 512 bytes can be used as MBR. So depending on the media the BIOS can either boot via the El Torito block or via the MBR. Yeah, that'd be it. With ISOLINUX/isohybrid i have to tell the MBR where the boot image isolinux.bin is located on the media. The method and the MBR template stems from syslinux-3.72/utils/isohybrid which operates on a El Torito enhanced ISO 9660 image in a disk file. Ah, I see. Well, GRUB uses an entirely different approach: - System area contains GRUB core.img image (GRUB's kernel plus a few modules like filesystem driver). - core.img is instructed to search in /boot/grub/ for grub.cfg and other modules, etc. So, it'd seem that unlike ISOLINUX, GRUB makes use of the whole System area (well, not all of it, but close: just as much as occupied by core.img). 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: grub-mkrescue --output=grub.iso [somedir] which as of recent Bazaar produces images that are bootable as HD media. (genisofs would be our mkisofs emulator. But i deem the architecture of separate ISO generator and burn program quite suboptimal. So i rather started an integrated ISO+burn tool.) You don't like pipes!? What kind of Un*x hacker are you ;-) -- Robert Millan Be the change you want to see in the world -- Gandhi -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing mkisofs 1.13
Robert Millan r...@aybabtu.com wrote: I'm proud to announce the release of GNU mkisofs version 1.13. Could you please explain this? Do you like to confuse people with outdated software? This looks like complete nonsense. The official mkisofs is part of cdrtools since a long time and the official mkisofs that is part of cdrtools has major enhancements compared to the completely outdated stuff you present! Also note that there was an official mkisofs with version number 1.13 that has been published on July 20th 2000. This release implements a few new features relative to the previous one (mkisofs 1.12b5). But most importantly, the codebase has been updated to modern standards and the build system has been rewritten from scratch using recent GNU autotools. 1.12b5 was full of bugs. It seems that you like to fool people with buggy software. Well, your source does not even compile As this is the first release of GNU mkisofs in more than 10 years, some explanation is in order: This program was initially written for the GNU system in 1993, by Eric Youngdale, who maintained it up untill 1997. Shortly afterwards, a derivative of GNU mkisofs was incorporated into cdrtools, the CD/DVD recording package. In 2006, the cdrtools version of mkisofs spawned another fork: genisoimage, which was included as part of cdrkit package in the Debian GNU/Linux distribution. You are wrong! The mkisofs in cdrtools is _not_ a fork but the official release. You also do not mention that the even outdated version of mkisofs you are using contains code from me. If you really like to start a project on completely outdated sources, use a different name! 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: Announcing mkisofs 1.13
* On 08.01. Joerg Schilling muttered: Well, your source does not even compile At least it compiles on my machine. Regards Til -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing mkisofs 1.13
Til Schubbe li...@lists.schubbe.org wrote: Well, your source does not even compile At least it compiles on my machine. Nobody is interested in software from 1997 and with only the features from 1997. 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: Announcing mkisofs 1.13
Hi, I'm proud to announce the release of GNU mkisofs version 1.13. Wow. That is kindof a blast from the past. bringing it to up-to-date standards, as well as implementing some unique features that are necessary for GRUB, the GNU bootloader. Would you be interested in cooperating with the libburnia project ? (Exchanging knowledge, sharing extension features, ...) up-to-date standards ... would that mean UDF ? 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 mkisofs 1.13
Hi, On Fri, Jan 08, 2010 at 05:30:09PM +0100, Joerg Schilling wrote: You also do not mention that the even outdated version of mkisofs you are using contains code from me. This is true (at least for files prototyp.h, fctldefs.h, statdefs.h and mconfig.h where your name appears). It's not my intention at all to neglect your contribution, it just happens that I didn't have all the information. If you're so kind to provide a short summary of your improvements in that version, I'll be glad to add your name in AUTHORS file and give proper recognition. -- Robert Millan Be the change you want to see in the world -- Gandhi -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing mkisofs 1.13
On Fri, Jan 08, 2010 at 08:24:10PM +0100, Thomas Schmitt wrote: bringing it to up-to-date standards, as well as implementing some unique features that are necessary for GRUB, the GNU bootloader. Would you be interested in cooperating with the libburnia project ? (Exchanging knowledge, sharing extension features, ...) Of course. I'm open to collaboration with all the interested parties, including libburnia, cdrkit and cdrtools. up-to-date standards ... would that mean UDF ? Silly me, I think I forgot to attach the NEWS file! This basically referred to items 2 and 3, see attachment. -- Robert Millan Be the change you want to see in the world -- Gandhi New in 1.13: * Lots of miscellaneous cleanup. * Support for creating large images ( 4 GiB). * Support for El Torito without floppy emulation. (this is the default now; --eltorito-emul-floppy brings back the old behaviour) * Support for localization of user messages. * Support for embedding bootloader code for disk boot on PC/BIOS platforms (--embedded-boot option).
Re: Announcing mkisofs 1.13
Hi, * Support for creating large images ( 4 GiB). You are aware that even quite young Linux kernels have problems to read multi-extent files ? My 2.6.18 swallows the last few bytes if the file size is not a multiple of 2048. (libisofs can dare to produce such files without warning because itself is able to extract them out of ISO images, if the kernel cannot.) * Support for El Torito without floppy emulation. (this is the default now; --eltorito-emul-floppy brings back the old behaviour) Do you have experience with El Torito pointing to something other than ISOLINUX ? (Nothing against ISOLINUX. I just wonder whether there are other El Torito bootable systems and how to bring them into an ISO image.) * Support for embedding bootloader code for disk boot on PC/BIOS platforms (--embedded-boot option). Do you have specs for that ? libisofs does the isohybrid MBR trick of ISOLINUX but cannot install MBRs in general. (The question is about how one has to patch the boot image and/or the MBR after the block address of the boot image is determined.) Oh well, i hoped for allies in a session oriented UDF endeavor. Proper multi-session, so that not can happen what happened to the backup of Zhang Weiwu. (First session UDF+ISO, second ISO, mount gets confused.) Do you have plans for UDF ? (Problem seems to develop a proper model of how the components of ECMA-167 form an UDF compliant graph that implements multi-session.) 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
