>> How can the installation system eat so much memory?
>
> It shouldn't. There is even a lowmem udeb which reduces the memory footprint
> [1].
>
> I could even install with debian-installer on my Amiga 1200 with 64 MiB.
>
> Please don't necessarily take tests on qemu as a reference. Rather
On 28/04/2019 13:35, John Paul Adrian Glaubitz wrote:
> On 4/28/19 11:13 AM, Mark Cave-Ayland wrote:
>>> I'm not sure this is actually required. debian-installer does actually have
>>> a low-mem
>>> installation mode with which I could the system even on 64 MiB.
>>
>> Oh I didn't know that! From
On 4/28/19 11:13 AM, Mark Cave-Ayland wrote:
>> I'm not sure this is actually required. debian-installer does actually have
>> a low-mem
>> installation mode with which I could the system even on 64 MiB.
>
> Oh I didn't know that! From memory when you first started the ports images the
> minimum
On 4/28/19 11:10 AM, Thomas Schmitt wrote:
> John Paul Adrian Glaubitz wrote:
>> You are very welcome to create a guest account for Debian Salsa
>
> I already have one for xorriso related package preparation.
Ok, great!
>> and open
>> merge requests for the debian-installer and debian-cd
On 28/04/2019 09:49, John Paul Adrian Glaubitz wrote:
> On 4/28/19 10:33 AM, Mark Cave-Ayland wrote:
https://cdimage.debian.org/cdimage/ports/grub-test/
>>
>> I grabbed the test image from the above URL to test under
>> qemu-system-sparc64 and
>> initially got the error below:
>
> Please
Hi,
John Paul Adrian Glaubitz wrote:
> You are very welcome to create a guest account for Debian Salsa
I already have one for xorriso related package preparation.
> and open
> merge requests for the debian-installer and debian-cd projects [1].
It is more about weighing the options and their
On 4/28/19 10:40 AM, Gregor Riepl wrote:
> That's pretty bad!
>
> I stuffed my old Ultra 10 with 512MB, but the machine originally came with
> only 256MB.
>
> How can the installation system eat so much memory?
It shouldn't. There is even a lowmem udeb which reduces the memory footprint
[1].
On 4/28/19 10:33 AM, Mark Cave-Ayland wrote:
>>> https://cdimage.debian.org/cdimage/ports/grub-test/
>
> I grabbed the test image from the above URL to test under qemu-system-sparc64
> and
> initially got the error below:
Please note: This image is not particularly tested with regards the
> Apr 28 08:11:44 debconf: Setting debconf/priority to medium
> Apr 28 08:11:44 kernel: [ 135.647875] main-menu[242]: segfault at 8 ip
> 0100298c (rpc f80100128e08) sp 07feff83ead1 error 1 in
> main-menu[100+4000]
>
> After some further poking it looks like the latest
On 28/04/2019 08:44, John Paul Adrian Glaubitz wrote:
> On 4/28/19 9:25 AM, Mark Cave-Ayland wrote:
Thanks everyone for the help!
>>>
>>> Attaching the two patches for debian-installer and debian-cd for reference,
>>> will commit them next week after cleaning them up and also switching ia64
Hi!
On 4/28/19 10:20 AM, Thomas Schmitt wrote:
> Interesting. I never had an ISO for Itanium.
> Looks very similar to the Debian arm64 ISOs. Much neater MBR partition
> table than i386 and amd64 ISOs.
>
> I still see room for improvements (for arm64 too):
>
> - Use xorrisofs option
Hi,
John Paul Adrian Glaubitz wrote:
> there is also a test image for ia64 with GRUB
> https://cdimage.debian.org/cdimage/ports/grub-test/
Interesting. I never had an ISO for Itanium.
Looks very similar to the Debian arm64 ISOs. Much neater MBR partition
table than i386 and amd64 ISOs.
I still
On 4/28/19 9:25 AM, Mark Cave-Ayland wrote:
>>> Thanks everyone for the help!
>>
>> Attaching the two patches for debian-installer and debian-cd for reference,
>> will commit them next week after cleaning them up and also switching ia64
>> to GRUB as well.
>
> Amazing - thank you for all the hard
On 27/04/2019 20:39, John Paul Adrian Glaubitz wrote:
> On 4/27/19 9:30 PM, John Paul Adrian Glaubitz wrote:
>> On 4/27/19 9:08 PM, Thomas Schmitt wrote:
>>> Maybe you should prepend 512 0-bytes to your cdboot.img.
>>
>> Yes, indeed that did the trick. The uploaded image now works
>> correctly
On 4/27/19 11:12 PM, Thomas Schmitt wrote:
> The ISO is now added to my collection of bootable ISOs for regression
> test. My test loop checks whether the ISOs which are repacked from
> existing ISOs still show the same boot equipment and file tree content.
> (Happens when i change boot related
Hi,
> PS: You can fetch the image from the known location to test
Looks good. Viewing xorriso arguments in /mnt/iso/.disk/mkisofs ...
looks good too.
The ISO is now added to my collection of bootable ISOs for regression
test. My test loop checks whether the ISOs which are repacked from
existing
On 4/27/19 9:30 PM, John Paul Adrian Glaubitz wrote:
> On 4/27/19 9:08 PM, Thomas Schmitt wrote:
>> Maybe you should prepend 512 0-bytes to your cdboot.img.
>
> Yes, indeed that did the trick. The uploaded image now works
> correctly and boots with GRUB on CD. We can finally get rid
> of SILO
On 4/27/19 9:08 PM, Thomas Schmitt wrote:
> Maybe you should prepend 512 0-bytes to your cdboot.img.
Yes, indeed that did the trick. The uploaded image now works
correctly and boots with GRUB on CD. We can finally get rid
of SILO \o/.
Thanks everyone for the help!
PS: You can fetch the image
Hi,
i wrote:
> grub-mkrescue copies stuff to bytes 512 to 767 of its -G image.
It's 512 to 1023, of course.
Have a nice day :)
Thomas
Hi,
there is a copy of the -G image file in the ISO:
/boot/grub/sparc64-ieee1275/cdboot.img
It has only 512 bytes. Very non-zero.
But block 0 is for the SUN disk label (partition table).
libisofs overwrites it completely at ISO production time.
See
On 27/04/2019 19:26, Thomas Schmitt wrote:
> Hi,
>
> xorriso-wise, the debian-10.0-sparc64-grub-NETINST-1.iso looks ok:
>
> $ xorriso -indev debian-10.0-sparc64-grub-NETINST-1.iso \
> -report_system_area plain
> ...
> Volume id: 'Debian 10.0 sparc64 n'
> System area
Hi,
xorriso-wise, the debian-10.0-sparc64-grub-NETINST-1.iso looks ok:
$ xorriso -indev debian-10.0-sparc64-grub-NETINST-1.iso \
-report_system_area plain
...
Volume id: 'Debian 10.0 sparc64 n'
System area options: 0x000c
System area summary: SUN-SPARC-Disk-Label
Hi,
John Paul Adrian Glaubitz:
> xorriso -as mkisofs -r -checksum_algorithm_iso md5,sha1
> -V 'Debian 10.0 sparc64 n'
> -o /home/glaubitz/debian-cd-test/debian-10.0-sparc64-NETINST-1.iso
> -J -joliet-long -cache-inodes
> -G /home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/sparc64-ieee1275/cdboot.img
>
Hi,
> xorriso -as mkisofs -r -checksum_algorithm_iso md5,sha1
> -V 'Debian 10.0 sparc64 n'
> -o /home/glaubitz/debian-cd-test/debian-10.0-sparc64-NETINST-1.iso
> -J -joliet-long -cache-inodes
> -G /home/glaubitz/tmp/sid/CD1/../CD1/boot/grub/sparc64-ieee1275/cdboot.img
> -B ...
>
On 4/27/19 7:16 PM, John Paul Adrian Glaubitz wrote:
> xorriso -as mkisofs -r -checksum_algorithm_iso md5,sha1 -V 'Debian 10.0
> sparc64 n' -o /home/glaubitz/debian-cd-test/debian-10.0-sparc64-NETINST-1.iso
> -J -joliet-long -cache-inodes -G
>
On 4/27/19 7:25 PM, Mark Cave-Ayland wrote:
> I think it's trying to find /boot/grub/core.img in the ISO image built from
> your CD1
> directory and failing - did you also update grub-mkimage in your first patch
> so that
> the core image is output as core.img and not sparc64.elf?
Yes, of
On 4/27/19 7:11 PM, Thomas Schmitt wrote:
> $ xorriso -as mkisofs \
> -o test.iso \
> -V 'FAKE_SPARC_64_ISO' \
> -J -joliet-long -cache-inodes -l \
> -G ./dummy_for_G \
> -B '...' \
> --grub2-sparc-core /boot/grub/core.img \
> -graft-points \
>
On 27/04/2019 18:12, John Paul Adrian Glaubitz wrote:
> On 4/27/19 6:47 PM, Thomas Schmitt wrote:
>> Mark Cave-Ayland wrote:
>>> In that case I think the change for Adrian's second patch should in fact be
>>> this:
>>> add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-G cdboot.img -B ...
>>>
On 4/27/19 7:11 PM, Thomas Schmitt wrote:
> John Paul Adrian Glaubitz wrote:
>> -J -joliet-long -cache-inodes -l
>> -G $CDDIR/../CD1/boot/grub/sparc64-ieee1275/cdboot.img -B ...
>>
>> Would it be enough to just switch to xorriso here?
>
> I think you forgot -o result.o and -V Volume_Id.
Those
On 4/27/19 6:47 PM, Thomas Schmitt wrote:
> Mark Cave-Ayland wrote:
>> In that case I think the change for Adrian's second patch should in fact be
>> this:
>> add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-G cdboot.img -B ...
>> --grub2-sparc-core /boot/grub/core.img"
>>
>> Does that look better?
>
Hi,
John Paul Adrian Glaubitz wrote:
> -J -joliet-long -cache-inodes -l
> -G $CDDIR/../CD1/boot/grub/sparc64-ieee1275/cdboot.img -B ...
>
> Would it be enough to just switch to xorriso here?
I think you forgot -o result.o and -V Volume_Id.
They are all in the list of emulated options (xorriso
Hi,
Mark Cave-Ayland wrote:
> In that case I think the change for Adrian's second patch should in fact be
> this:
> add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-G cdboot.img -B ...
> --grub2-sparc-core /boot/grub/core.img"
>
> Does that look better?
If /boot/grub/core.img is the path of the next
On 4/27/19 5:40 PM, Thomas Schmitt wrote:
>> Once this is done and the ISO image is generated, [...]
>> - Next check the offset and size of /boot/grub/core.img embedded in
>> sector 1 using dd and hexdump. As per Thomas' message you should find
>> the offset in bytes of the start of
On 27/04/2019 17:21, John Paul Adrian Glaubitz wrote:
> On 4/27/19 5:35 PM, Mark Cave-Ayland wrote:
>>> I set $CDDIR to the source directory which contains core.img? How does the
>>> initial
>>> bootloader know that it has to boot core.img?
>>
>> This is the part which Thomas explained: the
On 4/27/19 5:35 PM, Mark Cave-Ayland wrote:
>> I set $CDDIR to the source directory which contains core.img? How does the
>> initial
>> bootloader know that it has to boot core.img?
>
> This is the part which Thomas explained: the offset of core.img *as embedded
> within
> the ISO filesystem
On 27/04/2019 16:40, Thomas Schmitt wrote:
> Hi,
>
> Mark Cave-Ayland wrote:
>> - In your second patch re-enable the -G/-B options but with -G set to
>> cdboot.img:
>> add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-G cdboot.img -B ..."
>
> Does this refer to
> From: John Paul Adrian Glaubitz
Hi!
On 4/27/19 5:02 PM, Mark Cave-Ayland wrote:
> Adrian: based upon this I think what you need to do is:
>
> - For consistency rename /boot/grub/sparc64.elf to /boot/grub/core.img to
> match
> the descriptions of the grub components in the documentation
Ok. But still generate it with
On 26/04/2019 18:04, Thomas Schmitt wrote:
> Hi,
>
>> - the first 32K of an ISO9660 is undefined
>
> That's such a negative word. :))
> It is "reserved for system use" and "not specified" by ISO 9660 / ECMA-119.
>
>
>> - boot.S and diskboot.S get built into cdboot.img
>
> grub-mkrescue opens
Hi,
> - the first 32K of an ISO9660 is undefined
That's such a negative word. :))
It is "reserved for system use" and "not specified" by ISO 9660 / ECMA-119.
> - boot.S and diskboot.S get built into cdboot.img
grub-mkrescue opens cdboot.img for reading and the image file for -G
for writing
On 25/04/2019 12:58, Thomas Schmitt wrote:
> Hi,
>
> John Paul Adrian Glaubitz wrote:
>> I have read the genisoimage manpage and I have to admit, I haven't fully
>> understood
>> yet how it is supposed to work. It seems we have to specify the bootloader
>> code
>> with -G, thus -G cdboot.img.
Hi Thomas!
On 4/25/19 1:58 PM, Thomas Schmitt wrote:
>
> (snip)
>
> I hope this helps to get more insight. More background might be known
> to Vladimir.
Thanks, that looks very useful. I will have a look and try to understand
how CD boot with GRUB is supposed to work. I have also posted that
Hi,
John Paul Adrian Glaubitz wrote:
> I have read the genisoimage manpage and I have to admit, I haven't fully
> understood
> yet how it is supposed to work. It seems we have to specify the bootloader
> code
> with -G, thus -G cdboot.img. But -B is apparently used to pass a whole
> directory
On 4/25/19 9:30 AM, Mark Cave-Ayland wrote:
> Ah now I see - since your PROM supports gpt directly then that's how boot.S
> works.
> Presumably then it must be diskboot.S with blocklist support that gets used
> for older
> machines such as QEMU's sun4u?
Makes sense, yes.
> Okay so reviewing
On 25/04/2019 07:50, John Paul Adrian Glaubitz wrote:
> On 4/25/19 8:40 AM, Mark Cave-Ayland wrote:
>> When grub is installed to disk as per your latest ISO images, what is the
>> filesystem/partition type being used?
> For GPT-based partitioning, we have a dedicated GRUB boot partition:
>
>
On 4/25/19 8:40 AM, Mark Cave-Ayland wrote:
> When grub is installed to disk as per your latest ISO images, what is the
> filesystem/partition type being used?
For GPT-based partitioning, we have a dedicated GRUB boot partition:
(parted) p
On 25/04/2019 07:29, John Paul Adrian Glaubitz wrote:
> On 4/25/19 8:07 AM, Mark Cave-Ayland wrote:
>>> Yes, that would be most likely the sparc64.elf image that grub-mkimage
>>> produces. But
>>> I don't know yet how to encode the boot path for that into the bootable
>>> image.
>>
>> I'm
On 4/25/19 8:07 AM, Mark Cave-Ayland wrote:
>> Yes, that would be most likely the sparc64.elf image that grub-mkimage
>> produces. But
>> I don't know yet how to encode the boot path for that into the bootable
>> image.
>
> I'm struggling to see from the man pages the relationship between
On 25/04/2019 06:54, John Paul Adrian Glaubitz wrote:
> On 4/25/19 7:23 AM, Mark Cave-Ayland wrote:
>> Oh wait, now I see it: SILO's isofs.b also includes a mini-ISO9660 driver to
>> enable
>> the PROM to read from the CDROM. So given that grub on SPARC64 is already
>> working for
>> a disk
On 4/25/19 7:23 AM, Mark Cave-Ayland wrote:
> Oh wait, now I see it: SILO's isofs.b also includes a mini-ISO9660 driver to
> enable
> the PROM to read from the CDROM. So given that grub on SPARC64 is already
> working for
> a disk install then this aspect should already have been solved i.e.
On 4/25/19 6:18 AM, Mark Cave-Ayland wrote:
> FWIW I think you're pretty close here: as you say, you just need to fix the
> bits
> which set up a sun partition label and inject the bootloader. So the bit you
> need to
> re-enable to get this to work should be this:
>
> add_mkisofs_opt
On 25/04/2019 05:18, Mark Cave-Ayland wrote:
> On 24/04/2019 23:05, John Paul Adrian Glaubitz wrote:
>
>> Okay, so I have managed to build an image now, that's the good news:
>>
>>> https://people.debian.org/~glaubitz/debian-10.0-sparc64-grub-NETINST-1.iso
>>
>> The bad news is, it doesn't boot
On 24/04/2019 23:05, John Paul Adrian Glaubitz wrote:
> Okay, so I have managed to build an image now, that's the good news:
>
>> https://people.debian.org/~glaubitz/debian-10.0-sparc64-grub-NETINST-1.iso
>
> The bad news is, it doesn't boot yet:
>
> {0} ok boot cdrom
> Boot device:
Okay, so I have managed to build an image now, that's the good news:
> https://people.debian.org/~glaubitz/debian-10.0-sparc64-grub-NETINST-1.iso
The bad news is, it doesn't boot yet:
{0} ok boot cdrom
Boot device: /virtual-devices@100/channel-devices@200/disk@1 File and args:
ERROR:
On 24/04/2019 21:30, Frank Scheiner wrote:
> On 4/24/19 22:07, John Paul Adrian Glaubitz wrote:
>> On 4/24/19 9:46 PM, Mark Cave-Ayland wrote:
>>> For reference the CHRP bootinfo.txt isn't a configuration file, but is
>>> actually
>>> parsed by CHRP-compliant open firmwares directly - SPARC
Closing as the bug report is obviously invalid as bootinfo.txt is not
required on sparc and sparc64.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546
(Leave the bug tracker, I'll close the bug)
On 4/24/19 10:43 PM, Mark Cave-Ayland wrote:
> Is it possible to see the source for sparc64-ieee1275-cdcore anywhere? A
> quick search
> doesn't return anything obvious.
The regular grub2 packaging source is on salsa, see:
On 4/24/19 22:07, John Paul Adrian Glaubitz wrote:
> On 4/24/19 9:46 PM, Mark Cave-Ayland wrote:
>> For reference the CHRP bootinfo.txt isn't a configuration file, but is
>> actually
>> parsed by CHRP-compliant open firmwares directly - SPARC firmwares, including
>> OpenBIOS don't support them.
On 4/24/19 9:46 PM, Mark Cave-Ayland wrote:
> For reference the CHRP bootinfo.txt isn't a configuration file, but is
> actually
> parsed by CHRP-compliant open firmwares directly - SPARC firmwares, including
> OpenBIOS don't support them. Can you explain why grub on SPARC is trying to
> access
>
58 matches
Mail list logo
