Release Engineering

This project is intented for all release related issues (isos, installer, etc), under the umbrella of the ArchLinux Release Engineers
Tasklist

FS#16328 - fresh install populated /etc/fstab with wrong device

Attached to Project: Release Engineering
Opened by chris (jugg) - Wednesday, 23 September 2009, 11:13 GMT
Last edited by Dieter Plaetinck (Dieter_be) - Thursday, 09 December 2010, 10:00 GMT
Task Type Bug Report
Category AIF
Status Closed
Assigned To Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Dieter Plaetinck (Dieter_be)
Architecture All
Severity High
Priority Normal
Reported Version 2009.08
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

Fresh install on an old Toshiba Satellite 2805-s202 (p3-700mhz w/128mb ram) using: archlinux-2009.08-netinstall-i686.iso

Got through the entire installation, rebooted into Arch, and got a JFS fsck error. I tracked the problem down using the recovery console that was provided after the error. /etc/fstab contained:

/dev/hda1 /boot ext2 defaults 0 1
/dev/hda2 swap swap defaults 0 0
/dev/hda3 / jfs defaults 0 1
/dev/hda4 /home jfs defaults 0 1

However, on this system, the drive is /dev/sda meaning the fstab file should have contained:

/dev/sda1 /boot ext2 defaults 0 1
/dev/sda2 swap swap defaults 0 0
/dev/sda3 / jfs defaults 0 1
/dev/sda4 /home jfs defaults 0 1

After fixing said problem and rebooting, everything appears to be working fine.

I'm no linux guru and new to Arch, but if you ask for some additional information, I can probably provide it.
This task depends upon

Closed by  Dieter Plaetinck (Dieter_be)
Thursday, 09 December 2010, 10:00 GMT
Reason for closing:  Fixed
Additional comments about closing:  pick uuid/labelling
Comment by Aaron Griffin (phrakture) - Wednesday, 23 September 2009, 22:18 GMT
Weird, did you boot the ISO with the legacy IDE stuff?
Comment by chris (jugg) - Saturday, 26 September 2009, 03:14 GMT
Yes, I followed the instruction to do so as my system does not have SATA.
Comment by Aaron Griffin (phrakture) - Saturday, 26 September 2009, 20:32 GMT
Hmm, so you booted the install ISO with legacy IDE, but the actual system itself boots fine without it. If it was booting with legacy IDE, you would still have the hda entries.

Perhaps we should do away with the legacy boot option? Thomas, what configuration actually still needs legacy IDE, do you know?

However, it might just be our instructions that suck. Obviously, non-legacy works fine for you
Comment by chris (jugg) - Sunday, 27 September 2009, 00:22 GMT
Slightly guessing here, but I assume you mean that my system is currently booting without "legacy ide", yet why would that be if I installed using "legacy ide"? Should the system not have been configured to subsequently boot with "legacy ide" enabled after installation since that was the option it was installed with? If it is booting without "legacy ide" currently, I'm not aware of having configured it to do so. (However, I have no specific preference).

Also, I believe the installation UI itself indicated that legacy ide should be used - something like "Legacy IDE, No SATA" - not just the manual/instructions.

So, it seems like there may be at least two issues here:

1. Installed with "legacy ide", but installed system booted without it and was "broken".

2. Documentation and Install UI (?) indicates one should use "legacy ide" if you don't use SATA.
Comment by Aaron Griffin (phrakture) - Sunday, 27 September 2009, 06:30 GMT
Actually, it seems like your system is NOT legacy ide, and the actual system Did The Right Thing(TM) by booting normally.

I see two bugs here.
A) if booted with legacy IDE, we make sure the installed system uses the same boot method. This may actually be documented when configuring mkinitcpio during install.
B) the boot menu should expalin when to use legacy ide better
Comment by Jameson Thatcher (SirEel) - Friday, 09 October 2009, 21:44 GMT
I suffered a bug which I think may be related, although I did not touch the boot legacy option. I thought it best not to post a semi-duplicate bug.

The bug:
I couldn't say why, but after installation, booting was throwing errors about the filesystem being unmountable due to filesystem types not matching. I did some digging from another distro installation, and found that the device files for the drives seemed to have rearranged ( I think this is some problem due to my hardware, I'm not totally certain )

I was wondering why not have fstab populated with drives listed by UUID, just have a comment above each giving the device that the installation detected? Changing my fstab to list drives by UUID was certainly how I solved the problem.
Comment by Ionut Biru (wonder) - Monday, 28 December 2009, 14:12 GMT
before AIF was used by default in our installation cd, we had UUID in fstab also. is a regression because in menu.lst is used.
Comment by Dieter Plaetinck (Dieter_be) - Monday, 28 December 2009, 16:41 GMT
please open a separate feature request for uuid's in fstab (if there is none already)
Comment by Dieter Plaetinck (Dieter_be) - Friday, 05 March 2010, 20:19 GMT
is this still relevant? I disagree with wonders comment; uuids seems more like a hack/workaround to me. (edit: actually we use UUID now in fstab)
I wonder if the 2 problems said by Aaron are still relevant.
Comment by K.Mandla (K.Mandla) - Saturday, 06 March 2010, 23:38 GMT
Dieter asked me to check this bug report and see if it was similar to what I have experienced in the past. I believe it to be the same so I won't go into great detail. A Thinkpad iSeries 1100 with a 550Mhz Celeron and a 60Gb Hitachi IDE drive installs fine with the legacy boot option, but the drive assignments in fstab are /dev/hdaX, and on the first reboot the system assigns /dev/sdaX letters to the drive, resulting in the same error.

The workaround is just to remount the drive with write privileges, edit the /etc/fstab file and reboot. After that, the system behaves normally. It's a minor annoyance, but also a show-stopper if you're new to the Arch way, or if you overlook the possibility of the fstab being different from the drive labels. ;)
Comment by Ionut Biru (wonder) - Saturday, 06 March 2010, 23:39 GMT
did you tested the latest iso( http://build.archlinux.org/isos/ ) and using inside it aif-git or aif-experimental-git from aur?
Comment by Dieter Plaetinck (Dieter_be) - Sunday, 16 May 2010, 16:23 GMT
Quote from Aaron:
A) if booted with legacy IDE, we make sure the installed system uses the same boot method. This may actually be documented when configuring mkinitcpio during install.
-> is this still relevant?
B) the boot menu should expalin when to use legacy ide better
-> with isolinux, we don't even mention legacy ide anymore
Comment by Aaron Griffin (phrakture) - Monday, 17 May 2010, 18:21 GMT
I don't think it's still relevant
Comment by Dieter Plaetinck (Dieter_be) - Thursday, 09 December 2010, 10:00 GMT
actually the user can now choose between devicefiles, by label, and UUID's. so the issues are now moot :)

Loading...