F13 Beta 1 & 2 don't see my HDD

[erroneus]

I'm running an HP Mini 2102 and it cannot see the SATA hard drive. I was able to start the install process using a Fedora 12 install disk, I'm guessing whatever driver support that was available to F12 is not in F13? That wouldn't make sense. Another thing I did in F12 to get it to install was adding "ssb.blacklist=1" to the kernel boot line. Adding that to the F13 boot does not change anything.

Anyone have any ideas on how to get the HDD to detect?

[SlowJet]

I posted on your other thread. They looked similar?

SJ

[erroneus]

I tried the options you suggested from my other thread. The threads are different because with Fedora 12, I was able to get into the install process by including the ssb.blacklist=1 option on the kernel command line. In Fedora 13, there is no kernel boot hang up to be resolved with this option.

To continue the suggestions you offered in the previous thread, though, I will try monkeying with the partitioning. Interestingly, I has a similar problem with installing Windows XP on it. I used the Fedora 12 recovery mode to boot, then fdisk to delete any partitions on the drive and was able to set up WinXP on a 20GB partition I created during the install process.

Interesting to note that there is no option in the BIOS to change the SATA mode emulation and that there seems to be an option in the BIOS that cannot be changed (without special utility?) that says "Installed OS: Windows 7" I need to be able to dual boot as this is a work machine and is used for remote access through a VPN that requires MSIE 8 to connect... huge PITA. (Anyone know of a way to log in through Linux to a Juniper service that makes the client run an ActiveX control?) I've got my WinXP partition all tweaked out now and would hate to have to reload it again if I can help it... I'm guess it cannot be helped though...

---------- Post added at 02:31 PM CDT ---------- Previous post was at 09:44 AM CDT ----------

Okay I now have further information to provide about the problem.

I changed HDDs to the original 160GB drive it shipped with instead of the 320GB drive I installed. I started the install process again and the same problem occurred. In the former case, it showed /dev/sda1 which I presumed (stupidly) was the USB DVD drive. In the latter case, it showed /dev/sda1 and /dev/sda2 which I then realized was the original 160GB HDD with two partitions on it.

The installer is looking for some install image files that it couldn't seem to find from /dev/sr0.

That's when it hit me. I copied the contents of the installation media to a USB flash drive and made it available at installation time. When it asked for the image files, I pointed it to the USB flash drive. Installation is now proceeding. Interestingly enough, it is still reading some stuff from the DVD drive.

The installation has now failed again after setting up partitions. The window that has come up is as follows:

Title: Missing ISO 9660 Image
Content: The installer has tried to mount image #1, but cannot find it on the hard drive. Please copy this image to the drive and click Retry. Click Exit to abort the installation.

I would be happy to go to the command line to copy whatever file(s) are needed to continue the process, but I have no idea what files or where they are expected to go.

[CSchwangler]

That may sound strange, but did you verify the downloaded ISO file and the burned DVD? If the installer says it cannot find the install image files, it is often due to either a corrupt download or a bad burn.

[erroneus]

Yes, install media verified. Downloaded twice.

---------- Post added at 04:54 PM CDT ---------- Previous post was at 04:38 PM CDT ----------

I am now doing this as a network install. Booting from CD then specifying another machine on my network hosting the files over http.

It gets as far as creating the file system, which is where all previous attempts have gotten to, and now it fails at approximately the same stage of installation except now the error is:

Window title: Error
Window contents: Unable to read package metadata. This may be due to a missing repodata directory. Please ensure that your install tree has been correctly generated. failure: repodata/334255a36889b3084fc55902cc518d86df99f94ffde15da80a ffdb6d06e3eb15-primary.sqlite.bz2 from anaconda-InstallationRepo-201005072145.i386: [Errno 256] No more mirrors to try.

---------- Post added at 04:58 PM CDT ---------- Previous post was at 04:54 PM CDT ----------

I visited the machine hosting the files and found that the file was named "334255a36889b3084fc55902cc518d86df99f94ffde15da80 affdb6d06e3eb15" and not "334255a36889b3084fc55902cc518d86df99f94ffde15da80 affdb6d06e3eb15-primary.sqlite.bz2" and so I created a symlink of the one file to the later filename. The installer then advanced to the following error:

Window title: Error
Window contents: Unable to read group information from repositories. This is a problem with the generation of your install tree.

---------- Post added at 05:30 PM CDT ---------- Previous post was at 04:58 PM CDT ----------

Frustrated, I have been following the apache logs to see what files are being requested and creating symlinks to them; four in all.

I even selected to customize the install prior to installation and am now installing all from the network. It would seem to me that there is something broken with this current incarnation of the installer. I have been able to overcome these things by providing what is being requested by the installer ... things which were already there under a different name?? This is not what I would classify as a hardware problem any longer.

---------- Post added at 06:00 PM CDT ---------- Previous post was at 05:30 PM CDT ----------

Installation 100% successful. I am now looking at the GNOME Desktop after logged in.

I am now running updates and will begin tweaking.

I cannot imagine that no one else has had this problem. Perhaps all people testing are upgrading from previous successful installs?

[AdamW]

We do planned testing of network install at multiple test points throughout the cycle, and we haven't seen the above in any of those tests in the F13 cycle. Not sure what you did to hit such weird issues, I'm afraid, though you could file a bug report with more details.

https://fedoraproject.org/wiki/Test_...tallation_Test

[erroneus]

I might find some time to test an installation on a different computer, but given the consistency of the behaviors from install by DVD media and install by network, they both illustrated the same behavior -- unable to find a file specified by name while the file exists under a slightly different name. If renaming a file fixes the problem, there is something wrong with the filenames I would say. If you get a F13 beta DVD ISO and open it with an archive utility, you will find that the files in the repository folder have no extensions on the filenames meanwhile the various files that reference them expect to see such filenames. There could be a problem with the length of the filenames maybe... isn't there some ISO standard format that has a 64 character filename limit?

In any case, it would seem one of the "blocker" items that pushed release back a week deals with installation issues that are reportedly similar. I think perhaps someone is already on this one.

[AdamW]

"In any case, it would seem one of the "blocker" items that pushed release back a week deals with installation issues that are reportedly similar. I think perhaps someone is already on this one."

I don't believe so, I don't think the NFS bug we're dealing with is the same as this one.

Please do file a bug against this, though. That's the only way someone who knows for sure whether it's a problem will see it.

[erroneus]

Very well then, I will test the new F13-R3 to see if the problem exists/persists.