Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #224930 > unrolled thread

Final CDs being written for Stretch - 9.13 release - prior to LTS

Back to article view | Back to linux.debian.user

Contents

  Final CDs being written for Stretch - 9.13 release - prior to LTS Andrew Cater <amacater@gmail.com> - 2020-07-18 19:20 +0200
    Re: Final CDs being written for Stretch - 9.13 release - prior to LTS "Thomas Schmitt" <scdbackup@gmx.net> - 2020-07-18 20:00 +0200
      Re: Final CDs being written for Stretch - 9.13 release - prior to LTS Andrew Cater <amacater@gmail.com> - 2020-07-18 23:10 +0200
        Re: Final CDs being written for Stretch - 9.13 release - prior to LTS "Thomas Schmitt" <scdbackup@gmx.net> - 2020-07-19 00:00 +0200
        Re: Final CDs being written for Stretch - 9.13 release - prior to LTS Dan Ritter <dsr@randomstring.org> - 2020-07-19 01:20 +0200
          Re: Final CDs being written for Stretch - 9.13 release - prior to  LTS Tixy <tixy@yxit.co.uk> - 2020-07-19 19:10 +0200
            Re: Final CDs being written for Stretch - 9.13 release - prior to LTS Dan Ritter <dsr@randomstring.org> - 2020-07-19 19:50 +0200
              Re: Final CDs being written for Stretch - 9.13 release - prior to  LTS Tixy <tixy@yxit.co.uk> - 2020-07-19 20:10 +0200
            Re: Final CDs being written for Stretch - 9.13 release - prior to LTS Peter Ehlert <peter@sdi-baja.com> - 2020-07-19 20:00 +0200
            Re: Final CDs being written for Stretch - 9.13 release - prior to LTS Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-19 22:30 +0200
              Re: Final CDs being written for Stretch - 9.13 release - prior to LTS David Wright <deblis@lionunicorn.co.uk> - 2020-07-20 01:50 +0200
                Re: Final CDs being written for Stretch - 9.13 release - prior to LTS Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-20 05:40 +0200
                  Re: Final CDs being written for Stretch - 9.13 release - prior to LTS "Thomas Schmitt" <scdbackup@gmx.net> - 2020-07-20 09:10 +0200
                    Re: Final CDs being written for Stretch - 9.13 release - prior to LTS Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-20 16:30 +0200
                      Re: Final CDs being written for Stretch - 9.13 release - prior to LTS Andrew Cater <amacater@gmail.com> - 2020-07-20 17:40 +0200
                        Re: Final CDs being written for Stretch - 9.13 release - prior to LTS Peter Ehlert <peter@sdi-baja.com> - 2020-07-20 18:50 +0200
                        Re: Final CDs being written for Stretch - 9.13 release - prior to LTS "Thomas Schmitt" <scdbackup@gmx.net> - 2020-07-20 19:00 +0200
                      Re: Final CDs being written for Stretch - 9.13 release - prior to LTS "Thomas Schmitt" <scdbackup@gmx.net> - 2020-07-20 18:30 +0200
              Re: Final CDs being written for Stretch - 9.13 release - prior to LTS Gene Heskett <gheskett@shentel.net> - 2020-07-20 02:10 +0200
              Re: Final CDs being written for Stretch - 9.13 release - prior to  LTS Tixy <tixy@yxit.co.uk> - 2020-07-20 09:30 +0200
                Re: Final CDs being written for Stretch - 9.13 release - prior to LTS Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-20 16:40 +0200
        Re: Final CDs being written for Stretch - 9.13 release - prior to LTS Stefan Monnier <monnier@iro.umontreal.ca> - 2020-07-19 05:00 +0200
    Re: Final CDs being written for Stretch - 9.13 release - prior to LTS songbird <songbird@anthive.com> - 2020-07-18 21:00 +0200

Page 1 of 2  [1] 2  Next page →

#224930 — Final CDs being written for Stretch - 9.13 release - prior to LTS

[Multipart message — attachments visible in raw view] — view raw

As folk will be aware: we're building and releasing the final release of
Stretch before transition to LTS support. Testing is going well - there are
a couple of architectures that are built but not tested because the testers
have no hardware.

One set  is an old Mac on Intel media, the other is boot media for S390X.
Nobody has reported problems with these recently but it may be that nobody
is using them at all. If this is the case, these are prime candidates for
removal before Bullseye - Debian 11 - media preparation

Please shout: if we don't build media for obsolete hardware or machines
that nobody has, it makes the complex task of preparing media that much
simpler.

[toc] | [next] | [standalone]

#224931

Hi,

Andrew Cater wrote:
> [...] here are
> a couple of architectures that are built but not tested because the testers
> have no hardware.
> One set  is an old Mac on Intel media,

Do you mean these ?
  https://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-mac-10.4.0-i386-netinst.iso
  https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-mac-10.4.0-amd64-netinst.iso

They are related to
  https://wiki.debian.org/MacMiniIntel#Macmini_1.2C1
and following sections.

-------------------------------------------------------------------------

If it is not about above "mac" ISOs, which then ? I am curious.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#224946

[Multipart message — attachments visible in raw view] — view raw

Thank you Thomas. Yes, that's obviously why it was done.So - a quick look
on Wikipedia suggests that this was a current machine in 2006 and was
replaced in 2007 / 2008. So - if anyone has one running anywhere, it's
somewhere between 12-15 years old. If anybody knows of any that they really
must keep running, speak now or forever hold your peace. It's probably time
for this to be dropped for Bullseye.

Separately, we also had a quick think about the numbers of iso images in
general. A suggestion: For the future, we should produce physical media for
the netinst.iso, the first DVD image in any set and one larger image to be
written to a USB stick if wanted - and corresponding source for each size.
All other .iso files to be distributed as .jigdo and .template files.In
most instances, the netinst is enough, if you have network connectivity and
bandwidth. The DVD is enough to install the basis of any of the graphical
environments readily. This does not mean that you couldn't produce every
other image - but very few people are on a desert island and need every
piece of software Debian has produced on physical media.  Producing every
disk in every size would still be possble but using jigdo as an
intermediate step. This would also mean dropping the single CD image that
installs the XFCE graphical environment but that's one tasksel selection
away anyway. This would ease the pressure on mirrors and the main
cdimage.debian.org server and make the task of testing significantly
simpler.

New users find it difficult to work out why there should be so many DVDs
and whether they need to download them all even though only one is
bootable. Anything we can do to make our collective lives easier is a
bonus, given the size of the team. Thoughts?



On Sat, Jul 18, 2020 at 5:55 PM Thomas Schmitt <scdbackup@gmx.net> wrote:

> Hi,
>
> Andrew Cater wrote:
> > [...] here are
> > a couple of architectures that are built but not tested because the
> testers
> > have no hardware.
> > One set  is an old Mac on Intel media,
>
> Do you mean these ?
>
> https://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-mac-10.4.0-i386-netinst.iso
>
> https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-mac-10.4.0-amd64-netinst.iso
>
> They are related to
>   https://wiki.debian.org/MacMiniIntel#Macmini_1.2C1
> and following sections.
>
> -------------------------------------------------------------------------
>
> If it is not about above "mac" ISOs, which then ? I am curious.
>
>
> Have a nice day :)
>
> Thomas
>
>

[toc] | [prev] | [next] | [standalone]

#224952

Hi,

Andrew Cater wrote:
> If anybody knows of any [Mac Mini] that they really must keep
> running, speak now or forever hold your peace.

It is possible to create an ISO without EFI boot lures from a normal
i386 or amd64 ISO.
Follow
  https://wiki.debian.org/RepackBootableISO
but leave out the options beginning with
  -eltorito-alt-boot

Others seem to have solved their mini mac problems similarly
  https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface#Remove_UEFI_boot_support_from_optical_media


> For the future, we should produce physical media for
> the netinst.iso, the first DVD image in any set and one larger image to be
> written to a USB stick if wanted - and corresponding source for each size.

A large image for USB stick or 25 GB Blu-ray would help those with
insufficient network access at installation time.


> All other .iso files to be distributed as .jigdo and .template files.

Most DVD images and images for all larger media are already only available
via .jigdo.

Jigdo's software status is healthy. But we need better documentation and more
advertising for it. How about a jigdo help file in the download directories
with .jigdo files, which tells how to get the download software and how to
use it.

Steve McIntyre offers binaries for MS-Windows and source at
  https://www.einval.com/~steve/software/jigdo/download/
I documented the endeavor of getting and booting a Debian Live for the
purpose of downloading jigdo ISOs in
  https://wiki.debian.org/JigdoOnLive
(Still lacking knowledge about how to mount foreign OS disks for writing.)
Then there is
  https://www.debian.org/CD/jigdo-cd/
We could need a list of distros and names of their packages which contain
jigdo-lite.

This all should be mashed up and condensed to a tangible description what
to do with the presented .jigdo and .template files.


There is also the fact that due to network and server latency the download
on a fast internet connection via jigdo is much slower than direct download
via HTTPS.
(Netinst installation might have the same drawbacks. How much faster is
 installation from a 32 GB USB stick in comparison to netinst ?)


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#224954

Andrew Cater wrote: 
> Separately, we also had a quick think about the numbers of iso images in
> general. A suggestion: For the future, we should produce physical media for
> the netinst.iso, the first DVD image in any set and one larger image to be
> written to a USB stick if wanted - and corresponding source for each size.
> All other .iso files to be distributed as .jigdo and .template files.In
> most instances, the netinst is enough, if you have network connectivity and
> bandwidth. The DVD is enough to install the basis of any of the graphical
> environments readily. This does not mean that you couldn't produce every
> other image - but very few people are on a desert island and need every
> piece of software Debian has produced on physical media.


At this point in 2020, I think it would be reasonable to only produce
netinst images and jigdo (and live, but that's a different-ish
project). Drop the DVD images.

All of my installs in the last six years have either been via a
USB netinst image or PXE. New laptops and desktops are generally
shipping without optical drives at all. My oldest non-toy
hardware can boot via USB. 

-dsr-

[toc] | [prev] | [next] | [standalone]

#224989 — Re: Final CDs being written for Stretch - 9.13 release - prior to LTS

On Sat, 2020-07-18 at 18:48 -0400, Dan Ritter wrote:
> At this point in 2020, I think it would be reasonable to only produce
> netinst images and jigdo (and live, but that's a different-ish
> project). Drop the DVD images.
[...]

Though this doesn't apply to me, I can imagine a fair few people in the
world who don't have access to fast, cheap internet who would
appreciate a DVD image that they can simply download somewhere where
they can get good internet. e.g. library, work, education
establishment. Or could get someone else to do that and mail it.

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#224996

Tixy wrote: 
> On Sat, 2020-07-18 at 18:48 -0400, Dan Ritter wrote:
> > At this point in 2020, I think it would be reasonable to only produce
> > netinst images and jigdo (and live, but that's a different-ish
> > project). Drop the DVD images.
> [...]
> 
> Though this doesn't apply to me, I can imagine a fair few people in the
> world who don't have access to fast, cheap internet who would
> appreciate a DVD image that they can simply download somewhere where
> they can get good internet. e.g. library, work, education
> establishment. Or could get someone else to do that and mail it.
 
Effectively, that's what jigdo is. Run a program locally to
download and re-create ISO images.

-dsr-

[toc] | [prev] | [next] | [standalone]

#224998 — Re: Final CDs being written for Stretch - 9.13 release - prior to LTS

