Hi,
[resending to bug-grub after rejection message]
Alexander E. Patrakov wrote:
> > http://www.syslinux.org/wiki/index.php/Isohybrid
This is quite independent of what GRUB2 does.
(SYSLINUX and GRUB2 meet at BIOS and EFI, of course.)
Andrei Borzenkov wrote:
> Command from syslinux wiki does no
Hi,
Alexander E. Patrakov wrote:
> [resending after the rejection, now I am subscribed to both lists]
Hm. I got your first reply to Andrei and bug-xorriso after
i freed it from the bug-xorriso list jail.
Andrei's was on hold too.
Hopefully i now exempted both of you from moderator review.
... ah
Hi,
[taking Alexander out of Cc: as he probably gets the mails
from the lists twice, as i do]
I currently only have some mockup ISO from HFS+ experiments
with Vladimir.
When i replay its xorriso -as mkisofs boot related options
--grub2-mbr ...some.file...
--protective-msdos-label
-apm-b
Hi,
Andrei Borzenkov wrote:
> There is no regression [in xorriso].
This is now my opinion, too.
Regrettably the code has some history of stop-and-go development.
I added features when Vladimir requested them. And now i cannot
remember all the motivations.
But it is surely no inadverted change. A
Hi,
i wrote:
> > I currently try to talk Debian out of nesting partitions,
> > even id the big one is type 0x00.
Alexander E. Patrakov wrote:
> If the discussion is archived somewhere, a pointer to it would be nice to
> have.
I made a lenghty assessment of Debians amd64 and i386 setup at
occasio
Hi,
Andrei Borzenkov wrote:
> a) are we sure every EFI system out there accepts MBR (Apple?)
At least my favorite layout (see my recent mail
9837584093514267...@scdbackup.webframe.org) is explicitely
promised by UEFI 2.4, "5.2.1 Legacy Master Boot Record (MBR)".
The Apple problems in the blog of
Hi,
i wrote:
> > promised by UEFI 2.4,
Andrei Borzenkov wrote:
> "promised" is encouraging :)
More we can't get with all the implementations out there.
> GPT starts at LBA 1. So we can deduce block size used to create this GPT
> by checking location of GPT header.
Ah. The first "EFI PART\000\
Hi,
here is my proposal to Alexander how to achieve my favorite layout.
To be tested with all BIOS or EFI x86 machines in reach.
I renamed "minimal.iso" to "minimal-grub2.iso" because my
ISO collection is full of mini*iso images.
Obtain the MBR template file (normally provided by GRUB2 installat
Hi,
i see that in my test proposal i forgot the Mac specific options
-apm-block-size 2048 -hfsplus
They are not supposed to influence x86 BIOS or EFI.
Nevertheless it would be better to include them in the test.
$ xorriso -as mkisofs \
-o minimal-grub2-repacked.iso \
-r \
Hi,
Andrei Borzenkov wrote:
> As expected, GRUB cannot access second partition when booted as CD,
> either in BIOS or EFI mode. It can when booted as HDD with 512B sector
> in both BIOS and EFI mode.
I have quite contrary results here.
- The repacked ISO works for me on BIOS qemu -hda and -cdrom,
Hi,
i wrote:
> >error: disk `' not found.
Alexander E. Patrakov wrote:
> The "ls" command in this case finds only (hd0), (fd0), (fd1) and (cd0)
I meanwhile found the strings in /efi.img
disk `%s' not found
grub rescue>
So OVMF starts GRUB2.
To clarify whether via MBR x86 code in BIOS
Hi,
xorriso wrote under my insufficient control:
> >MBR partition : 1 0x80 0xee132803
Alexander E. Patrakov wrote:
> OK, this is the bug. You have a 0xee partition, that indicates that GPT
Yep. Looks like a xorriso bug.
(How could this slip through when i looked
Hi,
Andrei Borzenkov wrote:
> Try access ESP content.
Err ... looking up manual ... you mean this ?
With ISO without -hfsplus :
qemu ... -bios .../OVMF.fd -cdrom ...iso
grub> ls (cd0,msdos2)/
error: unknown filesystem.
In contrast to
qemu ... -bios .../OVMF.fd -hda ...iso
grub> ls
Hi,
i wrote:
> For some reason the perception of GRUB2 is too large by a factor
> of two.
It is of course a factor of 4, as GRUB2 talks of KiB and
xorriso or fdisk talk of 512-blocks.
(The disease might be contageous.)
Have a nice day :)
Thomas
_
Hi,
Alexander E. Patrakov wrote:
> I will be too far from the Intel DG965SS board for the rest of the day, so
> please expect the test results tomorrow. Sorry!
Note that ISOs produced with -hfsplus currently have partition 1
starting at LBA 1 as is prescribed for type 0xee.
If you want to test wi
Hi,
Andrei Borzenkov wrote:
> MBR is created with 512B sector size but when GRUB is booted
> from CD-ROM sector size is 2KiB.
Ain't that a bug ?
GPT is recognized with 512. El Torito is recognized with its
weird mix of 512 for size and 2048 for block addresses.
The reason why APM is recorded wit
Hi,
Alexander E. Patrakov wrote:
> MBR partition table: N Status TypeStart Blocks
> MBR partition : 1 0x80 0x83032804
> MBR partition : 2 0x00 0xef32804 5760
In xorriso this would need
- The HFS+-0xee bug fixed (or no HFS+ b
Hi,
when assessing the differences between grub-mkrescue xorriso
options and those of Alexander's repacking, i forgot to
mention that
--protective-msdos-label
is used by grub-mkrescue but would be avoided in the alternative
result. If present it would cause partition 1 to start at LBA 1
and thus
Hi,
first a helper in case repacking goes on with other ISOs.
To obtain the value for --modification-date= , do:
$ xorriso -indev minimal-grub2.iso -pvd_info 2>/dev/null | \
grep '^Modif\. Time :' | sed -e 's/^Modif. Time : //'
2015121916023100
> https://goo.gl/photos/GRS5khE8r7Xgat
Hi,
> http://82.193.153.141/minimal-grub2-repacked-nohfsplus.iso
MBR partition table: N Status TypeStart Blocks
MBR partition : 1 0x80 0x83032220
MBR partition : 2 0x00 0xef32220 5760
> Result: "Windows" + "EFI Boot"
Hi,
i wrote:
> > Ain't that a bug ?
Andrei Borzenkov wrote:
> What exactly?
Partition type "msdos" with block size 2048.
If GRUB2 accepts "msdos" on CDROM, then it should not make such
a weird assumption.
i wrote:
> > one could set 512 as soon as partition type "msdos" is detected.
Andrei Bor
Hi,
i wrote:
> > And the other non-working "EFI Boot" offer is gone ?
> > (That would mean it was the APM/HFS+ boot path.)
Alexander E. Patrakov wrote:
> Yes.
So APM with block size 2048 seems not to work on HDD with size 512.
(The bytes 2 and 3 of the GRUB2 MBR in its role as fake APM Block0
t
Hi,
Alexander E. Patrakov wrote:
> I propose --dummy-bootable-mbr-partition.
That would probably be a new record in the field of option length.
Any shorter proposals ?
> I think it can be made
> non-overlapping if we waste a few sectors, but need to test.
Awaiting your results and Andrei's o
Hi,
Alexander E. Patrakov wrote:
> The following variants, obtained by changing only the MBR, also work:
> 1. Type-0 one-sector bootable partition at the very first sector:
> 01d0: 0100 0200 0100
Did you create this by partition editor or by dd ?
Wh
Hi,
Andrei Borzenkov wrote:
> Attempt to mount third GPR partition as HFS+ results in failure.
> Additionally it tries to interpret the first (dummy) partition, which is
> not fatal but annoying.
> [24623.487605] hfsplus: invalid secondary volume header
> [24623.487608] hfsplus: unable to find HFS
Hi,
> I think that, at this point, it would be useful to take one step back.
> Namely, I have this fact: Porteus Kiosk has no Apple partition map and no
> hfsplus, and boots on all machines (including the 2007 Mac) both as USB
> flash drive and as a CD.
Do the Debian amd64 or i386 netinst ISOs bo
Hi,
i wrote:
> > Awaiting your results and Andrei's opinion.
> > [about MBR dummy partition with boot flag]
Andrei Borzenkov:
> TBH I think that the best would be generic support for partition table
> manipulation
The more generic it is, the more complicated it is to coordinate
with the various
Hi,
Andrei Borzenkov wrote:
> [proposal how to define synthetic partition entries]
> Otherwise the most safe approach is probably based on design of mjg
... which does not comply to EFI specs.
Its trick is that any misunderstanding by the firmware shall
finally end up at the same address where th
Hi,
i made a man-in-the-middle script which can be handed to
grub-mkrescue as "xorriso" and changes the normal arguments to
those for the mjg layout.
To be downloaded as neighbor of a readily built and executable
GNU xorriso
cd .../xorriso-1.4.3/frontend/
wget
http://libburnia-project.org/b
Hi,
when running grub-mkrescue from Debian Sid, i get a
growing collection of files in /tmp. One per run.
Names are like:
/tmp/grub.00529W
Content is always the same:
insmod part_acorn
insmod part_amiga
insmod part_apple
insmod part_bsd
insmod part_dfly
insmod part_dvh
insmod par
Hi,
i improved the test script by adding two more manipulation modes:
- "mbr_only" produces an EFI compliant ISO without GPT, HFS+, APM.
- "original" lets the xorriso arguments pass unchanged.
The mode can be chosen by the environment variable
MKRESCUE_SED_MODE
Default mode is "mjg": ESP in MBR
Hi,
do i understand it right that you decided for the dummy MBR partition
that covers a single block at the start of the ISO ?
If you confirm, i will replace the two macros by a single option
which you can add to your grub-mkrescue run.
How about this:
--protective-msdos-bootflag
If --prote
Hi,
Alexander E. Patrakov wrote:
> > > 2B: prints "this is not a bootable disk" message
i wrote:
> > You see a string from the EFI partition 0xef in your old BIOS ?
> Yes! And it shows it despite the fact that there is no bootable partition!
Is this string from the very start of /efi.img ?
In
Hi,
Alexander E. Patrakov wrote:
> So, I can agree with making this (or the variant without efi.img
> duplication) the default layout for grub-mkrescue,
My goal for now would be to get at least two alternative layouts
into grub-mkrescue. Changing the default could break other people's
well worki
Hi,
Happy New Year.
I have uploaded
http://www.gnu.org/software/xorriso/xorriso-1.4.3.tar.gz
MD5 3c438044dc8827f2d12b10c64bbf0dd9
Version timestamp : 2016.01.01.172817
with a new -as mkisofs option to enforce an MBR partition with
"bootable/active" flag set.
--mbr-force-bootable
Hi,
Alexander E. Patrakov wrote:
> I think the script contains a copy-paste bug. Both lines 202 and 222 are:
> elif test x"$mode" = xmbr_only_copy
Indeed. Now that i do the forgotten test of this case i get
grub-mkrescue-sed.sh : FATAL : Unknown manipulation mode 'mbr_hfs_copy'.
Fixed by
ht
Hi,
Alexander E. Patrakov wrote:
> Robert Jones found an
> iMac (iMac5,2, boot ROM version IM52.0090.B00) that boots from "mbr_only"
> but doesn't boot from "mjg" when attepted to boot from USB
Can you get him to test a Debian netinst image ?
They are ISOLINUX/GRUB2 hybrids in "mjg" layout. See b
Hi,
i wrote:
> >
> > http://cdimage.debian.org/debian-cd/8.2.0/i386/iso-cd/debian-8.2.0-i386-netinst.iso
Alexander E. Patrakov wrote:
> On this iMac 5,2, the i386 gives 2 EFI options, both launch the installer.
> The amd64 is not recognized.
So it's probably a 32 bit machine. (Or at least boot
Hi,
> Planned Release:None => 2.03+
I think this bug should rather be closed.
Maybe with a hint that xorriso >= 1.4.3 now offers an -as mkisofs option
which addresses the problem
--mbr-force-bootable
Enforce an MBR partition with "bootable/active" flag if
Hi,
the only workaround i see is a xorriso wrapper script which manipulates
the xorriso arguments.
E.g. by adding a new case to the sed runs at
http://libburnia-project.org/browser/libisoburn/trunk/frontend/grub-mkrescue-sed.sh#L171
Free Software Supporter wrote:
> Currently, however, when
Hi,
i meanwhile decided to let xorrisofs option --norock revoke the -find job
which might have been ordered by option -r.
http://libburnia-project.org/changeset/5695
Now for the patches.
--
My own proposal would need a di
Hi,
Kim Olsen wrote:
> Libre Office Writer 4.3.3.2 creates UTF-8-coded text files with three
> special characters at the beginning of the file.
> ef bb bf ...
That's the Byte-Order-Mark for UTF-8, where it is quite useless,
as UTF-8 offers no choice of byte order.
https://en.wikipedi
Hi,
Carlo Caione wrote:
> > I think that the problem
> > here is that endless.squash has been stored in two extents in the
> > ISO9660 and GRUB doesn't deal fine with that (also according to this
> > comment
> > http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/fs/iso9660.c#n960
Andrei Bor
Hi,
Michel Bouissou wrote:
> After having disabled Secure boot, I have discovered that none of the
> usual (curent, latest versions as of 2017/12) Linux live USB sticks
> (among : Ubuntu, Mint, Debian, Manjaro, PartedMagic) was able to boot on
> this machine.
I assume the boot success depends muc
Hi,
Michel Bouissou wrote:
> I'm not in a situation of testing new USB keys right now,
If this ever changes, then i advise to test a grub-mkrescue made ISO.
I assume that it has the best chances to get the attention of GRUB developers.
> *** Keys booting OK out of the box :
> - Tails : tails-am
Hi,
Michel Bouissou wrote:
> The process was to boot on the original key (or CDROM) that would be a
> "temporary" Tails ISO dd'ed, and from there use the “tails installation
> program" to create a second key,
> [...]
> # file -s /dev/sdb
> /dev/sdb: DOS/MBR boot sector; partition 1 : ID=0xee, star
Hi,
Michel Bouissou wrote:
> Well, Knoppix *DOES BOOT OK* on said machine,
> [...] no error message is displayed, and in the end, it runs.
So the presence of ISO 9660 on the same medium is not the problem.
I am out of guesses. Everything points to something being missing or going
wrong in GRUB.
Follow-up Comment #1, bug #55118 (project grub):
Hi,
> linux (xyz)/syslinux/isolinux.bin
This is the SYSLINUX/ISOLINUX boot image for El Torito. Isn't that a
use case for chain loading rather than for OS start by "linux" ?
https://www.gnu.org/software/grub/manual/grub/html_node/Chain_002dload
Follow-up Comment #3, bug #55118 (project grub):
Hi,
i assume the admins of this bug tracker begin to see our conversation as
being off topic. Maybe you should describe your use case at help-g...@gnu.org
and ask for advise. See
https://lists.gnu.org/mailman/listinfo/help-grub
I get the impress
Follow-up Comment #1, bug #65880 (group grub):
Hi,
i can confirm that it happens on Debian 12 with the Debian amd64 package
grub-common (2.06-13+deb12u1) (plus grub-efi-amd64 , grub-efi-amd64-bin ,
grub-efi-amd64-signed , grub2-common) and also with a git clone of today.
The change at the end of
f grub-mkrescue did with a missing argument (e.g 2.02).
Fixes: https://savannah.gnu.org/bugs/index.php?65880
Signed-off-by: Thomas Schmitt
---
util/grub-mkrescue.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/util/grub-mkrescue.c b/util/grub-mkrescue.c
index abcc1c2f5..8714d819e 100644
Follow-up Comment #3, bug #65880 (group grub):
Hi,
the patch is now posted for review and testing at grub-devel:
https://lists.gnu.org/archive/html/grub-devel/2024-06/msg00163.html
Have a nice day :)
Thomas
___
Reply to this item at:
Follow-up Comment #4, bug #65880 (group grub):
Hi,
belatedly i can report that the proposed change was committed to the
git repo of GRUB as
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=b53ec06a1d6f22ffc1139cbfc0f292e4ca2da9cd
I propose to close the bug now.
Have a nice day :)
Thomas
Hi,
Vijay Kirpalani wrote:
> Step1: grub-mkrescue
> Step2: xorriso
I meanwhile wrote to you partly on bug-xorr...@gnu.org and partly in a
reply to your private mail that step 2 is unnecessary and also uses an
unsuitable mix of options and ISOLINUX MBR for exposing GRUB equipment
to the boot firm
Hi,
if you reply to this mail, then please also o bug-grub@gnu.org, not only
to me in private. (A private Cc to me is unnecessary but would be ok.)
Vijay Kirpalani wrote:
> I built a bootable ISO and have appended an ext2 disk partition in it.
How exactly did you do it ?
(Really the strange ste
Hi,
Vijay Kirpalani wrote:
> Step1:
> grub-mkrescue --modules="part_msdos part_gpt gzio ext2 iso9660" \
> -o final1.iso -d img0
> Step2:
> xorriso -as mkisofs \
>-o final.iso -c boot.catalog -volid "MY_CUSTOM_LINUX" \
>-b boot/grub/i386-pc/eltorito.img -no-emul-boot -boot-lo
Hi,
Adam Purkrt wrote:
> tried stracing grub-mkrescue:
> renergy ~ # grep de.mo~ gentoo-grub-mkrescue.strace
> rename("/tmp/grub.Y1wajm/boot/grub/locale/de.mo",
> "/tmp/grub.Y1wajm/boot/grub/locale/de.mo~") = 0
> unlink("/tmp/grub.Y1wajm/boot/grub/locale/de.mo~") = 0
> rename("/tmp/grub.Y1wajm/bo
Hi,
i wrote:
> > Do you see the .mo~ in the output of
> >xorriso -lsx /tmp/grub.pNWWGC/boot/grub/locale --
Adam Purkrt wrote:
> no, they are not there.
>
> Secondly: if I do the last step in the verbose log manually, I get correct
> iso, also without *.mo~ files, so there seems to be no probl
Hi,
just in case it was not clear from my first reply:
I cannot reproduce the problem on Debian 12 with GRUB 2.06 and 2.13.
Adam Purkrt wrote:
> Hi, no, actually there is not any occurrence of the string "mo~" in
> the output
> renergy ~ # grub-mkrescue --verbose -o grub.iso 2>&1 | grep mo~
> re
Hi,
i got a little experiment for you to check whether the .mo~ files
really eat up 2.7 MB in your ISO. They would not if they were hardlinks
in the /tmp/grub.* directory.
$ path_to_iso=./output.iso
$ xorriso -indev "$path_to_iso" -find / -name 'e...@cyrillic.mo*' -exec
report_lba --
...
Hi,
Adam Purkrt wrote:
> Hi, tried on Gentoo and the .mo~ files are not there in the /tmp/grub.*
> directory
Hrmpf. That's confusing.
Debian 12 has xorriso-1.5.4. But when i try with the current stable
version xorriso-1.5.6 i still don't get .mo~.
Do they really appear when you pack up that dir
Hi,
another experiment request.
Do you see the .mo~ in the output of
xorriso -lsx /tmp/grub.pNWWGC/boot/grub/locale --
Have a nice day :)
Thomas
Hi,
Adam Purkrt wrote:
> so I've tried on updated Debian 12 to come to the same conclusion
> as you - the problem does not occur there, but it does on Gentoo and Arch.
> Maybe the reason is different libisoburn or xorriso version behaving
> differently and adding those ".mo~" files...
I am their
Hi,
Adam Purkrt wrote:
> the backup files are there (see below).
> -rw-r--r-- 1 root root 127089 May 28 10:15 ast.mo~
(Second big sigh of relief.)
> Perhaps, even though the
> renaming and unlinking in strace look it is paired, somewhere between
> the renames and unlinks xorriso is called by gr
Hi,
Adam Purkrt wrote:
> renergy ~ # grub-mkrescue -o /does_not_exist/output.iso ; ls -a
> /tmp/grub.*/boot/grub/locale
> [... no .mo~ files ...]
So we have to watch the situation while grub-mkrescue is still running.
The following script will serve as xorriso in this run.
I put it into my "$HO
Hi,
i meanwhile think that grub-mkrescue.c simply has no means for removing
grub-install backup files before it runs xorriso.
It only has means to remove all /tmp files afterwards and to remove only
the backup files at premature program end.
---
Hi,
after
apt-get install grub-pc-bin
i can reproduce the problem on Debian 12.
The resulting ISO now has boot equipment for X86_64_EFI and I386_PC.
Therefore grub_install_copy_files() ran twice and backup files .mo~
emerged which ended up in the ISO. 4.3 MB from ast.mo~ to zh_TW.mo~.
Have
Hi,
i cannot see any use of string "locale" in util/grub-mkrescue.c.
The files came in as part of the temporaty directory tree
/tmp/grub.GoPPTa
So the ".mo~" files probably stem from the activities of grub-install
functions underneath grub-mkrescue.
In grub-mkrescue.c :
main() -> grub_install_
Hi,
Adam Purkrt wrote:
> your patch works fine for me!
So the grub-mkrescue aspects of both alternatives look good so far.
But there is the grub-install aspect to be tested. And that is
absolutely not my realm.
Somebody has to repeatedly run grub-install on a (possibly virtual)
system disk and v
output_wo_backup.iso -lsl /boot/grub/locale --
but there were only the original .mo files.
Have a nice day :)
Thomas
Signed-off-by: Thomas Schmitt
===
diff --git a/include/grub/util/install.h b/include/grub/util/install.h
index
This is my preliminary proposal for a grub-util API call
void grub_install_delete_backup_files (void);
which gets called by grub-mkrescue instead of
grub_set_install_backup_ponr (void);
In my Debian 12 setup with X86_64_EFI and I386_PC this prevents the
presence of .mo~ files in the ISO.
Po
re are no more
> *.mo~ files in the iso made by grub-mkrescue, and all the .mo
> files are there.
Feel free to propose it to Gentoo for wider testing.
(IIRC there was an ISO generator tool involved that uses
grub-mkrescue.)
Signed-off-by: Thomas Schmitt
> But looking at the patch let me
Hi,
the program in this mail creates a directory and a file in it.
After checking that the file exists, it gets unlinked.
Then the program forks and the child checks for the existence of the
file, while the parent waits.
The parent checks for file existence after the child has finished.
Finally it
Hi,
Adam Purkrt wrote:
> great to hear you can reproduce the problem.
It would have been less bumpy if i were a better Debian admin. :))
I will ponder about possible fixes.
For now i have:
- A new static variable and setter API call in grub-install-common.c
similar to grub_install_backup_ponr
74 matches
Mail list logo
