Fedora 17’s unified filesystem (/usr-move)

Adam Williamson awilliam at redhat.com
Tue Jan 31 22:36:37 UTC 2012


On Tue, 2012-01-31 at 14:23 -0800, Adam Williamson wrote:
> On Fri, 2012-01-27 at 14:10 +0100, Harald Hoyer wrote:
> > Hello Testers and rawhide Users,
> > 
> > Fedora 17 will locate the entire base operating system in /usr. The directories
> > /bin, /sbin, /lib, /lib64 will only be symlinks:
> >  /bin → /usr/bin
> >  /sbin → /usr/sbin
> >  /lib → /usr/lib
> >  /lib64 → /usr/lib64
> 
> I've just tested building a live image from the /usr move repository. It
> boots, and the /usr move changes appear to be implemented. I'm currently
> testing if it can be installed successfully.
> 
> One thing I already noticed is that there seems to be a problem with the
> ntfs-3g executables. /bin/ntfs-3g seems to be a symlink to itself - it
> shows as "/bin/ntfs-3g -> /bin/ntfs-3g" in ls output. Trying to do 'ls
> -l /usr/bin/ntfs-3g' results in 'cannot access /usr/bin/ntfs-3g: Too
> many levels of symbolic links'. /bin/ntfsmount is similarly affected.
> 
> On a pre-/usr move system it seems that these executables are actually
> located in /bin but have symlinks in /usr/bin - /usr/bin/ntfs-3g is a
> symlink to /bin/ntfs-3g . Perhaps the existence of these symlinks
> in /usr/bin confused things?

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.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net



More information about the test mailing list