On Sun, 2020-07-19 at 13:43 -0400, Dan Ritter wrote:
> Tixy wrote: 
> > On Sat, 2020-07-18 at 18:48 -0400, Dan Ritter wrote:
> > > At this point in 2020, I think it would be reasonable to only
> > > produce
> > > netinst images and jigdo (and live, but that's a different-ish
> > > project). Drop the DVD images.
> > [...]
> > 
> > Though this doesn't apply to me, I can imagine a fair few people in
> > the
> > world who don't have access to fast, cheap internet who would
> > appreciate a DVD image that they can simply download somewhere
> > where
> > they can get good internet. e.g. library, work, education
> > establishment. Or could get someone else to do that and mail it.
>  
> Effectively, that's what jigdo is. Run a program locally to
> download and re-create ISO images.

Except you've got to download and install jigdo at your
library/work/college, or get a non-technical friend to do that, which
may not be permissible or possible. A DVD ISO image is just a file that
anyone can download with just a web browser.

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

#224997

On 7/19/20 9:59 AM, Tixy wrote:
> On Sat, 2020-07-18 at 18:48 -0400, Dan Ritter wrote:
>> At this point in 2020, I think it would be reasonable to only produce
>> netinst images and jigdo (and live, but that's a different-ish
>> project). Drop the DVD images.
> [...]
>
> Though this doesn't apply to me, I can imagine a fair few people in the
> world who don't have access to fast, cheap internet who would
> appreciate a DVD image that they can simply download somewhere where
> they can get good internet. e.g. library, work, education
> establishment. Or could get someone else to do that and mail it.
I fit in that category.
not expensive, but slow
I did a Bullseye net-install a day or two ago.
it crashed many times, finally it worked but took more than 8 hours to 
download.
It was a very long day.
DVD with a Torrent works for us.
>

[toc] | [prev] | [next] | [standalone]

#225011

>> At this point in 2020, I think it would be reasonable to only produce
>> netinst images and jigdo (and live, but that's a different-ish
>> project). Drop the DVD images.

An alternative is to have "virtual ISO images", i.e. images which are
constructed on the fly (presumably by jigdo) on the web-server side.

> Though this doesn't apply to me, I can imagine a fair few people in the
> world who don't have access to fast, cheap internet who would
> appreciate a DVD image that they can simply download somewhere where
> they can get good internet. e.g. library, work, education
> establishment. Or could get someone else to do that and mail it.

I'm not sure why the discussion is always around DVD images.
Would you be equally happy with an image only for a USB flash drive, or
is it important for it to be an image for optical media?

I always found optical media very unappealing, even back when its
capacity and price were strongly in its favor.  Nowadays, I'm having
a hard time imagining a circumstance when it would be a good choice.


        Stefan

[toc] | [prev] | [next] | [standalone]

#225019

On Sun 19 Jul 2020 at 16:25:31 (-0400), Stefan Monnier wrote:
> >> At this point in 2020, I think it would be reasonable to only produce
> >> netinst images and jigdo (and live, but that's a different-ish
> >> project). Drop the DVD images.
> 
> An alternative is to have "virtual ISO images", i.e. images which are
> constructed on the fly (presumably by jigdo) on the web-server side.
> 
> > Though this doesn't apply to me, I can imagine a fair few people in the
> > world who don't have access to fast, cheap internet who would
> > appreciate a DVD image that they can simply download somewhere where
> > they can get good internet. e.g. library, work, education
> > establishment. Or could get someone else to do that and mail it.
> 
> I'm not sure why the discussion is always around DVD images.
> Would you be equally happy with an image only for a USB flash drive, or
> is it important for it to be an image for optical media?
> 
> I always found optical media very unappealing, even back when its
> capacity and price were strongly in its favor.  Nowadays, I'm having
> a hard time imagining a circumstance when it would be a good choice.

There is a generation of machines that can boot from optical media
but not USB sticks. (I have one.) But even in that case, there's no
need to burn anything more than a netinst CD for booting from. The
installed system can then be extended with packages from USBs or
self-made optical media.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#225021

