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

[Dan McGee]

On Sat, Apr 5, 2008 at 1:42 PM, Thomas Bächler <thomas at archlinux.org> wrote:
> Dan McGee schrieb:
> > 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.

And then we are back to square one- having the installer being tightly
coupled with a particular live CD. You should be able to run the
installer from any environment, including another distro. Obviously we
have a lot of work to do in order to make this possible, but the above
simple logic seems to take us in the wrong direction.

> > 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 don't dismiss this as the users problem. Instead, I take a look at
my own fstab which was recommended by us quite some time ago:
# <file system>  <dir>       <type>    <options>                 <dump> <pass>
none             /dev/pts    devpts   defaults                     0      0
none             /dev/shm    tmpfs    defaults                     0      0

#/dev/hdc         /media/cd0  iso9660  user,ro,noauto,unhide        0      0
#/dev/hdd         /media/cd1  iso9660  user,ro,noauto,unhide        0      0
#/dev/hdc         /media/dvd  udf      user,ro,noauto,unhide        0      0
#/dev/fd0         /media/fl   auto     user,noauto                  0      0
LABEL=hdroot     /           ext3     defaults                     0      1
LABEL=hdboot     /boot       ext2     defaults                     0      2
LABEL=swapspace  swap        swap     defaults                     0      0

Now why aren't we doing something like this instead? Obviously the
links in /dev/disk/by-* would work just fine here. I can boot this
system with either IDE or PATA (which only works 50% of the time), but
the drives are all mounted correctly and in the right places.

-Dan