Public SourceMage Discussion List

[flux <flux AT sourcemage.org>]

Jeremy Blosser (jblosser-smgl AT firinn.org) wrote [08.09.26 13:43]:
> 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.

We are in complete agreement on this point, actually. The current
blocker with the kernel is not in having new support, but with changes
to how both new devices and old devices are being supported. For
pata/ide, there are two possible drivers that a device can use. The
older style ide drivers are more stable, and some ide devices will only
work with the ide drivers. The newer pata drivers work with the newer
ata subsystem, and are the direction the kernel is going in, but are
less stable. Some pata devices will only work with the newer pata
drivers. However, the real problem comes when ide/pata devices will work
reasonably well with both drivers (either the ide or the pata), as the
two drivers then fight with each other. Also, the pata drivers are too
aggressive, and sometimes attach themselves to ide devices that can only
work with the older ide drivers. This is still a problem with the most
current (stable released) kernel version, so an update to the kernel to
add support for new devices won't fix this problem. Since there is
already a blocker on the kernel itself, I don't want to update the
kernel for new devices until that blocker is resolved, as an update may
bring in additional changes and confuse the original problem. However,
please see my responses below for more on this.

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

The issue with SATA is due to changes internal to the linux kernel, so
I'm not completely sure how to respond to your question here. The
differences between 0.10.0 and 0.9 are not only in which kernel version
is present, and additionally, should a newer kernel version be
considered a regression? All of the newer kernels will have the same
issue as 0.10 until they are resolved in the kernel. A big part of the
problem is the transition in the kernel from the older but more stable
IDE drivers to the newer but less stable ATA drivers. As ATA matures and
all of the older IDE drivers are fully ported to use libata, the problem
will likely eventually go away. Having said all this, I don't consider
0.10 to be a regression from 0.9, but quite the opposite. Again, the
only current blocker with the 0.10 series is working out a known good
kernel config that can gracefully handle both older IDE and newer ATA at
the same time, which will have to get figured out in order to update the
kernel to even newer versions to support more hardware.

> 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).

I think we may have had a mismatch in terminology. When I said ISO fs, I
meant specifically the running ISO system. I didn't mean that grub
should be present anywhere on the ISO. It has to be present on the ISO
in order to install it onto the target system (obviously). However, it
has no business in the running ISO system, as the ISO system has no use
for it (the ISO boots with isolinux). Additionally, if the user wants to
run grub on their target system from inside the ISO, they chroot to do
so, and we have that as part of the installation procedure actually (if
you haven't seen this, please, please try the 0.10.0 ISOs before
commenting further on this issue).

> 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.

I completely agree on your points here. However, this seems to be less
about the ISO generation process and more about the ISO testing process.
Are you suggesting that 0.10 should be released as stable with a warning
that the ISO kernel may not work out-of-the-box for SATA users? By the
way, I will be releasing 0.10.0-test4 (likely tonight) and asking for
testers, particularly with SATA hardware, to see if the kernel issue has
been resolved for them.

> 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.

This is actually what I was referring to when I stated that if you
suggest me to release 0.10 as stable that I would consider doing so.
There is a step on the ISO for setting up a custom kernel on the target
system rather than using the ISO kernel. If we can reasonably expect our
users to deal with this level of rough edge, then I can release 0.10 as
stable (I'll do some very simple updates to the ISO software as
necessary, like making sure grub and ext2/3 play nicely, before
releasing it as stable of course).

> 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.

I would just like to point out that you are speaking mainly with respect
to your own use cases. Your use cases are shared with others, but there
are other groups that also want other kinds of ISOs. In the time that I
have been working on cauldron (about 1 year), I seen a request for this
type of ISO only a few times (like maybe 3), whereas I have had numerous
requests for a menu-based ISO (like what we had for 0.9). It is not
currently possible to satisfy the requests of all users for all the
types of ISOs they would like produced. However, the current 0.10 ISOs
are stable enough for most purposes, and with minimal effort can be
updated in precisely the way you desire. Although I admit the 0.10 ISOs
aren't exactly what you would be looking for in your own use cases, they
can be used for your purposes with minimal adaptation in the worst case,
but likely without any adaptation at all (just boot it and run the
commands, you are not forced to follow the installer).

-- 
Justin "flux_control" Boffemmyer
Cauldron wizard and general mage
Source Mage GNU/Linux
http://www.sourcemage.org

Attachment: pgp9yO1Eu_6sJ.pgp
Description: PGP signature