> There is a generation of machines that can boot from optical media
> but not USB sticks. (I have one.)

Indeed, IIRC my macmini-2,1 can boot from USB but only via EFI and not
via "MBR aka BIOS".  And my Thinkpad X30 can boot from a USB floppy but
I never managed to make it boot from a "non-floppy USB Mass Storage".

> But even in that case, there's no need to burn anything more than
> a netinst CD for booting from. The installed system can then be
> extended with packages from USBs or self-made optical media.

Indeed.  Maybe Debian should move further in that direction: focus on
USB installs and provide some "helper CDs" which don't do anything more
than provide something like a GRUB that then lets you boot the Debian
install provided via a USB drive for those rare old machines that can't
boot directly from the USB drive.

The good thing about those helper CDs would be that they could stay
unchanged across many Debian versions.


        Stefan

[toc] | [prev] | [next] | [standalone]

#225024

Hi,

(The mail headers indicate that the OP, Andrew Cater, is subscribed to
 debian-cd but not to debian-user. So replies to debian-user only might
 not get to his attention.)

Stefan Monnier wrote:
> An alternative is to have "virtual ISO images", i.e. images which are
> constructed on the fly (presumably by jigdo) on the web-server side.

Assuming that a complete set of ISOs for whatever medium occupies
at most 100 GB, it seems better to have the images ready rather than to
assemble them on demand, even if the mirror latency and bandwidth are
no problem.
This would spare the nightmare of managing the life cycle of temporary ISOs
on the server. I assume that all images would fit on a single modern HDD.

But the reason for letting the user perform jigdo download is that the network
load vanishes in the normal traffic of the package servers. If download gets
interrupted, one just has to start it again to get the remaining work
completed.
These adavantages for Debian can hardly be uphold by a jigdo assembling
server on Debian side.


> I'm not sure why the discussion is always around DVD images.

That's mainly about the image size factor of a 4+ GB DVD.

There is one size factor that is not defined by optical media sizes
  https://cdimage.debian.org/debian-cd/current/amd64/jigdo-16G/


> Would you be equally happy with an image only for a USB flash drive, or
> is it important for it to be an image for optical media?

The ISOs work from optical media and from hard-disk-like media.
The latter class includes USB sticks and memory cards.

The production of jigdo files is a linear effort only if the producer
knows where the filesystem stores file content data. This knowledge is in
the ISO 9660 producers genisoimage and xorriso. For other filesystems
the matching jigdo producer software is not available yet.

Further the filesystem must store the content of each Debian package as one
consequtive sequence of bytes. Fragmentation is not supported by jigdo.


For some reason even fancy container systems use ISOs for deployment.
  https://nanikjava.github.io/post/insideminikubeiso/
The example i found is BIOS-only and (virtual) CD-only
  https://storage.googleapis.com/minikube/iso/minikube-v1.0.0.iso
Maybe it's because the user would need to start an ISO 9660 manipulating
program in order to alter them. This hardly happens by mistake.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#225042

>> An alternative is to have "virtual ISO images", i.e. images which are
>> constructed on the fly (presumably by jigdo) on the web-server side.
> Assuming that a complete set of ISOs for whatever medium occupies
> at most 100 GB, it seems better to have the images ready rather than to
> assemble them on demand, even if the mirror latency and bandwidth are
> no problem.
> This would spare the nightmare of managing the life cycle of temporary ISOs
> on the server. I assume that all images would fit on a single modern HDD.

I was thinking of a scheme by which the ISO is constructed and streamed
at the same time, so the complete ISO images aren't ever stored whole
anywhere on the server.

> But the reason for letting the user perform jigdo download is that the network
> load vanishes in the normal traffic of the package servers. If download gets
> interrupted, one just has to start it again to get the remaining work
> completed.

Very good point.  I did not consider the interrupt&restart issue.

