I noticed late Sunday night that I was booting after the usrmove
procedure from a pre-usrmove kernel. When I tried to boot from a
kernel updated from the f17-usrmove repository (3.3.0-0.git4.1.fc17),
"/bin/sh: error while loading shared libraries: libc.so.6: cannot open
shared object file: No such file or directory
Kernel panic - not syncing: Attempted to kill init!"
So I rebuilt another Rawhide VM and went through the same procedure
but I'm having the same problem.
I'm now booting fine from 3.3.0-0.git4.1.fc17 (it was pulled in
pre-usrmove) but both 3.3.0-0.git5.1.fc17 and 3.3.0-0.git6.1.fc17 fail
at the same point.
Has anyone been able to boot from a kernel installed from the
On Wed, 2012-02-01 at 02:38 +0100, Kay Sievers wrote:
> > Installation fails at partitioning stage, with udisksd hitting "Error
> > opening /etc/crypttab file: Failed to open file '/etc/crypttab': No such
> > file or directory (g-file-error-quark, 4)"
> > The file /etc/crypttab indeed doesn't exist. I'm not sure if this is
> > actually specific to the /usr move stuff, but it does prevent me being
> > able to ensure that installation works from a /usr-moved live image. I
> > have a non-usr-move image also, I'll test install with that.
> Sounds unlikely that this is related. But tests should show.
> Unrelated: Do you know if the installer uses udisks? If, it should
> probably switch to the current udisks2, because udisks will not much
> longer be supported, and we should people give a note about that.
Confirmed that this bug is not related to /usr move. I'm working with
anaconda team now to try and get an anaconda that's actually capable of
completing a live install, with or without the /usr move stuff.
I'm not sure if anaconda uses udisks directly, or if it's something else
calling udisksd. The udisksd error may not actually have been the cause
of the anaconda crash, according to bcl.
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora