Bug 442457

Just noticed that system BIOS reports the Drive ID as "SAMSUNG HD160JJ/P".
Perhaps the P is getting truncated somewhere in the process?

Seems plausible... need to see more of the traceback to see where the problem is
really coming from though.

Created attachment 302400 [details]
Anaconda dump from when the exception occurred

Attached complete Anaconda dump from when the issue occurred.

To hal for now, although I'm not entirely sure that's where the problem lies

My guess is this is because the device identifier has a / in it, but HAL is not
quoting it.  

We should be quoting this stuff. lshal output please? 

Apparently we're not. I'll look into a fix.

I'm getting a very similar error - 
ValueError: Invalid object path
'/org/freedesktop/Hal/devices/storage_model_SAMSUNG_HD080HJ/': ends with '/' and
is not just '/'

From comment #1, I also have that /p
Drive ID = SAMSUNG HD080HJ/P 

Checking in the BIOS, I changed RAID Autodetect / AHCI to RAID Autodetect / ATA
for that device, but after saving the change and trying to install again, I got
the same error. 

Going to control + alt + f3, I see as some of the messages:
FATAL: Module md not found.
FATAL: Module blkcipher not found. 

I do not have hard/software raid setup. 

Getting to control + alt + f2, and running # lshal during the install before it
freezes, 
# lshal
error: dbus_bus_get: org.freedesktop.DBus.Error.FileNotFound: Failed to connect
to socket /var/run/dbus/system_bus_socket: No such file or directory

# lshal
Could not initialize connection to hald.
Normally this means the HAL daemon (hald) is not runnning or not ready.

This is all from GOLD media, not beta. 

*** Bug 444018 has been marked as a duplicate of this bug. ***

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

This bug has bitten several visitors in #fedora during the last 24 hours.  Seems
to be a Samsung hard disk in each case, with the trailing '/' in the model string.

*** Bug 446378 has been marked as a duplicate of this bug. ***

*** Bug 446386 has been marked as a duplicate of this bug. ***

Added to http://fedoraproject.org/wiki/Bugs/F9Common#samsung-hdds

I worked around this issue by installing from the LiveCD, which apparently
doesn't do the same check on the HD using hal.

