Public SourceMage Discussion List

[Jeremy Blosser <jblosser-smgl AT firinn.org>]

On Sep 19, flux [flux AT sourcemage.org] wrote:
> Jeremy Blosser (jblosser-smgl AT firinn.org) wrote [08.09.19 10:48]:
> > 1) boot as many places as possible
> > 2) contains basic system prep tools (fdisk, mdadm, lvm, ifconfig)
> > 3) has the latest grimoire tarball that was created as part of the stable
> >    testing
> 
> Resolving the issue with (1) requires a known-good kernel config, and
> any changes with updates to the kernel need to work. This is something
> that will need to be constantly updated on the ISO, because the kernel
> constantly supports more and more hardware. Therefore, booting in as
> many places as possible will mean booting in more places with (possibly)
> each new kernel release. This will require an updated kernel both for
> the ISO filesystem and for the installed system.

Perhaps I should have said "practical" instead of "possible."  If a new
kernel release brings a couple new pieces of hardware I would not expect
our ISO with the next stable grimoire to be held up until that was all
working.  Regressions are another thing but adding support for new things
should not be a blocker.

This problem with the 0.10 series and SATA, is it a regression from what we
have in 0.9?

> Resolving issue (2) doesn't in theory require newer tools, as you said.
> However, practice is not theory, and this is not necessarily true. A
> partition created with > 128 inodes will not be bootable with the grub
> that was available in stable-0.21.

How often do things like this reasonably happen, though?  Very rarely in my
experience.

> The partitioning tool is of course necessary on the ISO, while grub would
> be necessary in the target system. There's no need for grub on the ISO fs

It certainly helps if it's there so you can install grub on the target
system, though you can do that via mounting into the new system (if grub is
static or there aren't library version mismatches).

> Therefore not all cases of updating the image tarball can be guaranteed
> to work with a non-updated ISO. You may get away with it some of the
> time, but not all of the time, and if it can't be guaranteed then why
> develop it as a process we will rely on?

Because this is not brain surgery in that people aren't going to die if we
get it wrong on a minor point, and we do more harm than good sometimes if
we keep people using stale ISOs for years because too many things are seen
as blockers.  You made a point about cauldron having the most dependencies
on both sorcery and grimoire.  I'm not going to debate that here, however
I'll say that the grimoire should have a lower standard for what makes
something a blocker than the cauldron does, because in the case of the
grimoire something breaking can break a running system.  In contrast,
something breaking in cauldron typically hinders the creation of a new
system, which is not the same thing and can typically be more easily
noticed before being a catastrophic problem and can and even often be
worked around.

Let's keep in mind we are not a hand-holding distribution, we are a
distribution for people expected to know what they want and generally how
to get it, even from scratch.  We try to provide people with tools without
encumberances and expect them to make things work even where they are rough
around the edges.

> I understand the desire for a more minimal type of ISO, and I do agree
> with it. However, as general installation medium, it's not as practical.

I disagree at least for my uses and I think over the years we are seeing
more and more of our users ask for this.  It may just be because the
cauldron team doesn't have enough resources available to keep something
more complex current and people just need *something*, but regardless I do
think it's certainly an approach the archetypical SMGL user should be able
to work with.

Attachment: pgpVIeeLOLZ3I.pgp
Description: PGP signature