Ach, Arch!

I used the word “fitful” to describe installing Arch Linux on this machine the other day, and I should probably explain why.

The 2009.08 ISO has a couple of interrelated idiosyncrasies on this hardware, which I don’t think I have described in the past, but are worth mentioning. (It’s possible that I have mentioned them in the past, but perfect recall on a 4 1/2-year-old post-a-day blog is getting difficult. Please bear with me if this sounds familiar. 😦 )

That ISO, and some of the ones before it, have two boot options — one for SATA-style drive labeling, and one for old IDE-style naming. In other words, /dev/sdaX or /dev/hdaX. It’s not a huge difference, or at least it hadn’t been up until now.

I don’t usually pick the first option, but this time I did and got some of the strangest, most bizarre behavior from an Arch environment I ever saw. Network access was fruity to say the least, with the setup program downloading little more than the names of the files from the server, touching them in the temporary directory, and then complaining because it couldn’t install them. The one or two programs that did manage to survive the blast seemed somehow scrambled if I tried to tamper with them from another window.

It wasn’t just network access either — the drive (if you can believe this) seemed to sometimes be there, and sometimes not. I don’t know how else to say that, except that I could change into the temporary installation directory and find the wreckage of the installation, but seconds later the terminal would hang and tell me it was unable to find files or programs I asked for. Very strange.

I tried this twice, thinking the first was just a fluke, but a reboot using the same SATA-style selection yielded similar results. I know I should be concerned and I know I should be looking for some sort of bug to report … but where do I start? So many things were scrambled I don’t know what to say is wrong. And what does it have to do with that boot option? 😕

Anyway, the second boot option is usually the one I rely on, and at least this time I knew what I could expect. Behavior was normal, network access was normal, the system installed fine … except for one small thing: On the first boot, the system froze, complaining that the root drive was unavailable.

If you ever run into this problem, I can tell you that message is both true and false. It is available, and it isn’t. The issue is that the installer wrote out your /etc/fstab file with /dev/hdaX drive assignments — as you expect it might.

However, the kernel boots and recognizes everything with /dev/sdaX drive letters, and so asks for your help. The solution is somewhat straightforward: Remount the drive so you can write to it (the instructions are right there at the login prompt), then edit the /etc/fstab file to change the drive lettering to sda-style. Reboot, and it should work fine.

I’ll look around for a bug report on that particular issue, since it’s a rather easy one to pin down. I don’t know how much I can do about that first situation though, and it’s always possible this was something unique to this machine. I have one more thing to note in this short Arch experience, but I’ll save that for the next post. … 🙂

5 thoughts on “Ach, Arch!

  1. LeoSolaris

    I tried SATA once on an ancient Gateway laptop with an IDE drive. While it booted the live environment, it refused to acknowledge the drive’s existence, so I’m kinda surprised that the SATA install did anything at all on your hard drive if it is an IDE.

    If your drive is actually an SATA drive… I don’t know. Maybe an old first gen SATA had a minor glitch that got fixed later?

    Are their any other installers like Arch that have an SATA/IDE option that you could test to see if it was Arch or if it was the drive?

    Reply
    1. K.Mandla Post author

      I don’t recall seeing other distros with that option, but I am sure there are others. I don’t know why I picked that except I knew I was going to run into the other bug, so I thought I might be heading off the need to rearrange things by just building the system with /dev/sda assignments anyway.

      This is a purely IDE system, by the way. It might predate all but the most exotic early-run SATA hardware, but I have no way of being sure. In any case, I should have followed my instinct and stuck with the second boot option … the one clearly labeled “legacy.” 🙄

      Reply
  2. Dieter_be

    Devicefile naming bug:
    http://bugs.archlinux.org/task/16328
    The other issues you’re reporting are very odd indeed.
    There are some “exception handling” bugs fixed (example: when pacman fails for whatever reason) in the meanwhile, but what you mentioned is new to me.
    for a list of issues recently fixed, see:
    http://bugs.archlinux.org/index.php?events%5B%5D=2&event_number=200&project=6&do=reports

    Anyway, we’re currently working on new isos, so now is the time to report bugs and provide feedback 🙂
    see arch-releng mailing list for more info.
    http://mailman.archlinux.org/pipermail/arch-releng/

    Dieter

    Reply
    1. K.Mandla Post author

      Hi Dieter. Thanks for the bug link; I will add my experience if it’s helpful.

      As far as the creepy behavior with the non-legacy boot option, I can always start up the CD again and see if there are individual errors I can track. But the more I think about it, perhaps that option is just incorrect for this hardware. After all, there’s nothing SATA at all on the machine, so the “legacy” boot option should be correct, shouldn’t it … ? 😐

      Reply
  3. Med Berdai

    I had almost a similar issue with my DVD burner on Arch Linux on an old Pentium4 box. It turned out that Linux Kernel shifted to PATA which is as far as I can tell handle IDE disks as SATA. The fix was either to boot the install cd with the second option (IDE as I recall) or if already installed replace pata with ide in mkinitcpio.conf .

    Reply

Leave a reply to Dieter_be Cancel reply