> The production of jigdo files is a linear effort only if the producer
> knows where the filesystem stores file content data. This knowledge is in
> the ISO 9660 producers genisoimage and xorriso. For other filesystems
> the matching jigdo producer software is not available yet.

I'm not sure I understand what this means, but it does sound like it
implies that streaming production of ISOs is technically possible.


        Stefan

[toc] | [prev] | [next] | [standalone]

#225046

[Multipart message — attachments visible in raw view] — view raw

Streaming production of .iso files _is_ technically possible. Jigdo
effectively builds the iso file from chunks of ten or so files until the
disk is complete and checksummed. As mentioned, this query was about
stopping production of the .iso files specifically meant for the oldestMac
mini. That certainly sounds possible for Bullseye when it gets here since
that particular model will be about 15 years old and there's likely to be
very few of them still running.

I'm collecting what people are sending me on and off list. It does seem
that we may be able to stop routine production of as many images. Netinst,
something DVD-ish sized (so smaller than 8G) and some (larger file size ??)
may do it. The problem of using http to download large files is that it's
fairly difficult on a slow link or one which is losing packets. Jigdo does
work well to build .iso images - it might need more documentation.

Hope this helps

On Mon, Jul 20, 2020 at 2:25 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> >> An alternative is to have "virtual ISO images", i.e. images which are
> >> constructed on the fly (presumably by jigdo) on the web-server side.
> > Assuming that a complete set of ISOs for whatever medium occupies
> > at most 100 GB, it seems better to have the images ready rather than to
> > assemble them on demand, even if the mirror latency and bandwidth are
> > no problem.
> > This would spare the nightmare of managing the life cycle of temporary
> ISOs
> > on the server. I assume that all images would fit on a single modern HDD.
>
> I was thinking of a scheme by which the ISO is constructed and streamed
> at the same time, so the complete ISO images aren't ever stored whole
> anywhere on the server.
>
> > But the reason for letting the user perform jigdo download is that the
> network
> > load vanishes in the normal traffic of the package servers. If download
> gets
> > interrupted, one just has to start it again to get the remaining work
> > completed.
>
> Very good point.  I did not consider the interrupt&restart issue.
>
> > The production of jigdo files is a linear effort only if the producer
> > knows where the filesystem stores file content data. This knowledge is in
> > the ISO 9660 producers genisoimage and xorriso. For other filesystems
> > the matching jigdo producer software is not available yet.
>
> I'm not sure I understand what this means, but it does sound like it
> implies that streaming production of ISOs is technically possible.
>
>
>         Stefan
>
>

[toc] | [prev] | [next] | [standalone]

#225053

[Multipart message — attachments visible in raw view] — view raw