(In reply to comment #14)
> Added to http://fedoraproject.org/wiki/Bugs/F9Common#samsung-hdds

Sorry to point it bluntly but the indication in the page "For now, users are
advised to use a different hard disk model if possible." is far from satisfactory...

I've got something like 200 computers in my park on an identical model, and I
guess there are even more with SAMSUNG drives around, so doing a disk exchange
is a no way answer.

(In reply to comment #16)
I forgot to mention that I can't use the workaround pointed by comment #15 since
I have to create some kickstart set to boot the installation in different
configurations. I use a NFS server as source for this.

The likely fix for this problem will be an updates.img that you'll load during
install. It's being worked on.

*** Bug 446424 has been marked as a duplicate of this bug. ***

(In reply to comment #15)
> I worked around this issue by installing from the LiveCD, which apparently
> doesn't do the same check on the HD using hal.

For those impatient souls (like me)- I tried this with the KDE version, and it
worked. It preserved my main lvm like I wanted (LogVol02) and was able to get
the OS installed on the lvm I had used before for the os (LogVol00) and set the
encryption on it. The only issue with this is that you don't get the click and
choose for which packages you want installed. No matter, just use yum to get
whatever that is needed installed afterwards.
Thanks a lot Cary. 

Hit this bug as well, but to get around I used the following completely
unsupported hackery to re-use the packages preupgrade downloaded for a live yum
upgrade instead.

1. cp -R /var/cache/yum/anaconda-upgrade/packages /var/cache/yum/fedora/packages
2. Follow the steps on http://fedoraproject.org/wiki/YumUpgradeFaq

Worked fine in my case with some minimal manual package uninstalls, but use at
your own risk.

(In reply to comment #21)
This does only apply in the case of an upgrade from FC8 to FC9 right ?

yum upgrades have been an unsupported alternative for some time, I think FC6 ->
F7 they would *not* work but since then it's been an option for those willing to
undertake the risk.

Still no news about a fix ?

I think this bug should be labelled as High priority since it prevents automated
installations, wich is the most interesting way to mass deploy the distro.

hi, i just downloaded the fc9 dvd iso and while trying to upgrade from fc8,
getting the same error as above:

ValueError: Invalid object path
'/org/freedesktop/Hal/devices/storage_model_SAMSUNG_HD160JJ/': ends with '/' and
is not just '/'

donno what to do but whatever fix you propose, should preferably not be
rendering my already-burnt-dvd useless. am i too greedy? but my resources are
limited here.

...always faithful to fedora...
...however I don't believe that the other most important distro could have the
same problem and however I don't believe that the same bug in that distro could
stay opened so long time..
(I remember that when FC8 was released there was an upgrade problem with yum
external repos, but the fix was available in few days)
I apologize for this bugzilla use.

This bug is now forwarded upstream:
https://bugs.freedesktop.org/show_bug.cgi?id=16040

still no news or ETA on a fix ?

Hi,



I tried to update my Fedora 8 to Fedora 9 and I had exactly the same problem,
the installer crashed saying the same message "ValueError: Invalid object path..."



Any idea about what to do ? I really would like to upgrade my Fedora to use all
its wonderful new features... 

As the SAMSUNG hard disk are quite widespread (a least in my company, all our
Dell Workstation have Samsung HD), I think this should be considered as a major
problem that would penalize the deployment of this Fedora, so I'm concerned
about this.


Thanks a lot for your help !

(In reply to comment #29)
Add also the HP XW series Workstations, they also have samsung disks with a '/'
in their name.

This makes quite a lot of rigs impacted.

*** Bug 451034 has been marked as a duplicate of this bug. ***

I am hitting this bug too on an HP xw4400 Workstation with the same Samsung
Harddrive. I'm attaching some pictures showing anaconda failing.

Created attachment 311769 [details]
anaconda failing 0

Created attachment 311770 [details]
anaconda failing 1

*** Bug 456112 has been marked as a duplicate of this bug. ***

is there any ETA on this Fix. A show-stopper defect like this one shouldn't be opened for so long. dissapointed!!!

*** Bug 459047 has been marked as a duplicate of this bug. ***

I have just run into this bug in a corporate environment and needs this issues resolved or a work-around developed reasonably soon as this will effect productivity at my site. It looks like this issues has been out for a while. Is there any estimate ETA? ... any reasonable suggested work-arounds? ... any good indications on exactly what hardware is making it choke? Any current, quasi-detailed assistance would be much appreciated.

Thanks,
John C

jcurcio

(In reply to comment #38)

> there any estimate ETA? ... any reasonable suggested work-arounds? ... any good
> indications on exactly what hardware is making it choke? Any current,
> quasi-detailed assistance would be much appreciated.

The only current workarounds are:

1) Replace the disk with a non-Samsung one, which isn't too hard,

or 

2) Install using the LiveCD install-to-disk feature, instead of the standard installer disk. That actually works quite well.


I don't see anybody rushing to fix this at the upstream bug: https://bugs.freedesktop.org/show_bug.cgi?id=16040

- Mike

 Thanks for the feedback.

#1 is not a reasonable work-around in a corporate environment [as mine is] since we could be talking about replacing a number of disks.

I did stumble upon the idea of installing via the LiveCD and that works pretty well ... however, there is one additional piece of information which would make this a MUCH easier solution for me. In order to burden our network connection as little as possible I would like to be able to point yum (via cli or synaptics, yumex, or pirut) to utilize a locally mounted DVD so I can install all the additional software which I need which does not show up on a LiveCD. Would you be so kind as to write the explicit directions to do so? [I know it's not that differcult, but when I was attempting it (quickly) earlier I could not get it to recognize the location].

Thank you very much for your help ... this will prove to be a big help for my company and I and will be _much_ appreciated.

John C

All the mentioned workarounds are no options for our environment. We're encountering this problem in a corporate environment which uses PXE boot and kickstart to install F9.

Would it somehow be possible to use the anaconda from F8 which points to the software repository of F9 (in a respin for example) ?

John,

1) If you have a bunch of rpm files in a folder (on your DVD for example) that you want to install, you could use

cd /mnt/cdrom/whatever
yum localinstall *.rpm

Or, you could put your rpms on web server on your local network, and use the createrepo command to turn the folder into a proper yum repository. Then put a matching /etc/yum.repos.d/your-repo file in your local computers.


2) Do any of these "corporate environments" have programmers available?

Since the systems work using a LiveCD install, it suggests that the bug is not deep in dbus. Perhaps it is just in the Python dbus binding. If I look in the dbus-python source code, I see this:

_dbus_bindings/validation.c:

dbus_bool_t
dbus_py_validate_object_path(const char *path)
{
... snip ...
    if (ptr[-1] == '/') {
        PyErr_Format(PyExc_ValueError, "Invalid object path '%s': ends "
                     "with '/' and is not just '/'", path);
        return FALSE;
    }
... snip ...
}

So, for some reason, object paths ending with "/" are specifically rejected. Maybe removing that code will make things work. (Or maybe we'll find out why that check was added in the first place, that is, perhaps there is a deeper problem.)

Anyway, that would be a good place to starting testing.


- Mike

If I do a yum localinstall *.rpm on an install DVD, isn't that going to install everything on that DVD? ... that might be a bit much so I think I'll skip that ;-) As for adding the rpm files on a web-server, that means I'll have to have a web-server up and running, copy everything from a locally mounted DVD into the appropiate location ... and the steps listed aren't as explicit as I had hoped [since as I mentioned, I attempted this previously but could not get it to work]. Still, I appreciate the reply ... I'll simply see if I can get yum to recognize a locally mounted install DVD on my own (again).

Oh, I see.

If the DVD is mounted, can't you just change:

#baseurl=http://download.fedora.redhat.com/pub/fedora/linux/releases/$releasever/Everything/$basearch/os/
mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-$releasever&arch=$basearch

to:

baseurl=file:///path/to/your/repo
#mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-$releasever&arch=$basearch

I haven't tried it.

- Mike

is there any news for these bugs?

i have been stucked for three months by these bugs

fwiw, I mentioned the bug as a blocker for the next release

http://lists.freedesktop.org/archives/hal/2008-September/012252.html

*** Bug 464841 has been marked as a duplicate of this bug. ***

A patch for this issue has been posted on the hal list

Richard, can we get that patch into rawhide ? 
Your recent snapshot does not include it yet.

*** Bug 465388 has been marked as a duplicate of this bug. ***

Version with patch here: http://koji.fedoraproject.org/koji/taskinfo?taskID=863240

*** Bug 465387 has been marked as a duplicate of this bug. ***

FYI: The Fedora-10-Snap2-x86_64-DVD.iso installer finally works with Samsung disks (Model: SAMSUNG HD080HJ/ Rev: ZH10).

*** Bug 467885 has been marked as a duplicate of this bug. ***

Is this fixed in Fedora 10 Snap 3? I see jpo saying it works in Snap2, if so, I'd like to close this bug.

Bug closed, as the HAL snapshot will have fixed this for new installs.