Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Thomas Schmitt wrote: Hi, Ok, legacy :(. But --efi-boot would have no legacy. --efi-boot will be all at your service. :)) The more definite your wishes, the more swift their implementation. Maybe we should call it --efi-grub-boot just to make clear whom it cares for ? Right now it has nothing grub-specific. However I don't care much about the exact name. Feel free to use whatever you want and I'll make the adjustments in grub-mkrescue Shall the --efi* option have any influence on the BIOS boot stuff except the boot catalog ? (Default Entry, BIOS boot image, ...) No xorriso-0.5.3 timestamp 2010.04.18.100814 allows to set LBA sorting weights. Within the mkisofs emulation it is: --sort-weight number ISO-path If ISO-path is a directory, then its whole tree is affected. --sort-weight can get overridden by further --sort-weight options. They get applied after all files are added to the image. The boot catalog already has a hardcoded weight of 1000 in libisofs. It cannot be influenced by --sort-weight because it gets created after the image manipulations are done. The boot catalog of grub-mkrescue has no ISO-path anyway (no option -c). So in grub-mkrescue , this would give all files weight 0, then override the /boot/grub tree by 1, and the -b file by 2: --sort-weight 0 / \ --sort-weight 1 /boot/grub \ --sort-weight 2 /boot/grub/i386-pc/eltorito.img \ Thanks for the information. I'll look into it. After the image is written, xorriso can display the data LBAs of regular files: xorriso \ -indev image.iso \ -find / -sort_lba -exec report_lba -- \ 2/dev/null | less yields: Report layout: xt , Startlba , Blocks , Filesize , ISO image path File data lba: 0 , 38 , 12 ,24317 , '/boot/grub/i386-pc/eltorito.img' File data lba: 0 , 50 ,6 ,10564 , '/boot/grub/i386-pc/acpi.mod' ... For the boot catalog LBA, one has to peek binary (even if there was a ISO-path leading to it). This reads the LBA word from El Torito record: dd if=image.iso bs=1 skip=34887 count=4 \ 2/dev/null | od -x yields LBA 37 (decimal) 000 0025 (There is a mkisofs option -sort with a file as argument where single files get a weight. Wildcards are promised in mkisofs/README.sort. For now i deem that rather unappealing.) I will now finish multi-session MBR handling and release libisoburn-0.5.4. Then begins the next development cycle with EFI, adjustable boot catalog weight, ... Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Hi, Ok, legacy :(. But --efi-boot would have no legacy. --efi-boot will be all at your service. :)) The more definite your wishes, the more swift their implementation. Maybe we should call it --efi-grub-boot just to make clear whom it cares for ? Shall the --efi* option have any influence on the BIOS boot stuff except the boot catalog ? (Default Entry, BIOS boot image, ...) http://bzr.savannah.gnu.org/r/grub/people/phcoder/rescue-efi/ My bzr is too old for that. :( It is from 2009. Hrmpf. Is there a web interface to browse the source for a first glimpse ? BIOS+EFI one should look like ... Ok. I will start this in a few days. Keep your test environment ready. :)) xorriso-0.5.3 timestamp 2010.04.18.100814 allows to set LBA sorting weights. Within the mkisofs emulation it is: --sort-weight number ISO-path If ISO-path is a directory, then its whole tree is affected. --sort-weight can get overridden by further --sort-weight options. They get applied after all files are added to the image. The boot catalog already has a hardcoded weight of 1000 in libisofs. It cannot be influenced by --sort-weight because it gets created after the image manipulations are done. The boot catalog of grub-mkrescue has no ISO-path anyway (no option -c). So in grub-mkrescue , this would give all files weight 0, then override the /boot/grub tree by 1, and the -b file by 2: --sort-weight 0 / \ --sort-weight 1 /boot/grub \ --sort-weight 2 /boot/grub/i386-pc/eltorito.img \ After the image is written, xorriso can display the data LBAs of regular files: xorriso \ -indev image.iso \ -find / -sort_lba -exec report_lba -- \ 2/dev/null | less yields: Report layout: xt , Startlba , Blocks , Filesize , ISO image path File data lba: 0 , 38 , 12 ,24317 , '/boot/grub/i386-pc/eltorito.img' File data lba: 0 , 50 ,6 ,10564 , '/boot/grub/i386-pc/acpi.mod' ... For the boot catalog LBA, one has to peek binary (even if there was a ISO-path leading to it). This reads the LBA word from El Torito record: dd if=image.iso bs=1 skip=34887 count=4 \ 2/dev/null | od -x yields LBA 37 (decimal) 000 0025 (There is a mkisofs option -sort with a file as argument where single files get a weight. Wildcards are promised in mkisofs/README.sort. For now i deem that rather unappealing.) I will now finish multi-session MBR handling and release libisoburn-0.5.4. Then begins the next development cycle with EFI, adjustable boot catalog weight, ... Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Hi, i have to correct myself: The boot catalog of grub-mkrescue has no ISO-path anyway (no option -c). There is a boot catalog path in grub-mkrescue. -c /boot/grub/i386-pc/boot_catalog Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Thomas Schmitt wrote: Hi, /usr/include/sys/cygwin.h:typedef unsigned long __uid32_t; So you need to use %lu or %lx on cygwin. Ahum. Although (int) would technically suffice and (unsigned long) would suffice for all known cases, i ponder whether i should use %.f, (double) ... double would make no sense. long long int would cover all the cases. Good news is that now warning is gone. I'm looking now into efi booting and (thanks Seth Goldberg for pointing to right doc and explaining it a bit) it's basically standard no-emul eltorito except: platform_id[0] = 0xef; No isolinux patching (could this one be disabled by default?) load_sectors should be set to the size of whole image instead of just 4 sectors (I think it should be the case for normal eltorito as well but since many BIOSes bug with 4 sectors it's not that important). Can we have a --efi-boot image option which will do this? On another note: can it be ensured that boot images and files boot/grub directory? I've come across a bug which seems to be triggered by images being after 2GiB mark on DVD. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Hi, Vladimir Serbinenko: efi booting [...] it's basically standard no-emul eltorito except: platform_id[0] = 0xef; I assume you mean the Platform ID as of El Torito specs about the Boot Catalog and its Validation Entry. (Chapter 2, figure 2) That should be easy to test. In libisofs/eltorito.c, there is a line ve-platform_id[0] = 0; /* 0: 80x86, 1: PowerPC, 2: Mac */ A bit more work will be to make this controllable by the libisofs API. No isolinux patching (could this one be disabled by default?) You mean mkisofs -boot-info-table ? (Code in libisofs/eltorito.c : int patch_boot_image(uint8_t *buf, Ecma119Image *t, size_t imgsize) ) Just yesterday i moved that setting from option -b to option -boot-info-table, which was a noop. So if you omit -boot-info-table then patching should be disabled. Before i release xorriso-0.5.4 i will make a (dummy) test. load_sectors should be set to the size of whole image instead of just 4 sectors You mean mkisofs -boot-load-size ? This is implemented in -as mkisofs emulation. For a test you may set it manually. Unit is 512 bytes. Default is 4. Can we have a --efi-boot image option which will do this? This shall then determine the -boot-load-size from the size of the image file ? Should be possible. But it seems more natural to state -b image --efi-boot in comparison to traditional -b image -boot-info-table Whatever, except the small hardcoded change in libisofs/eltorito.c the currently uploaded xorriso-0.5.3 with time stamp 2010.04.17.171232 should already be able to produce such an ISO image. If a missing option -boot-info-table causes problems, then i will solve them soon. Please make a test. I can only check by od, but have no idea how to prepare something that would really boot. On another note: can it be ensured that boot images and files boot/grub directory? I've come across a bug which seems to be triggered by images being after 2GiB mark on DVD. There seem words missing around directory. Do i get it right that you want the LBA of the boot catalog and the boot image to be as low as possible ? I will have to explore how i can achieve that. Today i released libisofs-0.6.30. It will be the fundament of libisoburn-0.5.4, which i plan to release in the next few days, together with GNU xorriso-0.5.4. Then we can urge distribution maintainers to update their packages. The API change for adjustable Platform ID would become part of libisofs-0.6.32 and xorriso-0.5.6. Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Thomas Schmitt wrote:
Hi,
Vladimir Serbinenko:
efi booting [...] it's basically standard no-emul
eltorito except:
platform_id[0] = 0xef;
I assume you mean the Platform ID as of El Torito
specs about the Boot Catalog and its Validation
Entry. (Chapter 2, figure 2)
That should be easy to test.
In libisofs/eltorito.c, there is a line
ve-platform_id[0] = 0; /* 0: 80x86, 1: PowerPC, 2: Mac */
Yes. I attach the patch I used for dirty checks
A bit more work will be to make this controllable
by the libisofs API.
This is exactly why I asked you: I'm not familiar with these internals.
No isolinux patching (could this one be disabled by default?)
You mean mkisofs -boot-info-table ?
(Code in libisofs/eltorito.c :
int patch_boot_image(uint8_t *buf, Ecma119Image *t, size_t imgsize)
)
Just yesterday i moved that setting from option
-b to option -boot-info-table, which was a noop.
So if you omit -boot-info-table then patching
should be disabled.
Thanks.
load_sectors should be set to the size of whole
image instead of just 4 sectors
You mean mkisofs -boot-load-size ?
This is implemented in -as mkisofs emulation.
For a test you may set it manually.
Unit is 512 bytes. Default is 4.
Why not to determine it from file size by default?
Can we have a --efi-boot image option which will do this?
This shall then determine the -boot-load-size
from the size of the image file ?
Yes
Should be possible.
But it seems more natural to state
-b image --efi-boot
in comparison to traditional
-b image -boot-info-table
The problem is that I would like to have efi+bios cd with 2 eltorito
entries: one with platformid=0 and another one with platformid=0xef. It
seems to me that it's unachievable with this syntax.
Whatever, except the small hardcoded change in
libisofs/eltorito.c
the currently uploaded xorriso-0.5.3 with time
stamp 2010.04.17.171232 should already be able
to produce such an ISO image.
If a missing option -boot-info-table causes
problems, then i will solve them soon.
Please make a test. I can only check by od,
but have no idea how to prepare something that
would really boot.
Ok, I'll test it later today.
On another note: can it be ensured that boot images and files boot/grub
directory? I've come across a bug which seems to be triggered by images
being after 2GiB mark on DVD.
There seem words missing around directory.
Do i get it right that you want the LBA of the
boot catalog and the boot image to be as low
as possible ?
Yes and also the offset to files from boot/grub and metadata to reach it
too.
I will have to explore how i can achieve that.
Today i released libisofs-0.6.30. It will be the
fundament of libisoburn-0.5.4, which i plan to
release in the next few days, together with GNU
xorriso-0.5.4.
Then we can urge distribution maintainers to
update their packages.
The API change for adjustable Platform ID would
become part of libisofs-0.6.32 and xorriso-0.5.6.
Ok
Have a nice day :)
Thomas
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
diff -ur xorriso-0.5.3/libisofs/eltorito.c xorriso-0.5.3-mod//libisofs/eltorito.c
--- xorriso-0.5.3/libisofs/eltorito.c 2010-04-13 18:16:58.0 +0200
+++ xorriso-0.5.3-mod//libisofs/eltorito.c 2010-04-17 16:00:42.452627715 +0200
@@ -552,7 +555,7 @@
struct el_torito_validation_entry *ve =
(struct el_torito_validation_entry*)buf;
ve-header_id[0] = 1;
-ve-platform_id[0] = 0; /* 0: 80x86, 1: PowerPC, 2: Mac */
+ve-platform_id[0] = 0xef; /* 0: 80x86, 1: PowerPC, 2: Mac */
ve-key_byte1[0] = 0x55;
ve-key_byte2[0] = 0xAA;
@@ -787,6 +790,8 @@
uint32_t checksum;
size_t offset;
+return ISO_SUCCESS;
+
if (imgsize 64) {
return iso_msg_submit(t-image-id, ISO_ISOLINUX_CANT_PATCH, 0,
Isolinux image too small. We won't patch it.);
--- xorriso-0.5.3/xorriso/xorriso.c 2010-04-13 18:16:58.0 +0200
+++ xorriso-0.5.3-mod//xorriso/xorriso.c 2010-04-17 15:25:22.649625656 +0200
@@ -4882,7 +4882,7 @@
m-boot_image_bin_form[0]= 0;
m-boot_image_emul= 0;
m-boot_image_cat_path[0]= 0;
- m-boot_image_load_size= 4 * 512; /* hearsay out of libisofs/demo/iso.c */
+ m-boot_image_load_size= 2880 * 2 * 512; /* hearsay out of libisofs/demo/iso.c */
#ifdef Xorriso_with_isohybriD
m-boot_image_isohybrid= 1;
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Hi, I attach the patch I used for dirty checks Oh. You already tested. And ? Did it boot ? Just yesterday i moved that setting from option -b to option -boot-info-table, Thanks. Even better: i now tested that omitting -boot-info-table really prevents the patcher function. Why not to determine it [-boot-load-size] from file size by default? Because mkisofs doesn't do that, afaik. One never knows what happens if one deviates from the old ways by default. (See Joliet and grub 1.96. I now go the old way by default. So grub-mkrescue 1.96 boots from CD.) The problem is that I would like to have efi+bios cd with 2 eltorito entries: one with platformid=0 and another one with platformid=0xef. Ahum. More than one boot table entry. Would they point to different boot images ? I.e would we have -b BIOS-image [-boot-info-table] --efi-boot EFI-image Is it possible to get an exact prescription, what info to write at which byte in the boot catalog ? I have a PDF: El Torito 1.0, January 25, 1995. Figure 1, Multiple Boot-Image Configuration seems to be what you intend. I will try to match this with the existing code in libisofs (by Vreixo Formoso). Do i get it right that you want the LBA [...] to be as low as possible ? Yes and also the offset to files from boot/grub and metadata to reach it I learned meanwhile that there is a feature weight in libisofs by which one can influence the sequence of the data LBAs. An IsoNode with high weight will get a low LBA. So this is merely a matter of suitable options in xorriso, by which one can put weight on files. Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Thomas Schmitt wrote: Hi, I attach the patch I used for dirty checks Oh. You already tested. And ? Did it boot ? Yes it booted in qemu-tianocore. Why not to determine it [-boot-load-size] from file size by default? Because mkisofs doesn't do that, afaik. One never knows what happens if one deviates from the old ways by default. Ok, legacy :(. But --efi-boot would have no legacy. (See Joliet and grub 1.96. I now go the old way by default. So grub-mkrescue 1.96 boots from CD.) It was a grub bug. The problem is that I would like to have efi+bios cd with 2 eltorito entries: one with platformid=0 and another one with platformid=0xef. Ahum. More than one boot table entry. Would they point to different boot images ? Yes I.e would we have -b BIOS-image [-boot-info-table] --efi-boot EFI-image Yes. Prototype is available at http://bzr.savannah.gnu.org/r/grub/people/phcoder/rescue-efi/ . Is it possible to get an exact prescription, what info to write at which byte in the boot catalog ? BIOS+EFI one should look like Validation entry with id = 0 Default entry (BIOS). I would like that on hybrid BIOS always come in default entry to avoid hitting BIOS bugs Section header entry: 0x91, 0xef, 0x0001, 0, ..., 0 Section entry: 0x88, 0x00, 0x, 0, 0, number of sectors in EFI boot image, LBA start, 0, ..., 0 In case of just EFI the Section header entry and Section entry become Validation entry and default entry. I have a PDF: El Torito 1.0, January 25, 1995. Figure 1, Multiple Boot-Image Configuration seems to be what you intend. I will try to match this with the existing code in libisofs (by Vreixo Formoso). Do i get it right that you want the LBA [...] to be as low as possible ? Yes and also the offset to files from boot/grub and metadata to reach it I learned meanwhile that there is a feature weight in libisofs by which one can influence the sequence of the data LBAs. An IsoNode with high weight will get a low LBA. So this is merely a matter of suitable options in xorriso, by which one can put weight on files. Nice Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Hi, many thanks for testing xorriso in new situations. 1) It tries to build even if no iconv is present The tests in configure.ac resp. acinclude.m4 are too lax, obviously. They aim for finding out whether one needs -liconv or not. But they don't assure that iconv() works. I will have to make experiments with a non-existing dummy function, as it seems impossible to disable iconv() on Linux. 2) I needed to explicitly add LIBS=-liconv to configure depstite configure properly detecting the need of -liconv. In some commands actually -liconv was double: one from configure and another from LIBS but somewhere it's not propagated properly This sounds a bit like a bug in autotools. But in the log you sent, i only find them in pairs. Obviously one from LIBS= and one from dnl GNU iconv has no function iconv() but libiconv() and a macro iconv() AC_CHECK_LIB(iconv, libiconv, , ) Are you sure that the lack of -liconv was not due to libiconv missing initially ? 3) A ton of warnings. The implementation of the isspace() family seems not to be liked by the compiler. Shrug. I found legitimate warnings about putting out uid_t and gid_t by printf formatter %d. (Question is whether (int) is a suitable cast in this case.) Then there is the intentional warning that no MMC system adapter is available for operating optical drives directly. libburn/sg.c:42: warning: unused variable INTENTIONAL_COMPILER_WARNING libburn/sg.c:39: warning: unused variable This_libburn_will_not_be_able_to_operate_on_real_CD_drives This does not hamper the GRUB use case. One will just need cdrecord for burning the CD, rather than letting xorriso do: xorriso -as cdrecord -v dev=... blank=as_needed my_grub.iso So mainly the LIBS=-liconv remains as build obstacle. I have changed the iconv detection code in configure.ac meanwhile (to care for the const ambiguity on FreeBSD). A new tarball http://www.gnu.org/software/xorriso/xorriso-0.5.3.tar.gz is uploaded. cat xorriso/xorriso_timestamp.h should say #define Xorriso_timestamP 2010.04.10.180103 or later. Could you please try it on cygwin without LIBS= (but libiconv installed) and send me the log of the failing compile run ? If nothing else helps then i plan to set LIBS=$LIBS -liconv in a special cygwin case in acinclude.m4. (Do you know a reliable test pattern for cygwin ? Like *-*-linux* for Linux.) For now the double -liconv options give me hope that it could work without that. Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Thomas Schmitt wrote: Hi, many thanks for testing xorriso in new situations. 1) It tries to build even if no iconv is present The tests in configure.ac resp. acinclude.m4 are too lax, obviously. They aim for finding out whether one needs -liconv or not. But they don't assure that iconv() works. I will have to make experiments with a non-existing dummy function, as it seems impossible to disable iconv() on Linux. I think what you should check for is iconv.h since this missing header caused compilation problem. Moreover it covers the case of libiconv w/o libiconv-devel. 2) I needed to explicitly add LIBS=-liconv to configure depstite configure properly detecting the need of -liconv. In some commands actually -liconv was double: one from configure and another from LIBS but somewhere it's not propagated properly This sounds a bit like a bug in autotools. But in the log you sent, i only find them in pairs. Obviously one from LIBS= and one from dnl GNU iconv has no function iconv() but libiconv() and a macro iconv() AC_CHECK_LIB(iconv, libiconv, , ) Are you sure that the lack of -liconv was not due to libiconv missing initially ? You're right it was some leftover in build directory. When I rebuild from clean untar it worked fine. 3) A ton of warnings. The implementation of the isspace() family seems not to be liked by the compiler. Shrug. I found legitimate warnings about putting out uid_t and gid_t by printf formatter %d. (Question is whether (int) is a suitable cast in this case.) /usr/include/sys/cygwin.h:typedef unsigned long __uid32_t; So you need to use %lu or %lx on cygwin. Then there is the intentional warning that no MMC system adapter is available for operating optical drives directly. libburn/sg.c:42: warning: unused variable INTENTIONAL_COMPILER_WARNING libburn/sg.c:39: warning: unused variable This_libburn_will_not_be_able_to_operate_on_real_CD_drives This does not hamper the GRUB use case. One will just need cdrecord for burning the CD, rather than letting xorriso do: xorriso -as cdrecord -v dev=... blank=as_needed my_grub.iso So mainly the LIBS=-liconv remains as build obstacle. I have changed the iconv detection code in configure.ac meanwhile (to care for the const ambiguity on FreeBSD). A new tarball http://www.gnu.org/software/xorriso/xorriso-0.5.3.tar.gz is uploaded. cat xorriso/xorriso_timestamp.h should say #define Xorriso_timestamP 2010.04.10.180103 or later. Could you please try it on cygwin without LIBS= (but libiconv installed) and send me the log of the failing compile run ? I've tested with previous tarball. I'll retest on both systems with new one. If nothing else helps then i plan to set LIBS=$LIBS -liconv in a special cygwin case in acinclude.m4. (Do you know a reliable test pattern for cygwin ? Like *-*-linux* for Linux.) For now the double -liconv options give me hope that it could work without that. Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Hi, I think what you should check for is iconv.h since this missing header caused compilation problem. I have become quite radical and make a test compilation and linking of all *.h in libisofs/util.c and the basic iconv functions. If that fails, then ./configure aborts after reporting. The first three tests shall find out how to get it to work: checking for iconv() in separate -liconv ... no checking for libiconv in -liconv... no checking for const qualifier with iconv() ... const Then i insist in having it: checking for iconv() to be accessible now ... no Cannot get function iconv() to work. Configuration aborted. Check whether your system needs a separate libiconv installed. If it is installed but not found, try something like export LDFLAGS=$LDFLAGS -L/usr/local/lib export CPPFLAGS=$CPPFLAGS -I/usr/local/include export LIBS=$LIBS -liconv You may override this test by exporting variable XORRISO_ASSUME_ICONV=yes You're right it [LIBS=-liconv] was some leftover in build directory. When I rebuild from clean untar it worked fine. Whew. Broken autotools would be a drag. /usr/include/sys/cygwin.h:typedef unsigned long __uid32_t; So you need to use %lu or %lx on cygwin. Ahum. Although (int) would technically suffice and (unsigned long) would suffice for all known cases, i ponder whether i should use %.f, (double) ... The purpose is just to tell the user that different UID or GID was found when comparing files. I've tested with previous tarball. I'll retest on both systems with new one. I uploaded the next one meanwhile 2010.04.11.122253 with the new test for accessible iconv() and (int) conversion of uid,gid. Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
On Sun, Apr 11, 2010 at 02:56:37PM +0200, Thomas Schmitt wrote: /usr/include/sys/cygwin.h:typedef unsigned long __uid32_t; So you need to use %lu or %lx on cygwin. Ahum. Although (int) would technically suffice and (unsigned long) would suffice for all known cases, i ponder whether i should use %.f, (double) ... C99 has uintmax_t and %ju. If you don't want to rely on C99, unsigned long long and %llu would probably be best. I wouldn't use FP for this. -- Colin Watson [cjwat...@ubuntu.com] ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Hi, me: What about operating systems other than GNU/Linux and FreeBSD ? Seth Goldberg: I agree, selfishly :). Do you use some of the other OSes ? If so, would you mind to try what happens if you do tar xzf xorriso-0.5.3.tar.gz cd xorriso-0.5.3 ./configure make xorriso/xorriso -version The build system is autotools based. It should suffice for most systems. It does compile on all Debian buildd targets and it did on Solaris a year ago. Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Thomas Schmitt wrote: Hi, me: What about operating systems other than GNU/Linux and FreeBSD ? I've tested it on FreeBSD and grub-mkrescue worked fine with xorrisofs except: 1) you need to use gmake instead of make 2) libisofs/util.c: In function 'iso_iconv': libisofs/util.c:116: warning: passing argument 2 of 'libiconv' from incompatible pointer type Changing #define ICONV_CONST to #define ICONV_CONST const fixed this warning -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Hi, I've tested it on FreeBSD and grub-mkrescue worked fine with xorrisofs except: 1) you need to use gmake instead of make What FreeBSD version is this ? I test building of xorriso on own FreeBSD 8 and remotely on FreeBSD 6. My own ones are quite vanilla. Especially the 8-STABLE. Do you have a proposal how i could care for this by configure.ac ? libisofs/util.c:116: warning: passing argument 2 of 'libiconv' from incompatible pointer type #define ICONV_CONST const Directly in libisofs/util.c ? (Or somewhere else in the autotools jungle ?) I know the complaint. It is harmless. There is code in acinclude.m4 for that. But obviously i forgot to use it in configure.ac. I will check whether i can get that to work. Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Thomas Schmitt wrote: Hi, I've tested it on FreeBSD and grub-mkrescue worked fine with xorrisofs except: 1) you need to use gmake instead of make What FreeBSD version is this ? 8.0 I test building of xorriso on own FreeBSD 8 and remotely on FreeBSD 6. My own ones are quite vanilla. Especially the 8-STABLE. Do you have a proposal how i could care for this by configure.ac ? It's not anything in source, just the instructions. It's: ./configure gmake instead of ./configure make source is fine libisofs/util.c:116: warning: passing argument 2 of 'libiconv' from incompatible pointer type #define ICONV_CONST const Directly in libisofs/util.c ? (Or somewhere else in the autotools jungle ?) I tested it with a change directly. I know the complaint. It is harmless. I know, just wanted to make sure you're aware about this. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Hi, What FreeBSD version is this ? 8.0 ./configure gmake instead of ./configure make Strange. I run 8-RELEASE and 8-STABLE because of SATA differences. No problems with make. What are the negative symptoms on your system ? I know the [iconv] complaint. It is harmless. I know, just wanted to make sure you're aware about this. You made me find that M4 function which i once copied and prepared but never used. Now i will try whether it does something useful. (Then i will ponder whether it is worth the risk to break anything in ./configure.) Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Thomas Schmitt wrote: Hi, Strange. I run 8-RELEASE and 8-STABLE because of SATA differences. No problems with make. What are the negative symptoms on your system ? Actually I've just checked and make worked too. Just I'm accustomed to use GNU make (gmake) with all GNU programs which avoids bunch of issues -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
A first tarball is available with the necessary program enhancements: http://www.gnu.org/software/xorriso/xorriso-0.5.3.tar.gz For overall info see http://www.gnu.org/software/xorriso/xorriso_eng.html Build: ./configure ; make Installation is not mandatory. One may use it by the absolute path of ./xorriso/xorriso . E.g.: prog=/home/thomas/xorriso-0.5.3/xorriso/xorriso -as mkisofs -no-emul-boot -no-pad There is still no support for option --modification-date= and option -r is still ignored. (I will implement reasonable Rock Ridge soon. Although it is an odd thing.) I've tested and fixed few issues pointed out here earlier (missing -no-emul-boot, bug in grub-mkrescue). Now it's enough to replace grub-mkisofs with xorrisofs. Do you know when debian will follow? When this version is in Debian sid I plan to remove grub-mkisofs Is it worth to sacrifice multi-session history capabilities in order to save 64 kB ? Perhaps as an option, not as default. It turned out that writing to a recognizable random-access file or block device brings an overhead of 64 kB to 126 kB. Normally not a problem with contemporary media. But if floppies are of interest ... Unfortunately floppies are of interest. Moreover our modules put together result in 1146880 bytes tar file. Perhaps we should use some kind of tar.xz for floppies and not try to squeeze iso. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Hi,
Now it's enough to replace grub-mkisofs with xorrisofs.
What about operating systems other than GNU/Linux
and FreeBSD ?
I have running a version of grub-mkrescue which
can deal with grub-mkisofs, genisoimage, and
xorriso. (genisoimage without
--protective-msdos-label and --modification-date)
Maybe it would offer a softer migration path
than flatly urging people to port xorrisofs to
their favorite exotic OS.
Of course i would gladly support any porting
effort, which should be easy as long as one does
not want to use it for burning optical media.
Do you know when debian will follow? When
this version is in Debian sid I plan to remove grub-mkisofs
I informed George Danchev about our progress
today. Like so many people he is very occupied
currently.
In charge are the Debian Libburnia packagers.
See
http://packages.qa.debian.org/libi/libisofs.html
Since Debian covers our dynamic compilations
i will first have to release a new
libisofs-0.6.30 and a new libisoburn-0.5.4.
That should be possible in the next days.
I just have to do some more tests.
Maybe one could try to find testers for
GNU xorriso-0.5.3 on some of the other OSes in
the meantime ?
Unfortunately floppies are of interest. Moreover our modules put
together result in 1146880 bytes tar file.
Then you should in any case let xorrisofs
write into a sequential pipe
| cat ${output_image}
rather than into a random access file
-o ${output_image}
(or ${output_image} without cat)
in order to save the overhead of 64 to 126 kB.
Would read support for zisofs be in your reach ?
It is implemented in the Linux kernel iso9660
code since a while. See CONFIG_ZISOFS in
fs/isofs/*.[ch]
If zlib is provided, then xorriso can produce
zisofs on-the-fly on normal input file trees.
No need to run the mkzftree utility.
(But it can recognize and use the mkzftree
prepared files too.)
The mkisofs emulation cannot do the on-the-fly
stunt, yet. So this has to look a bit ugly:
${mkisofs_prog} ...
${source} \
-- -set_filter_r --zisofs / -- \
| cat ${output_image}
But the result has only 884736 bytes.
We would have to keep some modules uncompressed
i assume.
It can also produce gzipped files on the fly:
${mkisofs_prog} ...
${source} \
-- -set_filter_r --gzip / -- \
| cat ${output_image}
Result again has 884736 bytes. Files have suffix
.gz now. Small files may stay uncompressed:
$ ls -l /mnt/boot/grub/i386-pc
...
-r--r--r-- 1 root root 2675 2010-04-10 00:17 afs.mod.gz
-r--r--r-- 1 root root 1052 2010-04-10 00:17 aout.mod
...
One could of course apply mkzftree or gzip to
the temporary tree during the grub-mkrescue run.
Have a nice day :)
Thomas
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Quoting Thomas Schmitt, who wrote the following on Sat, 10 Apr 2010: Hi, Now it's enough to replace grub-mkisofs with xorrisofs. What about operating systems other than GNU/Linux and FreeBSD ? I agree, selfishly :). How about a configure-time test to check for and use xorriso if it's available, otherwise a fallback to mkisofs, which is much more ubiquitous. --S ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Thomas Schmitt wrote: Hi, i have roughly implemented the missing options of grub-mkisofs in xorriso and am now comparing the results. The ISO image by xorriso boots from CD and from USB stick. Are there other media types which would impose a further challenge ? Floppy. (supported for image sizes smaller than 1.44 MiB) If so: are there testers who would be willing to try my ISO image (1.9 MB) on such media ? It seems that grub-mkisofs does not comply much to the partition table prescription given by Vladimir. Yes, grub-mkisofs code is a stub. What I described is a correct table The image made by grub-mkisofs has 1550336 bytes = 757 * 2048 , 3028 * 512. It bears as partition table: 6600080 700 00cd 0001 720 * 760 aa55 (od -x regrettably produces big-endian 16 bit. One has to swap: 00cd is actually cd 00 .) The xorriso image is currently a bit larger (see below). 1966080 bytes = 960 * 2048 , 3840 * 2048 xorriso -toc reports: ISO session : 1 ,32 , 754s , ISOIMAGE Partition table: Image size is 32 + 754 = 786 * 2048 = 3144 * 512 = 0x0C48 I insert 0x0C47 as end LBA (= 0c47 ). End C/H/S is c0,h49,s57 (= 31xx 0039). 6600080 700 0002 31cd 0039 0001 0c47 720 * 760 aa55 Vladimir: does that look ok for you ? Is 0x0C47 correct to depict image size 0x0C48 ? Yes Is my C/H/S computation ok ? It looks fine - xorriso produces a larger image because of 64 kB multi-session preparations, of 300 kB end padding and of padding to full 32 kB blocks. Most of this overhead can already be prevented. I will see whether i can strip the output to its net size of 754 sectors. Nevertheless, neither the image of grub-mkisofs nor of xorriso fit on a vanilla floppy disk. We probably need a way to choose a subset of modules for floppies Is it worth to sacrifice multi-session history capabilities in order to save 64 kB ? (If i do not duplicate the ISO superblock then i cannot mount older sessions of a multi-session ISO image.) Perhaps as an option, not as default. Compatibility question: Is the help text of grub-mkisofs --protective-msdos-labelPatch a protective DOS-style label in the image essential to any frontend of grub-mkisofs ? I would prefer to print something more neutral. Like: --protective-msdos-labelPatch System Area by partition table Any DOS connotation should be obvious by the option name already. msdos is the name of this partition label - Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Hi,
Are there other media types [...] ?
Floppy. (supported for image sizes smaller than 1.44 MiB)
[...]
We probably need a way to choose a subset of modules for floppies
If i squeeze out the overhead, then xorriso
writes 754 * 2048 bytes rather than 757 * 2048
by grub-mkisofs.
At the end of grub-mkrescue i have now:
## prog=grub-mkisofs
prog=xorriso -as mkisofs -no-emul-boot -no-pad
# This creates an image without multi-session/Blu-ray overhead
# by hiding the random access capability of the target file.
$prog ${grub_mkisofs_arguments} --protective-msdos-label -r ${iso9660_dir}
${source} | cat ${output_image}
(Possibly the 3 blocks difference comes from
obsolete RockRidge RR entries written by
mkisofs.)
A first tarball is available with the necessary
program enhancements:
http://www.gnu.org/software/xorriso/xorriso-0.5.3.tar.gz
For overall info see
http://www.gnu.org/software/xorriso/xorriso_eng.html
Build:
./configure ; make
Installation is not mandatory. One may use it
by the absolute path of ./xorriso/xorriso .
E.g.:
prog=/home/thomas/xorriso-0.5.3/xorriso/xorriso -as mkisofs -no-emul-boot
-no-pad
There is still no support for option
--modification-date=
and option -r is still ignored.
(I will implement reasonable Rock Ridge soon.
Although it is an odd thing.)
Is it worth to sacrifice multi-session history
capabilities in order to save 64 kB ?
Perhaps as an option, not as default.
It turned out that writing to a recognizable
random-access file or block device brings an
overhead of 64 kB to 126 kB.
Normally not a problem with contemporary media.
But if floppies are of interest ...
Have a nice day :)
Thomas
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Hi, i have roughly implemented the missing options of grub-mkisofs in xorriso and am now comparing the results. The ISO image by xorriso boots from CD and from USB stick. Are there other media types which would impose a further challenge ? If so: are there testers who would be willing to try my ISO image (1.9 MB) on such media ? It seems that grub-mkisofs does not comply much to the partition table prescription given by Vladimir. The image made by grub-mkisofs has 1550336 bytes = 757 * 2048 , 3028 * 512. It bears as partition table: 6600080 700 00cd 0001 720 * 760 aa55 (od -x regrettably produces big-endian 16 bit. One has to swap: 00cd is actually cd 00 .) The xorriso image is currently a bit larger (see below). 1966080 bytes = 960 * 2048 , 3840 * 2048 xorriso -toc reports: ISO session : 1 ,32 , 754s , ISOIMAGE Partition table: Image size is 32 + 754 = 786 * 2048 = 3144 * 512 = 0x0C48 I insert 0x0C47 as end LBA (= 0c47 ). End C/H/S is c0,h49,s57 (= 31xx 0039). 6600080 700 0002 31cd 0039 0001 0c47 720 * 760 aa55 Vladimir: does that look ok for you ? Is 0x0C47 correct to depict image size 0x0C48 ? Is my C/H/S computation ok ? (I understand Wikipedia that way, but am not sure.) - xorriso produces a larger image because of 64 kB multi-session preparations, of 300 kB end padding and of padding to full 32 kB blocks. Most of this overhead can already be prevented. I will see whether i can strip the output to its net size of 754 sectors. Nevertheless, neither the image of grub-mkisofs nor of xorriso fit on a vanilla floppy disk. Is it worth to sacrifice multi-session history capabilities in order to save 64 kB ? (If i do not duplicate the ISO superblock then i cannot mount older sessions of a multi-session ISO image.) Compatibility question: Is the help text of grub-mkisofs --protective-msdos-labelPatch a protective DOS-style label in the image essential to any frontend of grub-mkisofs ? I would prefer to print something more neutral. Like: --protective-msdos-labelPatch System Area by partition table Any DOS connotation should be obvious by the option name already. - Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Hi, The urge to upgrade might earn you a whining user. Well, if you develop you have to use current version (IMO). Sure. As long as i occupy your time i will follow your proposals. Nevertheless, at some point i will have to look at older versions. After all, 1.96 is distributed with the current Debian release. Hopefully i will know enough then to help myself on the first hand. Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Thomas Schmitt wrote: Hi, The urge to upgrade might earn you a whining user. Well, if you develop you have to use current version (IMO). Sure. As long as i occupy your time i will follow your proposals. Nevertheless, at some point i will have to look at older versions. After all, 1.96 is distributed with the current Debian release. Hopefully i will know enough then to help myself on the first hand. The point is basically that even if you release 1.96 support right now it won't make it into distributions before GRUB 1.98 does. Additionally you must be aware that we don't accept bug reports for 1.96 anymore (and it had enough of bugs). So I would like to ask not to make this support. At very least it will save you and me few bug reports for version we don't support. Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Hi, Drake Donahue wrote: mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table -o grub.iso iso run the script it generates the image, presuming on a linux system Regrettably i cannot spot stage2_eltorito on my SuSE 10.2 (which has such files but not eltorito) or on Debian 5.04 (where the GRUB installation has files like cdboot.img). The Debian system (where i am novice too) does have /usr/bin/grub-mkrescue which has the line PACKAGE_VERSION=1.96 It uses genisoimage and no --embedded-boot for a MBR-style image. So my plan for development looks like this: - Use grub-mkrescue on Debian to produce a bootable CD. - Examine it and check whether libisofs can produce the same. Make necessary enhancements. - Substitute genisoimage in grub-mkrescue by xorriso and produce bootable CD. - Upgrade Debian to GRUB 1.98 and try to produce an image that boots from USB stick and from CD. This may last a few days. I have to dive into libisofs and check where we might be glued to ISOLINUX, inadvertedly. I will have to learn about GRUB installation and might need to cry for help. When i can perform grub-mkrescue gestures, then i plan to enable hard-disk emulation so that others (Vladimir ?) can test that. Vladimir wrote about HFS: I have an imac g3 I could test it on. The only catch is that I have no burner at home. But it should be manageable. I never looked deeply into HFS but I think I can do it. If you have the time, then try to find specs for HFS and make a sketch how a HFS tree would be structured. I would then prepare hooks in libisofs where a HFS tree can be generated and inserted into the emerging ISO image. Then we could put our knowledge together for the HFS tree generator. libisofs holds a tree model of nodes, from which the image trees get derived. Ideally, i would have made any needed preparations in the tree model, and you would know how to express it in HFS. This is of course a long term open ended endeavor. --protective-msdos-label 3) Put 0x80 (for bootable partition), 0, 2, 0 (C/H/S of the start), 0xcd (partition type), [3 bytes of C/H/S end], 0x01, 0x00, 0x00, 0x00 (LBA start in little endian), [LBA end in little endian] at 446-462 What number of sectors/head and heads/cylinder to use ? 32 sectors = 1 head, 64 heads = 1 cylinder would limit C/H/S size to 1 GB, due to the 10 bit limit of cylinder count. The partition table format would allow 63 (or 64 ?) sectors, 255 (or 256 ?) heads = ~ 8 GB. (isohybrid happily truncates C/H/S size to 1 GB and expresses the real size in LBA end.) me: --protective-msdos-label without --embedded-boot ?) Vladimir: Yes, for example to allow people dd images to USB sticks without a fear of another OS willing to format the stick. So OSes would pop up dangerous dialogs if they see a USB stick without partition table ? I would then have to write all zeros except the one slot in the partition table ? Curiosity to fill my lack of MBR knowledge: How does 0x01, 0x00, 0x00, 0x00 (LBA start match with 0, 2, 0 (C/H/S of the start) ? I see in isohybrid a similar addition of 1 to start sector. So it is obviously correct. But why ? Isn't there any field where the number of sectors per head, and heads per cylinder is recorded ? Is there a convention to express this in C/H/S end ? isohybrid seems to do so: heads-1 , sectors | high(cyls-1) , low(cyls-1) This gives in the sum the number of cyls. One could express that easier. Purpose could be to squeeze in the 1024th cylinder or to express heads/cyl and sectors/head. Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Thomas Schmitt wrote: Hi, Drake Donahue wrote: mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table -o grub.iso iso run the script it generates the image, presuming on a linux system Regrettably i cannot spot stage2_eltorito on my SuSE 10.2 (which has such files but not eltorito) or on Debian 5.04 (where the GRUB installation has files like cdboot.img). stage2_eltorito is grub legacy. Please disregard this part The Debian system (where i am novice too) does have /usr/bin/grub-mkrescue which has the line PACKAGE_VERSION=1.96 It uses genisoimage and no --embedded-boot for a MBR-style image. 1.96 is way too old. Please disregard. So my plan for development looks like this: - Use grub-mkrescue on Debian to produce a bootable CD. - Examine it and check whether libisofs can produce the same. Make necessary enhancements. - Substitute genisoimage in grub-mkrescue by xorriso and produce bootable CD. - Upgrade Debian to GRUB 1.98 and try to produce an image that boots from USB stick and from CD. From 1.96 to 1.98 grub-mkrescue was essentially rewritten. Supporting 1.96 (buggy, years old release) is basically a waste of time. Please use either http://alpha.gnu.org/gnu/grub/grub-1.98.tar.gz or bzr checkout from http://bzr.savannah.gnu.org/r/grub/trunk/grub/. This may last a few days. I have to dive into libisofs and check where we might be glued to ISOLINUX, inadvertedly. I will have to learn about GRUB installation and might need to cry for help. Feel free to ask. But please use current versions. When i can perform grub-mkrescue gestures, then i plan to enable hard-disk emulation so that others (Vladimir ?) can test that. It must be choseable whether to use emulation. By default no emulation should be used (recent BIOSes have problems with emulation). Vladimir wrote about HFS: I have an imac g3 I could test it on. The only catch is that I have no burner at home. But it should be manageable. I never looked deeply into HFS but I think I can do it. If you have the time, then try to find specs for HFS http://developer.apple.com/legacy/mac/library/documentation/mac/Files/Files-2.html and make a sketch how a HFS tree would be structured. Bad news are that it needs B* trees and isn't compatible with embedded boot trick. B* trees should be relatively easy to generate since we have to do it only once and not maintain their structure over time. I would then prepare hooks in libisofs where a HFS tree can be generated and inserted into the emerging ISO image. Then we could put our knowledge together for the HFS tree generator. libisofs holds a tree model of nodes, from which the image trees get derived. Ideally, i would have made any needed preparations in the tree model, and you would know how to express it in HFS. Just being sorted is mostly enough. Trouble is that HFS uses its own way of sorting. --protective-msdos-label 3) Put 0x80 (for bootable partition), 0, 2, 0 (C/H/S of the start), 0xcd (partition type), [3 bytes of C/H/S end], 0x01, 0x00, 0x00, 0x00 (LBA start in little endian), [LBA end in little endian] at 446-462 What number of sectors/head and heads/cylinder to use ? 63/255 as its what is reported on most harddisks. Most modern tools will ignore this field altogether so putting just anything sane is enough me: --protective-msdos-label without --embedded-boot ?) Vladimir: Yes, for example to allow people dd images to USB sticks without a fear of another OS willing to format the stick. So OSes would pop up dangerous dialogs if they see a USB stick without partition table ? I think they would, especially if they find no FS they expect to (fat). I would then have to write all zeros except the one slot in the partition table ? Basically you need a fake partition to avoid disk appear as unformatted Curiosity to fill my lack of MBR knowledge: How does 0x01, 0x00, 0x00, 0x00 (LBA start match with 0, 2, 0 (C/H/S of the start) ? I see in isohybrid a similar addition of 1 to start sector. So it is obviously correct. But why ? Because sector value is 1-based. Isn't there any field where the number of sectors per head, and heads per cylinder is recorded ? No. In times when it was a hard property of disk it was deemed unnecessary. When big disks appeared C/H/S was largely abandoned. Is there a convention to express this in C/H/S end ? isohybrid seems to do so: heads-1 , sectors | high(cyls-1) , low(cyls-1) This gives in the sum the number of cyls. One could express that easier. Purpose could be to squeeze in the 1024th cylinder or to express heads/cyl and sectors/head. /* The head of the start. */ grub_uint8_t start_head; /* (S | ((C 2) 0xC0)) where S is the sector of the start and C is the
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Thomas Schmitt wrote: Feel free to ask. But please use current versions. The urge to upgrade might earn you a whining user. Well, if you develop you have to use current version (IMO). I will backup the 31.5 kB of pre-partition space and the Debian partition. So hopefully i can always roll back. If you do it with dd then yes. http://developer.apple.com/legacy/mac/library/documentation/mac/Files/Files-2.html The interesting part seems to begin at http://developer.apple.com/legacy/mac/library/documentation/mac/Files/Files-99.html (I hate that Legacy Document overlay) Bad news are that it needs B* trees Do i find that in Knuth's The Art of Computer Programming ? Yep. Volume 3, page 474 looks very similar. Brand new art of the 1970s. :)) I can't find my copy of Knuth's books. But wikipedia should be enough. and isn't compatible with embedded boot trick. Because of the Master Directory Block at block 3 and because the Partition Map at block 0 is not compatible with a PC MBR ? Actually for CD to be macppc-bootable it has to have an apple partition map (at least all hybrid disks I've seen so far followed this convention). It will go into 16 sector space and we can put real start of HFS at any point we like Just being sorted is mostly enough. Trouble is that HFS uses its own way of sorting. We will have to learn how to express our file objects as Node Records. And how do the tree keys map to a hierarchical file naming system with directories ? I don't know yet but grub already has read-only hfs implementation. I think it can be upgraded to use for creating hfs. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Your question is how to make a cd with grub on it ? Or a way to boot an
iso from grub ?
If it's the second question, I made this page for the ubuntu doc in
French :
http://doc.ubuntu-fr.org/tutoriel/grub2_lancer_des_images_iso#versions_karmic
With an entry for Ubuntu (for an iso located in an iso folder on
/dev/sda5) like that :
menuentry ISO Live - Ubuntu 9.10 Karmic AMD64 {
insmod loopback
insmod iso9660
set isofile=/iso/lucid-desktop-amd64.iso
loopback loop (hd0,5)$isofile
linux (loop)/casper/vmlinuz locale=de_DE bootkbd=de console-setup/layoutcode=de
iso-scan/filename=$isofile boot=casper file=/cdrom/preseed/ubuntu.seed noprompt
quiet splash --
initrd (loop)/casper/initrd.lz
}
Just change the line set isofile= to your version of ubuntu iso.
Benoit
Le 01/04/2010 15:49, Thomas Schmitt a écrit :
Hi,
i would like to learn how GNU xorriso can make
use of GRUB.
Are there any specs available, or an example
of a GRUB enhanced ISO 9660 image that boots
from CD on PC BIOSes ?
I know about ECMA-119 (ISO 9660) and El Torito
CD booting specs, but few about GRUB.
In january 2010 Robert Millan announced
GNU isofsmk. In the course of the following
discussions he 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
I did this with isofsmk-1.13 and a dummy file
tmp (not boot.img+core.img) in the hope to
learn what kind of El Torito record gets
produced. But i cannot spot any.
mkisofs just copied tmp to the System Area in
block 0 to 15 of the ISO image.
So i would need a more realistic test setup
or some explanations.
Any help with a quick start is appreciated.
Have a nice day :)
Thomas
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Hi, i would like to learn how GNU xorriso can make use of GRUB. Are there any specs available, or an example of a GRUB enhanced ISO 9660 image that boots from CD on PC BIOSes ? =20 GRUB2 iso generated with grub-mkrescue is a bit special: it can be boot as either CD, HDD or floppy. For CD boot it follows El Torito no emulation boot. For booting from HDD or floppy it adds bootcode into begining of iso image. I think you fond only the second part and missed the first part I know about ECMA-119 (ISO 9660) and El Torito CD booting specs, but few about GRUB. In january 2010 Robert Millan announced GNU isofsmk. In the course of the following discussions he wrote: =20 Robert is unavailable right now but I'll happily discuss GRUB and xorriso collaboration. Would you mind joining our IRC channel? --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
On Thu, 2010-04-01 at 19:59 +0200, Thomas Schmitt wrote:
Hi,
Your question is how to make a cd with grub on it ?
Yes.
GNU xorriso is like cdrtools + growisofs in
one single binary.
My question about GRUB on CD shall improve the
mkisofs-like aspect of xorriso. I am able to
influence ISO image production in any detail.
But i need instructions how to prepare it so
that a PC BIOS starts GRUB correctly.
I expect a BIOS to ignore the first 16 blocks
of a CD unless an El Torito record points to
an address in there.
Robert Millan's example
cat boot.img core.img tmp
mkisofs --embedded-boot tmp -o grub.iso -r somedir
places GRUB files into those 16 blocks.
But it does not produce an El Torito record
when run with his latest mkisofs and a dummy
file tmp.
So either his mkisofs wants to see real GRUB
files or my theory about BIOS + CD + GRUB is
wrong.
menuentry ISO Live - Ubuntu 9.10 Karmic AMD64 {
insmod loopback
insmod iso9660
set isofile=/iso/lucid-desktop-amd64.iso
Interesting example. It is astounding what one
can do with a bootloader nowadays.
It would be in my current focus of interest,
if that ISO image itself is equipped with
GRUB and boots from real CD. In that case i
would like to know an URL for downloading it.
Have a nice day :)
Thomas
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Attached is a script I use to make a legacy grub booting cd that
provides an alternate way to boot the system it was built on.
mkdir iso
#mkdir -p iso/boot/grub
cp -rf /boot/ iso/boot/
rm iso/boot/grub/menu.lst
cp iso/boot/grub/grub.conf iso/boot/grub/menu.lst
rm iso/boot/grub/grub.conf*
mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4
-boot-info-table -o grub.iso iso
#genisoimage -R -b boot/grub/stage2_eltorito \ -input-charset iso8859-1 \ -V
iso \ -no-emul-boot \ -boot-load-size 4 -boot-info-table -o grub.iso iso
#This produces a file named grub.iso, which then can be burned into a CD (or a
DVD). mkisofs has already set up the disc to boot from the
boot/grub/stage2_eltorito file, so there is no need to setup GRUB on the disc.
(Note that the -boot-load-size 4 bit is required for compatibility with the
BIOS on many older machines.)
Y#ou can use the device `(cd)' to access a CD-ROM in your config file. This is
not required; GRUB automatically sets the root device to `(cd)' when booted
from a CD-ROM. It is only necessary to refer to `(cd)' if you want to access
other drives as well.
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Hi,
GRUB2 iso generated with grub-mkrescue is a bit special: it can be boot
as either CD, HDD or floppy. For CD boot it follows El Torito no
emulation boot.
Ahum ... grub-1.98/util/grub-mkrescue.in :
iso_uuid=$(date +%Y-%m-%d-%H-%M-%S-00)
grub_mkisofs_arguments=${grub_mkisofs_arguments} --modification-date=$(echo
${iso_uuid} | sed -e s/-//g)
[...]
grub_mkisofs_arguments=${grub_mkisofs_arguments} -b
boot/grub/i386-pc/eltorito.img -boot-info-table \
--embedded-boot ${embed_img}
[...]
grub-mkisofs ${grub_mkisofs_arguments} --protective-msdos-label -o
${output_image} -r ${iso9660_dir} ${source}
Do i get it right that there are two
boot files:
- eltorito.img for CD
- ${embed_img} for MBR style booting
I don't see the -no-emul-boot option, though.
Are you sure it is effectively used ?
man mkisofs says -b is by default floppy
emulation.
For comparison, this is the official ISOLINUX
production gesture which already works
with xorriso:
mkisofs -o output.iso \
-b isolinux/isolinux.bin -c isolinux/boot.cat \
-no-emul-boot -boot-load-size 4 -boot-info-table \
root-of-iso-tree
So if there is indeed a -no-emul-boot option in
grub-mkrescue then it seems to be mainly about
implementing option --embedded-boot combinable
with the El Torito option -b.
These seem to be Robert's novelties:
--modification-date Override modification date
Probably ECMA-119, 8.4.27,
Volume Modification Date and Time
(BP 831 to 847 of Primary Volume Descriptor)
--protective-msdos-labelPatch a protective DOS-style label in the image
What is this ?
How does it look and at what address
to write it ?
I'll happily discuss GRUB and
xorriso collaboration. Would you mind joining our IRC channel?
I would prefer e-mail. Public or private.
It's so nicely asynchronous.
Have a nice day :)
Thomas
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Hi, Drake Donahue wrote: Attached is a script I use to make a legacy grub booting cd that provides an alternate way to boot the system it was built on. [...] mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table -o grub.iso iso This resembles a reply of Joerg Schilling to the example given by Robert Millan. Joerg wrote January 10 on cdwr...@other.debian.org mailing list: mkisofs -V $volid -o xxx.iso -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table somedir Is that GRUB2 or GRUB-Legacy ? (I'd like to support both. But GRUB2 is of course first goal.) Well, i see the same options as with ISOLINUX. So this gesture should already be possible by xorriso: xorriso -as mkisofs ...above.options... Is there by chance a resulting image available which i could test and examine ? (The smaller the better. Booting up to a GRUB menu would suffice.) Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Thomas Schmitt wrote:
Hi,
Do i get it right that there are two
boot files:
- eltorito.img for CD
- ${embed_img} for MBR style booting
Yes
I don't see the -no-emul-boot option, though.
Are you sure it is effectively used ?
In grub-mkisofs:
{ {no-emul-boot, no_argument, NULL, OPTION_NO_EMUL_BOOT },
'\0', NULL, N_(Dummy option for backward compatibility), ONE_DASH },
{ {eltorito-emul-floppy, no_argument, NULL,
OPTION_ELTORITO_EMUL_FLOPPY },
'\0', NULL, N_(Enable floppy drive emulation for El Torito),
TWO_DASHES },
So basically the default is reversed. We can add --no-emul-boot to
grub-mkrescue though
So if there is indeed a -no-emul-boot option in
grub-mkrescue then it seems to be mainly about
implementing option --embedded-boot combinable
with the El Torito option -b.
Mainly.
Although there are few other things we would like to be possible in future:
- Is it possible to declare the whole iso for hard-disk emulation for
providing emulating image for buggy BIOSes
- Is it possible to have HFS support in xorriso? It would allow merging
PPC grub-mkrescue into generic one.
These seem to be Robert's novelties:
--modification-date Override modification date
Probably ECMA-119, 8.4.27,
Volume Modification Date and Time
(BP 831 to 847 of Primary Volume Descriptor)
Yes, this is needed to know the creation date (which is use as disk
identifier in GRUB) before image is complete.
--protective-msdos-labelPatch a protective DOS-style label in the image
What is this ?
How does it look and at what address
to write it ?
This one adds a simple partition table spanning across whole image of
type 0xCD
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Thomas Schmitt wrote: mkisofs -V $volid -o xxx.iso -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table somedir Is that GRUB2 or GRUB-Legacy ? (I'd like to support both. But GRUB2 is of course first goal.) GRUB Legacy isn't developed anymore. As a matter of fact we don't even support it anymore. GRUB Legacy is off-topic on this list in most cases. -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
On Thu, 2010-04-01 at 22:43 +0200, Thomas Schmitt wrote: Hi, Drake Donahue wrote: Attached is a script I use to make a legacy grub booting cd that provides an alternate way to boot the system it was built on. [...] mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table -o grub.iso iso This resembles a reply of Joerg Schilling to the example given by Robert Millan. Joerg wrote January 10 on cdwr...@other.debian.org mailing list: mkisofs -V $volid -o xxx.iso -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table somedir Is that GRUB2 or GRUB-Legacy ? (I'd like to support both. But GRUB2 is of course first goal.) Well, i see the same options as with ISOLINUX. So this gesture should already be possible by xorriso: xorriso -as mkisofs ...above.options... Is there by chance a resulting image available which i could test and examine ? (The smaller the better. Booting up to a GRUB menu would suffice.) run the script it generates the image, presuming on a linux system Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Hi, Vladimir '?-coder/phcoder' Serbinenko wrote: - Is it possible to declare the whole iso for hard-disk emulation for providing emulating image for buggy BIOSes libisofs.h describes type ELTORITO_HARD_DISC_EMUL with API call iso_image_set_boot_image(). http://bazaar.launchpad.net/%7Elibburnia-team/libisofs/scdbackup/annotate/head%3A/libisofs/libisofs.h To my knowledge this is not tested yet. xorriso surely has no option to trigger it. But that is easily implemented as soon as a sincere tester shows up. - Is it possible to have HFS support in xorriso? It would allow merging PPC grub-mkrescue into generic one. Ouch. In principle it should work like Joliet: A complete second directory tree that co-exists with the ECMA-119/RockRidge tree. They only share data file contents. But i have no clue of HFS. Actually i use any possible excuse to not start working on UDF. I can promise to help integrating HFS into libisofs if somebody shows up who has the necessary HFS knowledge and comprehensive testing capabilities. --modification-date Override modification date this is needed to know the creation date (which is use as disk identifier in GRUB) before image is complete. Should not be a big problem. libisofs will get a new API call for that. Are there more add-on options which i should implement ? --protective-msdos-labelPatch a protective DOS-style label This one adds a simple partition table spanning across whole image of type 0xCD To bytes 446 - 509 of the image ? Type 0xCD in byte 450 ? Eventually into the data provided by --embedded-boot ? (Does it make sense without --embedded-boot ?) Syslinux isohybrid rounds up the image size to full MB. (I understand because it sets 64 heads * 32 sectors = 2048 * 512 bytes per cylinder) Is that necessary with --protective-msdos-label ? There must also a curb of nominal cylinder count (bytes 452,453) to 10 bits. Does that sound reasonable ? Have a nice day :) Thomas ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: How to prepare an ISO 9660 CD for booting via GRUB ?
Thomas Schmitt wrote: Hi, Vladimir '?-coder/phcoder' Serbinenko wrote: - Is it possible to declare the whole iso for hard-disk emulation for providing emulating image for buggy BIOSes libisofs.h describes type ELTORITO_HARD_DISC_EMUL with API call iso_image_set_boot_image(). http://bazaar.launchpad.net/%7Elibburnia-team/libisofs/scdbackup/annotate/head%3A/libisofs/libisofs.h To my knowledge this is not tested yet. xorriso surely has no option to trigger it. But that is easily implemented as soon as a sincere tester shows up. Should be easily testable with qemu. I can do it. The only problem is whether we should declare both possibilities in el torito because having 2 possible boots in eltorito is likely to trigger even more bugs. I think it should be an option to grub-mkrescue which emulation to use. - Is it possible to have HFS support in xorriso? It would allow merging PPC grub-mkrescue into generic one. Ouch. In principle it should work like Joliet: A complete second directory tree that co-exists with the ECMA-119/RockRidge tree. They only share data file contents. But i have no clue of HFS. Actually i use any possible excuse to not start working on UDF. I can promise to help integrating HFS into libisofs if somebody shows up who has the necessary HFS knowledge and comprehensive testing capabilities. I have an imac g3 I could test it on. The only catch is that I have no burner at home. But it should be manageable. I never looked deeply into HFS but I think I can do it. --modification-date Override modification date this is needed to know the creation date (which is use as disk identifier in GRUB) before image is complete. Should not be a big problem. libisofs will get a new API call for that. Are there more add-on options which i should implement ? Other than protective label, not off the top of my head. --protective-msdos-labelPatch a protective DOS-style label This one adds a simple partition table spanning across whole image of type 0xCD To bytes 446 - 509 of the image ? Type 0xCD in byte 450 ? Currently we use first and not last entry. You need to: 1) Zero-fill 446-510 2) Put 0x55, 0xAA into 510-512 3) Put 0x80 (for bootable partition), 0, 2, 0 (C/H/S of the start), 0xcd (partition type), [3 bytes of C/H/S end], 0x01, 0x00, 0x00, 0x00 (LBA start in little endian), [LBA end in little endian] at 446-462 Eventually into the data provided by --embedded-boot ? Yes (Does it make sense without --embedded-boot ?) Yes, for example to allow people dd images to USB sticks without a fear of another OS willing to format the stick. Syslinux isohybrid rounds up the image size to full MB. (I understand because it sets 64 heads * 32 sectors = 2048 * 512 bytes per cylinder) Is that necessary with --protective-msdos-label ? No -- Regards Vladimir 'φ-coder/phcoder' Serbinenko signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
