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
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
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 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
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
Announcing mkisofs 1.13
Hi, I'm proud to announce the release of GNU mkisofs version 1.13. 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. A source tarball for the new release can be found at: http://ftp.gnu.org/gnu/mkisofs/mkisofs-1.13.tar.gz and its GPG detached signature [*]: http://ftp.gnu.org/gnu/mkisofs/mkisofs-1.13.tar.gz.sig [*] You can use the above signature file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify mkisofs-1.13.tar.gz.sig If that command fails because you don't have the required public key, then run this command to import it: gpg --keyserver keys.gnupg.net --recv-keys DEA2C38E and rerun the `gpg --verify' command. This release was bootstrapped with the following tools: Gettext 0.17 Automake 1.10.1 Autoconf 2.61 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. Unfortunately, both forks of mkisofs shared the same problem: they introduced new code under terms that would made them incompatible with future versions of the GNU General Public License. Although this didn't cause any practical issues at the time, it became problematic when version 3 of the GNU GPL was released in 2007: code licensed under the incompatible terms couldn't be used by programs that adopted the new license. Because of this, the GNU project has resumed work on mkisofs, starting with modernization of the codebase, bringing it to up-to-date standards, as well as implementing some unique features that are necessary for GRUB, the GNU bootloader. -- Robert Millan Be the change you want to see in the world -- Gandhi signature.asc Description: Digital signature
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).
