Hi,
Mike Hosken wrote:
> When I burned it to a cd it didn’t boot. When I tried a dvd it did boot.
That's strange. Do you still have that CD with the ISO on it ?
If so, what do you get from a run of
xorriso -indev /dev/sr0 -toc -report_system_area plain -check_media --
assumed that /dev/sr0
Hi,
John Paul Adrian Glaubitz wrote:
> > There is currently one limitation with the HFS patch as it doesn't allow
> > setting
> > a custom volume name and hard-wires it to "untitled" [4]. This is because
> > the original code uses an Apple-specifc function to convert UTF-8 into Mac
> > encoding
Hi,
Frank Scheiner wrote:
> > I believe you
> > can't have both FAT as OF bootstrap partition **and** blessing.
The only way would be that Apple had defined some protocol using the
specified capabilities of FAT, by which blessing and other Apple-specific
file properties can be expressed, and
Hi,
John Paul Adrian Glaubitz wrote:
> What's the alternative HFS+ tree of the ISO? Does it write a small HFS+
> filesystem onto the ISO image?
Alternative trees are tradition in ISO 9660: Joliet, ISO 9660:1999, UDF.
They can refer to the same data file content as the ISO 9660 tree, but
have
Hi,
John Paul Adrian Glaubitz:
> I just don't know how to bless a bootloader located on a FAT partition.
> I know that xorriso does it and it works on ISO9660 filesystems, but I
> don't understand how.
xorriso attributes blessing to an alternative HFS+ tree of the ISO.
This HFS+ tree is
Hi,
Mathieu Malaterre wrote:
> I vaguely remember someone mentioning a service where one could ssh
> onto ppc64el machines.
Maybe "The GCC Compile Farm project" ?
https://cfarm.tetaneutral.net/
> I need access to a POWER10
Their list shows POWER7 to 9, but no POWER10.
Hi,
John Paul Adrian Glaubitz wrote:
> - Use HFS+ with hfsprogs and write a blessing tool based on libisofs [2]
The code was contributed by Vladimir Serbinenko in 2012, when he was
the active maintainer of GRUB. See:
have yielded poffset 0.
But at that time the pages pointer has already moved beyond the end of
the allocated array of page structs (which has only 1 element).
Signed-off-by: Thomas Schmitt
Tested-by: Anatoly Pugachev
---
fs/isofs/compress.c | 33 ++---
1 file changed, 26
Hi,
Anatoly Pugachev wrote:
> mator@chubaka:~$ md5sum /tmp/half_sparse /mnt/iso/half_sparse
> 3e98c342558c453b379cf7699f98a108 /tmp/half_sparse
> Segmentation fault
Hah ! The obvious bug about all-zero blocks has bitten.
I would not have expected a memory fault, though. Rather some false
output
Hi,
after some confusion i found out that the endianness bug was fixed
unnoticed a few weeks ago, when i implemented zisofs version 2. The
current GNU xorriso development tarball has it already fixed.
https://www.gnu.org/software/xorriso/xorriso-1.5.3.tar.gz
Anatoly Pugachev wrote:
> copied
Hi,
Anatoly Pugachev wrote directly to me:
> sent you an ISO file with another account...
Now that's embrassing. My zisofs compressor did put out the zisofs
block pointers into the file as big-endian 32-bit numbers, where
everybody expects little-endian.
So the bread() call in the kernel which
Hi,
Anatoly Pugachev wrote:
> copied to my local x86 VM:
> mator@u164:~> sudo mount -o loop,ro test.iso /mnt
> mator@u164:~> md5sum /mnt/1mb
> md5sum: /mnt/1mb: Input/output error
Grrr. This is not supposed happen. (I tested this here. Grrr, again.)
> probably xorriso wrote a wrong iso on ppc64
Hi,
to answer my own question whether bytes were delivered:
The strace shows that there were none. The first read of 32 KiB already
fails. Hopefully a useful hint.
Have a nice day :)
Thomas
Hi,
Anatoly Pugachev wrote:
> mator@chubaka:~$ getconf PAGESIZE
> 65536
> mator@chubaka:~$ uname -a
> Linux chubaka 5.9.0-1-powerpc64 #1 SMP Debian 5.9.1-1 (2020-10-17)
> ppc64 GNU/Linux
> [...]
> mator@chubaka:~$ md5sum /mnt/1mb
> md5sum: /mnt/1mb: Input/output error
Does it deliver any bytes
Hi,
John Paul Adrian Glaubitz wrote:
> Valgrind didn't find any memory leaks, so I'm currently out of ideas:
> [..] valgrind --leak-check=yes ./parted_server
> [...]
> ==280387== in use at exit: 0 bytes in 0 blocks
I had a look at the code and wonder how the variable "device_name"
gets freed
Hi,
Anatoly Pugachev wrote:
> > > $ ssh gcc203 getconf PAGESIZE
> > > 65536
I wrote:
> > If there is a machine of that kind which can be used for a short bitrot
> > test of the existing kernel with CONFIG_ZISOFS=y (which is usually already
> > set), i'd be glad to propose a few shell commands
Hi,
Anatoly Pugachev wrote:
> $ ssh gcc203 getconf PAGESIZE
> 65536
> [...]
> thouse gcc* machines are from 'gcc compile farm' [1] , ppc64 or ppc64le
Ah yes. That's probably what i ask about.
arch/powerpc/include/asm/page.h
/* ... For PPC64 we support either 4K or 64K software page size. ...
Hi,
by incident one of my other kernel adventures leads me here, although
it might turn out to be off topic, as i know too few about powerpc.
Are there machines in use which really have regular memory page size
larger than 32 KiB ?
I read in Linux source
arch/powerpc/include/asm/page.h
this
Hi,
if nothing else helps:
What happens if you destroy the Apple Partition Map of the ISO before you
burn it to the CD.
cp debian-10.0.0-powerpc-NETINST-1.iso test.iso
dd if=/dev/zero conv=notrunc bs=2048 count=16 of=test.iso
... burn test.iso with SAO ...
This won't boot. But maybe it
Hi,
> Can you guys try it please? I am lost here.
On amd64 Debian:
# mount debian-10.0.0-powerpc-NETINST-1.iso.1 /mnt/iso
mount: /dev/loop0 is write-protected, mounting read-only
$ tar cf - /mnt/iso | dd bs=2K of=/dev/null
tar: Removing leading `/' from member names
158930+0 records
Hi,
Jeroen Diederen wrote:
> If I boot and try to mount the CDROM it fails again to mount the CDROM
> but I don't see the kernel messages as before.
> [...]
> I tried several ways of burning this image now, always failing to be
> mounted. I also tried an iBook G4, with the same result.
This
Hi,
i wrote:
> > [PATCH 0/3] Fix the old CD read-ahead bug for media with a single TAO
> > track
John Paul Adrian Glaubitz wrote:
> I would definitely support that effort. [...]
> So feel free to post your patches to the corresponding LKML and put me in
> CC,
Will do. Let's wait
Hi,
Jeroen Diederen wrote:
> kernel: [timestamp] sr 1:0:0:0: [sr0] tag#0 Sense Key : Illegal Request
> kernel: [timestamp] sr 1:0:0:0: [sr0] tag#0 Add. Sense: Illegal mode for
> this track
> ...
> kernel: [timestamp] attempt to access beyond end device
> kernel: [timestamp] sr0: rw=0, want
Hi,
John Paul Adrian Glaubitz wrote:
> Tools like Rufus make weird assumptions and it has happened more
> than once that one of these imaging tools create unusuable installation
> media [1].
That's the other mode of Rufus, which unpacks the ISO onto the USB stick,
interprets its bootloader menu,
Hi,
Sam Imberman wrote:
> I burnt the image using Rufus on Windows,
Rufus' "dd" mode is known to be suitable.
The displayed size of /dev/sdb1 matches what i would expect from a correct
plain copy.
So i think this part succeeded.
> For the moment I've managed to 'solve' the problem by using the
Hi,
John Paul Adrian Glaubitz wrote:
> Please use the latest image I created yesterday:
> https://cdimage.debian.org/cdimage/ports/snapshots/2020-10-13/debian-10.0.0-powerpc-NETINST-1.iso
This contains 1 mountable partition in MBR and 3 partitions in an
Apple Partition Map (APM), of which
Hi,
i wrote:
> > If a file CD1/System/Library/CoreServices/BootX had existed on hard disk,
> > the pathspec "CD1" would have overwritten the previously inserted IsoNode
> > object which held the instruction to copy from "grub.chrp".
John Paul Adrian Glaubitz wrote:
> But there is no file
Hi,
Mark Cave-Ayland wrote:
> Right, these graft points are unnecessary - if you look at the BootX file on
> the ISO then it's simply a pointer to /boot/grub/powerpc-ieee1275/grub.chrp
They are copy siblings. libisofs knew that they came from the same hard
disk inode and thus decided to store
Hi,
Mark Cave-Ayland wrote:
> Hi Adrian, [...]
> In the last thread you listed the options as:
The actually used options can be seen in a debian-cd specific data file
of the ISO:
mount debian-10.0-powerpc-grub-NETINST-1.iso /mnt/iso
cat /mnt/iso/.disk/mkisofs
yields in a single line which
Hi,
John Paul Adrian Glaubitz wrote:
> Looking at the grub-mkrescue.c source, I figured the proper linking would
> be:
> xorriso_link ("/System/Library/CoreServices/grub.elf",
> "/boot/grub/powerpc-ieee1275/core.elf");
In the end it produces this pathspec
Hi,
John Paul Adrian Glaubitz wrote:
> On the other hand, having HFS support in libisofs is still desirable
> for OldWorld Macs and m68k Macs,
(We should better not tell the Fridays-For-Future kids. The MIPS/Watt
ratio must be subterran.)
> Looking at grub-mkrescue [1], I assume the options
Hi,
i notice that i sent this to the wrong thread of debian-powerpc
and did not Cc the intended other receivers. So again.
John Paul Adrian Glaubitz wrote:
> > What about a funding? I would actually be willing to shell out
Hi,
John Paul Adrian Glaubitz wrote:
> > What about a funding? I would actually be willing to shell out some money
Mark Cave-Ayland wrote:
> Certainly if there were some funding available, this is something that I
> could look at if required.
If you do, i am ready for giving advise about
Hi,
John Paul Adrian Glaubitz wrote:
> > Odd. I just ran this command on Debian/powerpc but it didn't produce any
> > output file but also no error message.
> Ah, grub-mkrescue needs xorriso as a dependency.
I wonder why this gesture of grub-mkrescue did not tell you:
if (!check_xorriso
Hi,
aggaz wrote:
> Are ISO images capable to boot with GRUB instead of yaboot already
> available for the masses? If so I would like to try to boot one.
There is a GRUB_INSTALL_PLATFORM_POWERPC_IEEE1275 for which
grub-mkrescue produces bootable ISOs. I understand that the ISO gets
prepared with
Hi,
i wrote:
> > [...] Fedora HFS image [...]
> > I think Fedora uses hfsutils to create and populate it.
> My colleague Marcus Schaefer at SUSE told me
> about this solution. He's the maintainer of SUSE's KIWI image tool (but
> I think you know that ;)).
I had contact with him last year.
> We
Hi,
John Paul Adrian Glaubitz wrote:
> Btw, I was wondering how much it would take to add HFS support to
> xorriso but I guess the necessary changes are so extensive which
> is why it's not been done yet.
I obtained (hopefully complete) HFS specs and had to learn that it is
not easily
Hi,
i
wrote:
> > One could do it with HFS like Fedora ISO does with HFS+.
> > A small HFS+ filesystem image is marked in APM as Apple_HFS. In the ISO
> > it has the name /images/macboot.img.
Frank Scheiner wrote:
> Is that the same method as what `mkfs.hfs` can do with option:
> -w Adds an
Hi,
John Paul Adrian Glaubitz wrote:
> So, the first question is whether xorriso supports HFS volumes
No. Only HFS+, contributed by Vladimir Serbinenko for x86 Macs and
used in grub-mkrescue ISOs for x86 EFI.
The xorrisofs options used by grub-mkrescue for HFS+ are:
-hfsplus
-apm-block-size
39 matches
Mail list logo
