Hi,
Mingcong Bai wrote:
> While FAT < 32 filesystems are not case sensitive (which grub-mkrescue
> creates
> as a FAT12 image via mformat with a size of 2.88MiB), it seems that
> some of Loongson's LoongArch-based firmware (namely those found on their
> latest XA61200 boards) seems to treat this
Hi,
Gerd Hoffmann wrote:
> I doubt the vfat driver of the uefi firmware supports rock ride,
> and that is the driver used to load efi/boot/bootloongarch64.efi
> because grub is not yet loaded ...
xorrisofs option -iso-level 3 has no effect on the FAT filesystem in
the EFI boot image (/efi.img
Hi,
Mingcong Bai wrote:
> This is needed for architectures whose EFI executables has file names that
> exceeds the 8.3 (extension.suffix) convention, such as LoongArch64
> (bootloongarch64.efi).
In general -iso-level 3 is a harmless setting if the reading operating
system is Linux or
Hi,
Daniel Kiper wrote:
> AIUI this [1] email presented some concerns.
> [1] https://lists.gnu.org/archive/html/grub-devel/2023-03/msg00022.html
This was about the trailing blank in the output of grub-fstest.
I decided to simply remove it because it is not expectable that any wrong
handling of
-fstest.
Signed-off-by: Thomas Schmitt
---
tests/iso9660_early_ce.iso.gz | Bin 0 -> 709 bytes
tests/iso9660_test.in | 24
2 files changed, 24 insertions(+)
create mode 100644 tests/iso9660_early_ce.iso.gz
diff --git a/tests/iso9660_early_ce.iso.gz b/tests/iso9660_e
and perform checks and
reading of new data only after the reader loop has ended.
Signed-off-by: Thomas Schmitt
---
grub-core/fs/iso9660.c | 84 ++
1 file changed, 44 insertions(+), 40 deletions(-)
diff --git a/grub-core/fs/iso9660.c b/grub-core/fs/iso9660.c
sequence
dd conv=notrunc if=ce_field bs=1 seek=37198 of="$iso"
dd conv=notrunc if=nm_field bs=1 seek=37226 of="$iso"
-
Have a nice day :)
Thomas
Thomas Schmitt (2):
fs/iso9660: Delay CE hop until end of current SUSP area
tests: Add te
Hi,
i am working on a patch to let GRUB delay the execution of a ISO 9660
SUSP CE hop until the current SUSP area is consumed. Currently it hops
immediately which is wrongly relying on implementation details of the
ISO producer. SUSP 1.12 specs are clear. Linux obeys them.
The code works but the
Hi,
Glenn Washburn wrote:
> > > +echo "Testing for proper recognition of CE loops ... "
> Ugh, this should be "echo -n".
My make "check" wrote:
> > Testing for proper recognition of CE loops ...
> > FAIL (iso9660_ce_loop)
> > FAIL iso9660_test (exit status: 1)
Actually this looks quite ok
r the functional tests
>
> * If running a Linux kernel the following modules must be loaded:
>- fuse, loop
Reviewed-by: Thomas Schmitt
Have a nice day :)
Thomas
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
t;
> +if [ ! -e "@builddir@/"unicode.pf2 ]; then
> + echo "Functional test requires grub-mkfont support"
> + exit 99
> +fi
> +
> case "${grub_modinfo_target_cpu}-${grub_modinfo_platform}" in
> # PLATFORM: Max RAM is 256M
> mips
e
> +"@builddir@/grub-fs-tester" rockridge_joliet_1999
> +
> +echo "Testing for proper recognition of CE loops ... "
> +for fs in iso9660_ce_loop iso9660_ce_loop2; do
> + tempdir=`mktemp -d "${TMPDIR:-/tmp}/${0##*/}.$(date
> '+%Y%m%d%H%M%S%N').${fs}
Hi,
another confused statement of mine:
> Unicode is mentioned two times in INSTALL.
I meant "Unifont" and "unifont".
Have a nice day :)
Thomas
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Hi,
Glenn Washburn wrote:
> IIRC, xfonts-unifont is pulled in by the unifont package on Debian, but
> it is the one with the files you need. No, its not documented, but then
> not every single debian package name needed is documented because the
> documentation is partially distribution agnostic.
Hi,
Glenn Washburn wrote:
> You have the package xfonts-unifont installed correct?
Urm, no. (I have no desktop running. Just fvwm.)
Is the need for this package documented somewhere ?
Well, now it is installed. I do
$ ./configure
...
GRUB2 will be compiled with following components:
Hi,
i have to correct a confused statement of mine:
> I suspect that ${files} comes from the "--files=" argument that is given
> to ./grub-shell by tests/util/grub-shell.in.
The "--files=" argument is given by tests/grub_func_test.in.
Meanwhile i verified that this argument is the origin of
Hi,
Vladimir Serbinenko wrote:
> Look at the end of configure message. Is free type enabled? Was unifont
> found?
$ ./configure
...
checking whether -Wtrampolines work... yes
checking for freetype2... yes
checking ft2build.h
Hi,
i encountered some stumblestones after running "make check":
-
I see in file ./test-suite.log :
FAIL: grub_func_test
xorriso 1.5.2 : RockRidge filesystem manipulator, libburnia project.
...
iso9660_ce_loop iso9660_ce_loop2; do
> + tempdir=`mktemp -d "${TMPDIR:-/tmp}/${0##*/}.$(date
> '+%Y%m%d%H%M%S%N').${fs}.XXX"` ||
> +{ echo "Failed to make temporary directory"; exit 99; }
> + gunzip <"$srcdir"/tests/${fs}.iso.gz >"${temp
Hi,
Glenn Washburn wrote:
> --- a/tests/iso9660_test.in
> +++ b/tests/iso9660_test.in
> @@ -12,4 +12,13 @@ fi
> "@builddir@/grub-fs-tester" rockridge_joliet
> "@builddir@/grub-fs-tester" joliet_1999
> "@builddir@/grub-fs-tester" rockridge_1999
> -"@builddir@/grub-fs-tester"
Hi,
Glenn Washburn wrote:
> Why does only one suffice? It
> sounds like they test different code paths. Is it possible that there
> is a future code regression such that one iso succeeds and the other
> fails?
They follow different code paths before hunk 4 of patch 5 fixes the
bug that CE and ST
Hi,
i wrote:
> > So it would be better to add one or two canned images:
> > 897 bytes of http://scdbackup.webframe.org/ce_loop.iso.gz
> > 904 bytes of http://scdbackup.webframe.org/ce_loop2.iso.gz
Glenn Washburn wrote:
> These are small, I'm good with adding these images to the repository.
Hi,
Daniel Kiper wrote:
> Thomas, it would be nice if you could add the broken ISOs images which you
> used for tests to the tests in the GRUB. If you do that please CC Glenn.
Is it wise to have a test which will loop endlessly in case of failure ?
Is there a way to let a test time out ?
SUSP entries of the file. In case of ST this could
> cause following non-SUSP bytes to be interpreted as SUSP entries.
>
> Signed-off-by: Thomas Schmitt
> Tested-by: Lidong Chen
> ---
> grub-core/fs/iso9660.c | 16
> 1 file changed, 16 insertions(+)
>
>
Hi,
Lidong Chen wrote:
> I ran grub-fastest with both ce_loop ISO files. The endless loops were
> detected and Grub exited accordingly.
Good.
> I didn't know where the grub error message
> were stored in case of grub-fastest.
So you don't see an error message ?
I had the same problem a while
Hi,
i wrote:
> > libisofs and xorriso are in the process of getting an adjustable curb to
> > prevent the production of ISO filesystems with files which would not show
> > up in Linux. I decided for 100,000 hops as hard limit but set the default
> > to 31.
Lidong Chen wrote:
> I am not sure I
Hi,
On Wed, 18 Jan 2023 08:23:53 + Lidong Chen wrote:
> Thomas also pointed out the issue of the potential endless
> loops by CE. Since the sugguested fix requires a bit more
> investigation, and as Thomas pointed out that it should be
> handled in a separate patch, the fix is not included
SUSP entries of the file. In case of ST this could
> cause following non-SUSP bytes to be interpreted as SUSP entries.
>
> Signed-off-by: Thomas Schmitt scdbac...@gmx.net
> ---
> grub-core/fs/iso9660.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/g
zeof (*entry) to check the entry boundary.
>
> Signed-off-by: Lidong Chen
> Reviewed-by: Thomas Schmitt
> ---
> grub-core/fs/iso9660.c | 17 +++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/grub-core/fs/iso9660.c b/grub-core/fs/iso9660.c
Hi,
On Wed, 18 Jan 2023 08:23:56 + Lidong Chen wrote:
> Added a check for the SP entry data boundary before reading it.
>
> Signed-off-by: Lidong Chen
> Reviewed-by: Thomas Schmitt
> ---
> grub-core/fs/iso9660.c | 16 ++--
> 1 file changed, 14 inser
grub_free (sua);
> sua = grub_malloc (sua_size);
> if (!sua)
> @@ -319,6 +338,11 @@ grub_iso9660_susp_iterate (grub_fshelp_node_t node,
> grub_off_t off,
> grub_free (sua);
> return 0;
> }
> +
> + entry = (struct grub_iso9660_susp_e
nd of the block and ensure the read is within directory
> boundary.
>
> Signed-off-by: Lidong Chen
> Reviewed-by: Thomas Schmitt
> ---
> grub-core/fs/iso9660.c | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/grub-core/fs/iso9660.c b/grub-core
Hi,
Lidong Chen wrote:
> To test it, I am thinking to add the ISO entry in 40_custom script, then
> select
> the ISO from Grub menu. Is it the right way to test it? Or, is there a better
> way
> to it?
I have to leave the answer to the experienced GRUB developers.
Testing is my weak spot with
Hi,
i created another bad ISO which i expect to lead to an endless loop in
existing GRUB (i.e. before applying the proposed change).
Both ISOs can be downloaded as gzip-compressed files now:
http://scdbackup.webframe.org/ce_loop.iso.gz
SHA256:
Hi,
Lidong Chen wrote:
> Thanks for the clarification. I created a new patch for the fix and added
> you as the “Signed-off-by”.
> My question is how to test it.
I just sent libisofs into an endless recursion loop. Grrr.
For this i created a small ISO with a file which surely needs a CE, changed
Hi,
i wrote on Fri, 16 Dec 2022 10:42:13 +0100:
> > If processing of a SUSP CE entry leads to a continuation area which begins
> > by entry CE or ST, then these entries were skipped without interpretation.
> > In case of CE this would lead to premature end of processing the SUSP
> > entries of
Hi,
Pete Batard wrote:
> > unlike what is the case for UEFI, one can not expect
> > to be able to pick all the GRUB core files needed to convert a GRUB
> > based ISO bootable media to a GRUB based USB bootable media [...]
> > Typically, one of the
> > missing files will be a 'core.img' that can
ec 15, 2022, at 10:20 AM, Thomas Schmitt wrote:
> > This loop is iterating over component records, not SUSP entries.
> > Minimum size of a component record is 2.
> >
> > So i think the appropriate condition is:
> >
> > while (pos + 1 < entry->
Hi,
i wrote:
> > (Are we aware of the file size limit of 32 GiB - 14 KiB - 1 imposed by
> > struct grub_fshelp_node { ... struct grub_iso9660_dir dirents[8]; ... }
> > ? )
Lidong Chen wrote:
> I am not familiar with this file size limit. Do we need to add a check
> somewhere?
Good question.
of the file.
In case of ST this could cause following non-SUSP bytes to be interpreted
as SUSP entries.
Signed-off-by: Thomas Schmitt
--- grub-core/fs/iso9660.c.lidong_chen_patch_2 2022-12-15 11:46:50.654295924
+0100
+++ grub-core/fs/iso9660.c.lidong_chen_patch_2_ce_fix_v22022-12-16
13
were skipped without interpretation.
In case of CE this would lead to premature end of processing the SUSP entries
of the file.
In case of ST this could cause following non-SUSP bytes to be interpreted
as SUSP entries.
Signed-off-by: Thomas Schmitt
--- grub-core/fs/iso9660.c.lidong_chen_patch
Hi,
while preparing a proposal how to avoid skipping of CE (and ST) if they
are found at the start of a continuation area, i came to a problem of
patch [2/4] which i did not see when reviewing it yesterday:
> + return grub_error (GRUB_ERR_BAD_FS, "invalid CE entry size");
It is not
Hi,
On Wed, 14 Dec 2022 18:55:05 + Lidong Chen wrote:
> [PATCH 4/4] fs/iso9660: Incorrect check for entry boudary
s/boudary/boundary/
> An entry consists of the entry info and the component area.
Component area is specific to the RRIP SL entry. So:
s/An entry/An SL entry/
> The entry
+
> data->susp_skip = entry->data[2];
>entry = (struct grub_iso9660_susp_entry *) ((char *) entry +
> entry->len);
>
> --
> 2.35.1
>
Reviewed-by: Thomas Schmitt
But the expression (GRUB_ISO9660_SUSP_HEADER_SZ + 2) will need correction if
my wish for
#defi
Hi,
On Wed, 14 Dec 2022 18:55:03 + Lidong Chen wrote:
> In the code, the for loop advanced the entry pointer to the
> next entry before checking if the next entry is within the
> system use area boundary. Another issue in the code was that
> there is no check for the size of system use area.
gt; + continue;
> + }
> +
> if (node->have_dirents >= node->alloc_dirents)
> {
> struct grub_fshelp_node *new_node;
> --
> 2.35.1
>
Reviewed-by: Thomas Schmitt
The second hunk will become very necessary when more
Hi,
i will review the patches hopefully tomorrow.
But in [PATCH 2/4] and [4/4] i stumble over the statement that a SUSP
entry has 5 bytes of size. This is not true. The minimum size is 4.
In SUSP there are "Padding" PD (if its byte LEN_PD is 0) and "Stop" ST,
which have 4 bytes. In RRIP there
Hi,
i wrote:
> > > I will think about creating such an ISO by help of xorriso and dd.
Daniel Kiper wrote:
> Yeah, that would be perfect...
I believe to have created one. But grub-fstest does not produce a memory
fault. See my mail
Date: Tue, 29 Nov 2022 19:47:22 +0100
Message-Id:
Hi,
Fengtao wrote:
> I think:
> (char *) entry < (char *) sua + sua_size - 3 && entry->len > 0
> is ok, or:
> (char *) entry <= (char *) sua + sua_size - 4 && entry->len > 0
"4" would be overdone. There are SUSP and RRIP entries of length 4,
which would be ignored if appearing at
Hi,
(Again i Cc t.feng in the hope that the review is not finished yet. :))
Daniel Kiper wrote:
> I am not an ISO format expert but your thinking LGTM.
So you agree that "3" is really the right number if any remaining bytes
fewer than 4 shall be ignored ?
(I don't trust myself, although i made
Hi,
i wrote:
> I think the loop end condition should use 4 rather than 1:
> (char *) entry < (char *) sua + sua_size - 4 && entry->len > 0
Urm ... better "3 rather than 1":
(char *) entry < (char *) sua + sua_size - 3 && entry->len > 0
The memory fault by entry->len will appear if
Hi,
(Cc-ing t.feng in the hope that this issue can become part of the code
review.)
While reviewing "[PATCH 7/9]" by t.feng, i wonder whether there is a bug
in grub_iso9660_susp_iterate() in regard to the end of the SUSP data:
for (entry = (struct grub_iso9660_susp_entry *) sua; (char *)
Hi,
on Sat, 19 Nov 2022 18:39:44 +0800, t.feng via Grub-devel wrote:
> Fix memory leak in grub_iso9660_susp_iterate.
>
> Fixes: 99373ce47(iso9660.c: Remove nested functions.)
>
> Signed-off-by: "t.feng"
Reviewed-by: Thomas Schmitt
H
9660 file
> system.
>
> This is accomplished by removing the use of a temporary directory to create
> the
> efi/ content, to instead place it at the root of the ISO9660 content.
>
> Signed-off-by: Pete Batard
Reviewed-by: Thomas Schmitt
Tested-by: Thomas Schmitt
I
Hi,
Pete Batard wrote:
> 2. It uses a efi.img to embed the UEFI bootloaders, but does not keep a copy
> of these bootloaders on the ISO9660 file system itself, with the end result
> that, when copying the media at the file system level, the '/efi/boot/'
> directory and its content is missing.
I
Glenn Washburn
> ---
> Updates since v1:
> * Reorder such that command line arguments are built in order, per Thomas'
> suggestion
> ---
Reviewed-by: Thomas Schmitt
Have a nice day :)
Thomas
___
Grub-devel mailing list
Grub-devel
Hi,
i think this change is beneficial for the maintainability of the test.
But this sequence looks a bit confusing, albeit it is ok on the second
glimpse:
+ XORRISO_ARGS="-as mkisofs $XORRISOFS_CHARSET -graft-points"
+
+ if [ -z "${fs##*rockridge*}" ]; then
+
Hi,
Robbie Harwood wrote:
> dl.c:694:
> add-symbol-file ...
> dl.c:694:
> add-symbol-file ...
> dl.c:694:
> add-symbol-file ...
>
> You can't easily copy-paste that into gdb. It needs to be processed to
> remove the file:line stuff.
How about hiding the "dl.c" lines
r_r and -zisofs.
Remove the -as mkisofs options which produce a Joliet filesystem tree.
Signed-off-by: Thomas Schmitt
---
tests/util/grub-fs-tester.in | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/tests/util/grub-fs-tester.in b/tests/util/grub-fs-tester.in
index 4f581b638..a28e0
Hi,
i am working on the requested changes.
In my patch message i wrote:
> > A bug
> > in xorriso causes a distracting warning about FSLABEL being too long for
> > Joliet. Shortcommings of Joliet cause warnings about symbolic links.
Daniel Kiper wrote:
> s/links./links too./?
Rather not. Both
Hi,
sorry for messing up the mail subject by "[PATCH] [PATCH]". (I added one
of them already to the local commit message.)
Shall i send new mail with better subject ?
Have a nice day :)
Thomas
___
Grub-devel mailing list
Grub-devel@gnu.org
iso9660" to the 32-byte FSLABEL list. Fix the xorriso run to
produce compressed files which for now cause righteous failure of the test.
Remove the option to produce a Joliet filesystem tree in order to
concentrate on testing zisofs decompression.
Signed-off-by: Thomas Schmitt
---
tests/uti
Hi,
i wrote:
> > it might be contraproductive to set LANG=en_US.UTF-8.
Glenn Washburn wrote:
> My patch only sets LANG if empty, so in this case I don't think its
> counterproductive, just not productive.
Yes. It cautiously avoids to make the situation any worse.
I meant my own announced plan
CODESET.
So override the result of nl_langinfo(CODESET) by options of xorriso -as
mkisofs.
Signed-off-by: Thomas Schmitt
---
tests/util/grub-fs-tester.in | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/tests/util/grub-fs-tester.in b/tests/util/grub-fs
Hi,
it turns out that it might be contraproductive to set LANG=en_US.UTF-8.
If the LANG locale is not listed by
locale -a
then nl_langinfo(3) returns "ANSI_X3.4-1968".
I stumbled over this when testing LANG=de_DE.UTF8, which despite of
my location is not an available locale on my machine.
So
Hi.
Glenn Washburn wrote:
> I think the changes to get the test
> working are worthy of inclusion so that the tests are ready when this
> feature gets implemented.
Do you think my draft of a commit message is ok ?
Probably i should mention that this test will fail until zisofs is
implemented.
Hi,
i wrote:
> > xorriso ... -as mkisofs -input-charset UTF-8 -output-charset UTF-8
Glenn Washburn wrote:
> Do there need to be any UTF-8 locales installed (or any locales for
> that matter) for this to work? My guess is no.
I expect the same. It's not easy to test, though.
In theory it is
s applied before any
files had populated the emerging ISO image.
So add "ziso9660" where other ISO 9660 tests get a shorter FSLABEL and
re-arrange the commands of the xorriso run to bring -add and -zisofs before
-set_filter_r.
Signed-off-by: Thomas Schmitt
diff --git a/tests/util/grub-fs-
Hi,
now i know that i should have asked for the test-suite.log file.
The problem turned out to be in Joliet, not in ISO 9660.
Because Joliet gets its file names and other texts encoded as UCS-2
16-bit characters it is indeed inavoidable to define the meaning of the
bytes in a Unix file name.
The
Hi,
Glenn Washburn wrote:
> If I'm not mistaken, there is currently no test which actually
> exercises that code, ie no test runs "grub-fs-tester ziso9660". I think
> it could be a good idea to have one though.
So we should get this to work. zisofs can be helpful to squeeze more
operating system
Hi,
Glenn Washburn wrote:
> Despite having an alternative approach, do you have concerns or
> objections to my patch?
Not specifically. I initially only wanted to mention that there is
a xorriso alternative to setting LANG. Both ways have different
implications in detail. (LANG is global to the
Hi,
the xorriso run for testing zisofs in
tests/util/grub-fs-tester.in
looks not like it would cause any zisofs compression in the ISO.
Line 1024:
xorriso -compliance rec_mtime -set_filter_r --zisofs -- -zisofs default
-as mkisofs ... some options ... --
Hi,
Glenn Washburn wrote:
> LANG must be set to something that supports international characters,
> otherwise xorriso will refuse to include the file with name having
> international characters, causing the test to fail.
Can you tell me the exact error message from xorriso ?
I have some
Hi,
what shall be done about the failure of grub-mkrescue for I386_EFI,
X86_64_EFI, and POWERPC_IEEE1275 with very large input file trees ?
https://lists.gnu.org/archive/html/grub-devel/2020-06/msg00062.html
libisofs now emits a better error message
Too many files in HFS+ directory tree
Hi,
(cc-ing bug-xorr...@gnu.org and the reporter of the problem.)
I now have the Guix ISO which fails when created by grub-mkrescue
with HFS+ tree.
To my newest theory it is not about the number of files in a directory
but about the total number of files in the tree and their name lengths.
I
Hi,
i just got a bug report about Guix ISO image production failing with
libisofs: FAILURE : HFS+ map nodes aren't implemented
The message stems from the HFS+ contribution to libisofs by Vladimir
Serbinenko in 2012. About the only program which asks libisofs to
produce HFS+ is grub-mkrescue,
Hi,
Michael Chang wrote in patch 2/2:
> ../../grub-core/fs/zfs/zfs.c:2263:44: error: array subscript '' is
> outside the bounds of an interior zero-length array 'grub_uint16_t[0]' {aka
> 'short unsigned int[0]'} [-Werror=zero-length-bounds]
> [...]
> The l_hash[0] is apparnetly an interior member
Hi,
i wrote:
> >(char *) _roles - (char *) sb
> >+ grub_le_to_cpu32 (sb.dev_number) * sizeof(grub_uint16_t)
PGNet Dev wrote:
> grub-core/disk/mdraid1x_linux.c:183:6: error: cannot convert to a
> pointer type
My fault. I forgot the "&" before "sb".
(char *)
Hi,
Paul Menzel wrote:
> 181 | (char *) _roles[grub_le_to_cpu32 (sb.dev_number)]
>98 | grub_uint16_t dev_roles[]; /* Role in array, or 0x for a
> 127 | struct grub_raid_super_1x sb;
> [...]
> Normally, it should be fixed by using `grub_uint16_t[]` instead of
>
Hi,
i wrote:
> > [ ] Change HFS+ LABEL automatically by adding "_HFSPLUS" to the upto 32
> > characters of Volume Id.
Daniel Kiper wrote:
> Where this automatic change should happen? grub-mkrescue or libisofs?
In libisofs. The decisive code gesture is in Vladimir's contribution
Hi,
during tests about the changes in blkid which are still discussed in
https://github.com/karelzak/util-linux/pull/913
i noted that a grub-mkrescue ISO for x86 BIOS and EFI shows the same
filesystem label with its ISO 9660 and HFS+ filesystem superblocks.
# lsblk -o NAME,FSTYPE,LABEL
Description of the workaround for firmware of older MacBooks which
stalls with a grub-mkrescue ISO image for platform "x86_64-efi" on
a USB stick.
Signed-off-by: Thomas Schmitt
---
diff --git a/docs/grub.texi b/docs/grub.texi
index 308b250..a9b38e9 100644
--- a/docs/grub.texi
Hi,
@Daniel Kiper:
I am trying to answer your mail from yesterday.
(Offlist) Re: grub-mkrescue: Problem with MBR partition table at
start of EFI partition
But my mail provider's server forwards to me this rejection:
dki...@net-space.pl:
SMTP error from remote server for MAIL FROM
Hi,
thanks a lot for the background info.
Alain Knaff wrote:
> A platform that expects the disk to be unpartitioned would just ignore
> this mini partition table.
The EFI platform encounters the mformat-produced image in a partition.
Nearly all implementations indeed ignore the MBR-ish table in
Hi,
in the course of a problem search between GRUB, Guix, and xorriso we found
the trigger of a problem with some old Macbook EFI firmware in a gesture
of mformat.
Line 1375 of
http://svn.savannah.gnu.org/viewvc/mtools/trunk/mformat.c?revision=506=markup
has
/* install fake partition table
Hi,
i wrote:
> > So i propose the change as fine tuning of the original developer's
> > intention. (Vladimir will correct me if i'm wrong.)
Daniel Kiper wrote:
> After some thinking I have an itching to add the "-k" option to the
> mformat.
I am not courageous enough to go that far.
> So, I
Hi,
i quoted mformat.c:
> > /* install fake partition table pointing to itself */
Daniel Kiper wrote:
> OK, but why it is also done for FDD images?
According to its man page, mformat formats floppies. So the question
would be why it creates a partition table at all.
> > Either mformat's
Hi,
> Again, this is an FDD 2880K image and there is no MBR there. Your
> interpretation is wrong.
In respect to MBR partition table, mformat source has at
https://sources.debian.org/src/mtools/4.0.23-1/mformat.c/#L1375
code with this comment:
/* install fake partition table pointing to
Hi,
Daniel Kiper wrote:
> may I ask you to write a summary of your findings,
A Macbook took offense from the MBR partition table entry in the EFI FAT
image which grub-mkrescue produces by help of mformat(1).
Vladimir stated that this partition table entry is not intentional and
that the
Hi,
Daniel Kiper wrote:
> may I ask you to write a summary of your findings,
A Macbook took offense from the MBR partition table entry in the EFI FAT
image which grub-mkrescue produces by help of mformat(1).
Vladimir stated that this partition table entry is not intentional and
that the
Hi,
Florian Pelz wrote:
> I guess this is off-topic and we cannot learn anything about the
> permissibility of mformat -k from Windows?
Yes.
The on-topic conclusion so far is that i cowardly propose to zeroize
the MBR partition table in the mformat result before populating it
by mcopy.
(Code
Hi,
> On the other hand, in the Windows world this rarely causes any confusion
> since no Windows version I've encountered so far contains native tools
> to write an ISO (or any other image file) to a USB stick as Unix' "dd"
> command would.
A Wallace Line for ISO-zooa. This explains a lot.
>
Hi,
Florian Pelz wrote:
> Shall I continue testing?
I'm into ISO images. But it might be interesting to see what Microsoft
deems to be bootable and is willing to promote by its weight.
> I do not know how to verify on Windows if the boot used UEFI.
You could zeroize the x86 machine code in
Hi,
> The Windows 8.1 ISO image that I downloaded from Microsoft yesterday
> also cannot be booted from a USB drive on neither this Macbook or
> another computer.
I wonder how other people can get to the impression that their attempts
succeeded. (Will have to wait for somebody who is willing to
Hi,
Florian Pelz wrote:
> This is not an install ISO but a USB install medium. The USB drive
> was written by the Windows Media Creation Tool. Copying instead a
> Windows ISO created by the Windows Media Creation Tool to a USB drive
> does *not* yield a bootable USB drive; it does not even boot
Hi,
Florian Pelz wrote:
> I would like to test but on this bootable German Windows 10
> 32-bit+64-bit USB install medium, the content is different. How would
> I find the offset in the USB image (you call it offset 454) which I
> should zero out to break Windows?
That would be offset 454 in the
Hi,
iwrote:
> What do you get as hex dump of byte 1,062,912 to 1,063,423 ?
I found the answer in the hex dump:
00103800 eb 3c 90 4d 53 44 4f 53 35 2e 30 00 02 01 01 00 |.<.MSDOS5.0.|
00103810 02 e0 00 40 0b f0 09 00 12 00 02 00 00 00 00 00 |...@|
00103820 00 00 00 00 00
Hi,
Chris Murphy wrote:
> [Microsoft image CCCOMA_X64FRE_JA-JP_DV9]
> b040 91 ef 01 00 00 00 00 00 00 00 00 00 00 00 00 00 |
> b050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
> b060 88 00 00 00 00 00 01 00 07 02 00 00 00 00 00 00 |
It comes to
Hi,
Chris Murphy wrote:
> Fedora ISO's use isohybrid and have multiple partitions on their ISOs:
> MBR, GPT, and APM.
Well, the GPT is not valid because the MBR partition table is not
"protective". It has a partition of type 0xEF embedded in a partition
of type 0x00. Barely compliant to UEFI
Hi,
Vladimir 'phcoder' Serbinenko wrote:
> > have a look at windows install CD/DVD.
Chris Murphy wrote:
> I think there's no partition whatsoever, plain UDF.
> LABEL="CCCOMA_X64FRE_EN-US_DV9"
debian-user has a thread about a similar image: CCCOMA_X64FRE_JA-JP_DV9
1 - 100 of 214 matches
Mail list logo
