[arch-dev-public] ArchISO FTP Installer - Round 2
dpmcgee at gmail.com
Sat Apr 5 14:57:58 EDT 2008
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.
More information about the arch-dev-public