Those vesa and fbdev errors are probably irrelevant. I use a kernel
without vesa or fbdev frame buffer support configured, because
I am using the nouveau kernel driver with an nvidia gpu, and
nouveau implements its own frame buffer internally. I have been
seeing those vesa and fbdev errors in Xorg.0.log since I first installed
Xorg on this system, and X works, so does xfce4. Xorg probably
attempts to load those drivers by default, independently of what you have
for

Code:

VIDEO_CARDS="..."

in /etc/make.conf (or /etc/portage/make.conf).

(The kernel does the same thing at boot when mounting ext4
partitions when you have ext2 and ext3 support enabled in
the kernel, too. It reports an ext2 error and then an ext3 error
before actually mounting the partition as ext4, because it tries
them in that order: "Is it ext2? No, report ext2 error. Is it ext3?
No, report ext3 error. Is it ext4? Yes, proceed normally." It can
look confusing until you get down to the message where it actually
mounts that partition as an ext4 partition.)

You should find the Xorg messages relevant to the driver for your
actual gpu after that in the Xorg log.

You may find what you need to get xfce4 working in the Xorg.0.log,
but vesa and fbdev are likely not it.

You do have "exec /usr/bin/startxfce4" as the contents of your
~/.xinitrc? (Then you can use "startx" from a login by the user
that owns that .xinitrc file to start Xorg and xfce4. It does not
need to be a root login.)_________________TIA

These can be single files covering all categories (like "sys-apps",
"sys-libs", "sys-kernel"; "ls /usr/portage" to see the categories),
or they can be sub-directories of /etc/portage/ containing
per-category files.

package.keywords are where you specify that you want
to use a package from the testing or "alpha, not even in
testing status yet" package sets. For example, I use
the testing version of the netpipes package. I don't wish
to specify to use that instead of the stable version
every time I emerge it, so, in "/etc/portage/package.keywords/net-misc",
I have this line:

Code:

net-misc/netpipes ~amd64

"~amd64" is the keyword. Keyword "~[arch]" means "emerge
the testing version". It is being tested by a group of users,
and if no regressions turn up, it will eventually become
the new stable version.

package.mask is where you block packages completely from
being emerged. My system profile says to emerge ssmtp (an smtp
server) as the default email server. I use postfix or qmail
rather than ssmtp, so I do not want ssmtp merged.
In /etc/portage/package.mask/mail-mta, I have this line:

Code:

mail-mta/ssmtp

Portage would report that ssmtp is masked if I tried to emerge
it.

package.use is where you specify USE flags that are for just
one package rather than for the whole system. For example,
I want the glibc info files installed when I install glibc.
One communicates this to the glibc ebuild with "USE=doc".
However, I do not want everything that I emerge emerged with
that USE flag enabled, so I do not put it in "USE=" in
/etc/make.conf (old way) or /etc/portage/make.conf (new way).
I do not want to need to remember it everytime that I upgrade
glibc and to need to specify it in the emerge command line,
either. So, in /etc/portage/package.use/sys-libs, I have
this line:

Code:

sys-libs/glibc doc

Portage will install the glibc info files automatically anytime
that I emerge glibc.

Portage does not care whether /etc/portage/package.{keywords, mask, use}
are single files covering all categories of packages or directories
containing per-category files. The choice is only for user convenience.
I like my entries arranged per-category, so I have per-category
files in package.* subdirectories of /etc/portage/.

A lot of keyworded and masked packages are set for your
whole system in your portage profile. To find out what
profile you are using:

Code:

# old way
ls -l /etc/make.profile
# or new way
ls -l /etc/portage/make.profile

make.profile is a symbolic link that points to some directory
under /usr/portage/profiles/.

(The "old way/new way" stuff just changed locations recently,
and I do not know which one a new installation may be using.)

Having landed in what I think of as "the udev rat's nest",
you will probably need to know this stuff to escape the resulting
tangle of confusion.

For myself, I found that masking off >= udev-181 in
/etc/portage/package.mask/sys-fs, removing the udev and thunar USE flags
from /etc/make.conf, and simply not merging thunar (the xfce4 file manager)
eliminated a lot of maintenance complications. The desktop may seem
a little less ergnomic without icons appearing for hot-plugged devices
that you can click on, etc, but "emerge world" also no longer pulls in a lot
of gnome packages and their "blocking, masking, missing USE flag" complexities.

Back to the present:
The kernel has probably detected a filesystem error of some kind and
remounted the root partition read-only. Try this:

Code:

dmesg | less

See if you can find where the kernel tries to mount the root partition.
(Your initramfs or initrd probably has some kind of error, if you are
booting with one of those.)

As for the Xorg.0.log, it looks fine with regard to your graphics
hardware. My guess would be that it is simply failing to start xfce4 for
some reason.

(You can use pastebin for logs manually without using wgetpaste.
For example, http://pastebin.ca/
)_________________TIA

Ok. For a noob are my sudden read only problems enough to warrant starting again and using this post to get xfce working afterwards? I have no data to lose yet. I'm sure it's not the way but I'm too new to face a problem this big right? All I did was install as per the handbook and emerge x and xfce. Something went wrong?

Well, you could reinstall, up to the point where things went
wrong before, then try to find out why xfce4 is not starting.

At that point you can deal with udev, gnome dependencies
of thunar, and so on as separate issues. For the record,
I had xfce4 with thunar installed on one system. I got tired
of "emerge world" pulling in gnome packages that required
me to untangle various emerge issues before it could complete.
I had already masked the udev version with this entry
in /etc/portage/package.mask/sys-fs:

Code:

>=sys-fs/udev-181

I edited /etc/make.conf, removing udev and thunar from USE=,
and I did:

Code:

emerge -C thunar

Then I ran:

Code:

revdep-rebuild -p

to see if anything more needed to be fixed up. revdep-rebuild re-emerged a few
packages with new USE flags, and since then everything that worked before still
works (I never used thunar anyway, did not hotplug things, etc).

So removing thunar after it and all of its dependencies are already
installed works without major breakdown of the system.

revdep-rebuild is part of the gentoolkit package. You will need to emerge gentoolkit,
usually sooner rather than later. It also contains a command called "equery",
invaluable for finding out what package things belong to and various
other useful information about package dependencies, USE flags, etc.

Whether to reinstall or try to unbreak what you have installed now
is up to you.

edit:
One can of course untangle thunar's gnome dependencies at emerge
time and just use it if it suits you. I simply did not want to spend the time
to do that for something that I considered a "desktop frill" anyway._________________TIA