[arch-dev-public] ArchISO FTP Installer - Round 2

[Simo Leone]

On Sat, Apr 05, 2008 at 08:42:41PM +0200, =?ISO-8859-1?Q?Thomas_B=E4chler_ wrote:
>> The next issue is the "remember what you chose and put it in the
>> system's mkinitcpio.conf". How about "No"? Why on earth do we need to
>> automate things for the users as long as we document it in the install
>> guide? It isn't that hard to have a one-liner saying "if you booted
>> with IDE drivers, you will want to modify your mkinitcpio hooks
>> accordingly. This would save us a lot of hassle from stupid automation
>> tricks that I really feel we don't need to do.
>
> Because we don't want to produce broken installations, it's that easy. What 
> a nice experience would it be if you told yourself "let's install this new 
> distro" and it would just kernel panic? You would never try again, as it's 
> a broken piece of software. Nobody will notice a one-liner in the 
> installation guide, seriously.
>
> And this is easily fixed. When we mount the unionfs in the initrd, we just 
> add a file indicating which image was used to boot, and if the installer 
> finds that, it does a simple sed on mkinitcpio.conf. Problem solved.
>
I agree this isn't hard to automate. It's not that hard to get at the
boot command line parameters and see if it was booted with oldschool
drivers, we don't even need a file for that. BUT it's still something
that needs to be in the docs. People need to know what automagic we're
doing for them. And on the installation guide in general, that's pretty
sad, it used to be quite a selling point for us, I'd like to take it
back in that direction. If no one reads it, we may as well just stop
including it. Documentation worth reading...ya know?

>> The final issue was references to /dev/hda and such in fstab, which
>> won't work for PATA drivers. Where are these even coming from? Are we
>> autopopulating these, and doing it horribly wrong?
>
> The fstab is generated according to what the installer mounted, so this 
> isn't an issue.
>
>
> You are missing the most important problem, one which you simply can't 
> dismiss by saying it's the user's problem:
> The ordering in which drivers for several controllers are loaded is 
> changing with kernel updates, udev updates, or even randomly between 
> reboots. Almost everyone has several controllers (for example, one onboard 
> sata, one onboard ide, or in my case, one onboard sata, one onboard ide, 
> one pci ide). When sda becomdes sdc at the next boot, and is then sdb and 
> then sda again, then we have a basically unusable distribution. This is the 
> issue we should be concentrating on (I proposed several alternatives 
> already), not the ide vs. pata issue, which is - as mentioned - easily 
> solved.
>
I'm thinking this is another thing that should just be documented.
/dev/disk exists for just this problem, maybe we should default to that,
or at the very least advise people to use it if they have trouble.

I agree that we should be maximizing the chances that someone is going
to end up with a bootable system. But the methods for doing this
(documentation/automation) are pretty debatable. Automation has
historically been minimal, one of the only things we've really done is
populated the fstab with semi-sane defaults. Beyond that there isn't
much. I think we should keep it at that level, attempting to provide
sane defaults, and nothing more. But that's just my 2 cents.

-S
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://archlinux.org/pipermail/arch-dev-public/attachments/20080405/f0024975/attachment.pgp>