On 7/20/20 8:32 AM, Andrew Cater wrote:
> Streaming production of .iso files _is_ technically possible. Jigdo 
> effectively builds the iso file from chunks of ten or so files until 
> the disk is complete and checksummed. As mentioned, this query was 
> about stopping production of the .iso files specifically meant for the 
> oldestMac mini. That certainly sounds possible for Bullseye when it 
> gets here since that particular model will be about 15 years old and 
> there's likely to be very few of them still running.
>
> I'm collecting what people are sending me on and off list.
that is greatly appreciated
> It does seem that we may be able to stop routine production of as many 
> images. Netinst, something DVD-ish sized (so smaller than 8G) and some 
> (larger file size ??) may do it. The problem of using http to download 
> large files is that it's fairly difficult on a slow link or one which 
> is losing packets.
I suffer with a slow link. We use bittorrents whenever possible. 
Downloads for even modest size ISOs sometimes take days, but it does work.
> Jigdo does work well to build .iso images - it might need more 
> documentation.
Yes, enhance the documentation please. It is befuddling to me.
>
> Hope this helps
>
> On Mon, Jul 20, 2020 at 2:25 PM Stefan Monnier 
> <monnier@iro.umontreal.ca <mailto:monnier@iro.umontreal.ca>> wrote:
>
>     >> An alternative is to have "virtual ISO images", i.e. images
>     which are
>     >> constructed on the fly (presumably by jigdo) on the web-server
>     side.
>     > Assuming that a complete set of ISOs for whatever medium occupies
>     > at most 100 GB, it seems better to have the images ready rather
>     than to
>     > assemble them on demand, even if the mirror latency and
>     bandwidth are
>     > no problem.
>     > This would spare the nightmare of managing the life cycle of
>     temporary ISOs
>     > on the server. I assume that all images would fit on a single
>     modern HDD.
>
>     I was thinking of a scheme by which the ISO is constructed and
>     streamed
>     at the same time, so the complete ISO images aren't ever stored whole
>     anywhere on the server.
>
>     > But the reason for letting the user perform jigdo download is
>     that the network
>     > load vanishes in the normal traffic of the package servers. If
>     download gets
>     > interrupted, one just has to start it again to get the remaining
>     work
>     > completed.
>
>     Very good point.  I did not consider the interrupt&restart issue.
>
>     > The production of jigdo files is a linear effort only if the
>     producer
>     > knows where the filesystem stores file content data. This
>     knowledge is in
>     > the ISO 9660 producers genisoimage and xorriso. For other
>     filesystems
>     > the matching jigdo producer software is not available yet.
>
>     I'm not sure I understand what this means, but it does sound like it
>     implies that streaming production of ISOs is technically possible.
>
>
>             Stefan
>

[toc] | [prev] | [next] | [standalone]

#225054

Hi,

Andrew Cater wrote:
> It does seem that
> we may be able to stop routine production of as many images. Netinst,
> something DVD-ish sized (so smaller than 8G) and some (larger file size ??)
> may do it.

How about being storage-neutral and drop amd64-DVD-2.iso and
amd64-DVD-3.iso in favor of a new amd64-STICK8GB-1.iso ?

That would mean the dropped DVDs 2 and 3 have to be downloaded by jigdo
like DVDs 4 to 16 (or like DVD 2 and 3 of arm64).
Question is what is on DVD 3 that will be missing for a "normal" Debian
installation from STICK8GB.

Really generous with more than all DVD.iso packages would be a readily
downloadable amd64-STICK16GB-1.iso (currently only available via jigdo).


> Jigdo does work well to build .iso images
> - it might need more documentation.

Especially the documentation needs to be where the .jigdo files are.

I meanwhile learned that SuSE has a package "jigdo" which provides
jigdo-lite. (It's not easy to get a file list of their packages online.)
Fedora too has jigdo-lite in package "jigdo".
(Well, when debian-cd switches to SHA256 for jigdo, those will need a
 nudge.)


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#225052

Hi,

Stefan Monnier wrote:
> I was thinking of a scheme by which the ISO is constructed and streamed
> at the same time, so the complete ISO images aren't ever stored whole
> anywhere on the server.

Although there are no fundamental obstacles for stream production,
the current software uncompresses the .template file to a file on disk
and then fills the marked holes by the packages which it downloads from
the chosen mirror server.


I wrote:
> > The production of jigdo files is a linear effort only if the producer
> > knows where the filesystem stores file content data.

Stefan Monnier wrote:
> I'm not sure I understand what this means,

Indeed "linear" is not the right term. I apologize for being misleading.

Given the original description
  http://atterer.org/jigdo/debian-jigdo-mini-howto#PREPARINGTHEISOFORDOWNLOAD
of the production process it is more about "scientific" versus "magic":

  "Through magic, jigdo-file finds out which of the loose files are
   contained in the ISO image and their offsets within the ISO file.
   It outputs two files: a ".template" file and a ".jigdo" file."

All tools for creating .jigdo and .template get a list of MD5 sums and
package file paths (the "loose" files).

The original tool, jigdo-file, scans the readily prepared ISO image for
the content of the data files without knowing where their content starts.
This implies a large amount of try-and-error, even with a smart algorithm.
The mismatching efforts are wasted.

genisoimage and libjte (under libisofs and xorriso) get to see the content
data of each data file, compute the MD5 and look up this MD5 in the list.
They don't have to guess where the files are stored in the ISO.

On the other hand, jigdo-file can apply its magic to any filesystem which
stores file content unchanged in one byte string, whereas the non-guessing
approach needs help from the filesystem producer.


> it does sound like it
> implies that streaming production of ISOs is technically possible.

I actually meant production of .template and .jigdo, not re-assembly of
the .iso from them and Debian packages.

But yes, streaming re-assembly of .iso from .jigdo only needs structural
changes in the download software. (The problem is how to motivate the
change given that there hardly will be an official ISO-from-Jigdo server.)

-------------------------------------------------------------------------

Tixy wrote:
> > Debian's 'DVD' images are isohybrid and work for booting from USB flash
> > drives,

Stefan Monnier wrote:
> The discussion was about the creation of special ISOs for old Mac
> hardware whose firmware isn't able to boot from those hybrid ISOs.

The "mac" ISOs for i386 and amd64 are hybrid ISOs too. Just not for EFI.

They have legacy MBR boot code which hops on the boot image for CD booting
after it was started by legacy BIOS from USB stick.
But they don't have a second boot image for EFI from CD (which also
would serve as EFI System Partition on USB stick).


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#225020

On Sunday 19 July 2020 16:25:31 Stefan Monnier wrote:

> >> At this point in 2020, I think it would be reasonable to only
> >> produce netinst images and jigdo (and live, but that's a
> >> different-ish project). Drop the DVD images.
>
> An alternative is to have "virtual ISO images", i.e. images which are
> constructed on the fly (presumably by jigdo) on the web-server side.
>
> > Though this doesn't apply to me, I can imagine a fair few people in
> > the world who don't have access to fast, cheap internet who would
> > appreciate a DVD image that they can simply download somewhere where
> > they can get good internet. e.g. library, work, education
> > establishment. Or could get someone else to do that and mail it.
>
> I'm not sure why the discussion is always around DVD images.
> Would you be equally happy with an image only for a USB flash drive,
> or is it important for it to be an image for optical media?

With the exception of this new Asus mobo, none of my other 4 machines can 
boot from usb.  So I'd have to have locally written DVD's. Or in the 
case of the pi4, a usb driven u-sd card writer.

> I always found optical media very unappealing, even back when its
> capacity and price were strongly in its favor.  Nowadays, I'm having
> a hard time imagining a circumstance when it would be a good choice.
>
>
>         Stefan


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#225025 — Re: Final CDs being written for Stretch - 9.13 release - prior to LTS

On Sun, 2020-07-19 at 16:25 -0400, Stefan Monnier wrote:
> > > At this point in 2020, I think it would be reasonable to only produce
> > > netinst images and jigdo (and live, but that's a different-ish
> > > project). Drop the DVD images.
> 
> An alternative is to have "virtual ISO images", i.e. images which are
> constructed on the fly (presumably by jigdo) on the web-server side.
> 
> > Though this doesn't apply to me, I can imagine a fair few people in the
> > world who don't have access to fast, cheap internet who would
> > appreciate a DVD image that they can simply download somewhere where
> > they can get good internet. e.g. library, work, education
> > establishment. Or could get someone else to do that and mail it.
> 
> I'm not sure why the discussion is always around DVD images.
> Would you be equally happy with an image only for a USB flash drive, or
> is it important for it to be an image for optical media?

Debian's 'DVD' images are isohybrid and work for booting from USB flash
drives, which is how I use them now [1]. So, for me, an image that only
works on a USB stick would be fine, but what benefit is gained by
removing support for optical media which some other people may need?

[1] Actually, I use the net install 'CD' images, CD/DVD/Blueray(?) just
gets used to distinguish capacity of optical media needed to contain
them I believe.

-- 
Tixy

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web