Cross compiling on x86_64 to pentium4
by Jonathan Ryshpan
I need to build a program on an x86_64 system to run on an old laptop,
which uses a pentium4. What's the most convenient way to build this on
a Fedora-16 system?
Thanks - jon
12 years, 1 month
Vps encrypted root partition
by Marco Vittorini Orgeas
Hello,
I'd like to encrypt sensible data on a VPS linux instance (emails,
etc...) and I would proceed with a dm-crypt encrypted root tree (apart
from /boot).
Now the only downside I see is that in case of unexpected reboot I have
to insert the pass-phrase
to have the system booted.
Any hints/recommendation/warnings about this configuration ?
It's my first try at it.
Thanks
Marco
12 years, 1 month
Filesystem arch changes in Fedora 17
by Alan Rodas
Hello everybody, I'm new to this list, although I have been using
Fedora for a little while now.
As I finally decided to adopt Fedora as my main linux OS I decided
that it was time to join this list.
I would like to ask about the changes in the FS for the new release of Fedora.
I understand that FS are changing as follows
/bin → /usr/bin
/sbin → /usr/sbin
/lib → /usr/lib
/lib64 → /usr/lib64
And after reading the benefits of the changes I seem to agree that it
is an excellent decision.
But after reading Lennart's mail at
http://thread.gmane.org/gmane.linux.redhat.fedora.devel/155511/focus=155792
In his email Lennart argues, for what I understood, that there is no
need for sbin a bin separation anymore, but a merge between bin and
sbin has not been done, and I was wondering why.
Also, there are many other directories that doesn't seem to fulfill
they original purpose anymore, like /opt (Things in /opt could be
easily installed in /usr/local for what is seems, is that right or am
I missing something?). Are there any plans to get rid of this folders?
Thanks for any answer that you may give me, and forgive if this things
have already been answered, but I sware I use my google-fu but
couldn't find an answer.
Cheers
--
Alan Rodas Bonjour
12 years, 1 month
SELinux preventing login (Fedora 16)
by Braden McDaniel
I have a Fedora 16 box where something seems to have gone sideways with
SELinux. I am unable to log into the box with SELinux enabled. I see
messages in /var/log/messages that look like this:
Apr 11 02:40:06 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:40:06 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:40:07 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:40:10 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:40:26 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:40:58 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:42:02 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:42:02 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:42:02 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:42:06 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:42:14 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:42:30 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Apr 11 02:43:02 rail setroubleshoot: SELinux is preventing /usr/libexec/accounts-daemon from name_connect access on the tcp_socket . For complete SELinux messages. run sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
I tried doing a full relabel; but that had no noticeable effect. If I
boot to single user mode and disable SELinux (via /etc/selinux/config),
I'm able to log in and things appear to be functional. Well, with the
caveat that the suggestion in the message to run sealert yields this:
# sealert -l aeded892-dec1-4e6d-87ce-7c10a4e42e2b
Opps, sealert hit an error!
Traceback (most recent call last):
File "/usr/bin/sealert", line 668, in <module>
proxy_obj = bus.get_object(dbus_system_bus_name, dbus_system_object_path)
File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 244, in get_object
follow_name_owner_changes=follow_name_owner_changes)
File "/usr/lib/python2.7/site-packages/dbus/proxies.py", line 241, in __init__
self._named_service = conn.activate_name_owner(bus_name)
File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 183, in activate_name_owner
self.start_service_by_name(bus_name)
File "/usr/lib/python2.7/site-packages/dbus/bus.py", line 281, in start_service_by_name
'su', (bus_name, flags)))
File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 630, in call_blocking
message, timeout)
DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 3
Any idea what happened here and how I might actually fix it?
--
Braden McDaniel <braden(a)endoframe.com>
12 years, 1 month
Triple-head with a 2nd (different) gfx card, possible?
by Fernando Cassia
Hi there,
My current setup includes a PCI-X ATI X1600 board, which its dual DVI+VGA
outputs.
That card has two 19' monitors connected, a DVI one and a VGA-only one,
both LGs.
Now, suppose I don't want to buy another gfx board, but rather connect an
external USB-to-VGA adapters like these:
http://goo.gl/TqchG
Would Fedora recognize the 3rd display (no matter it being much slower due
to the USB 2.0 interface) and put the 3rd screen alongside the other two so
I can move app windows from one monitor to the next?
Or would it be a separate X display because it's handled by a different
driver?
TIA
FC
--
During times of Universal Deceit, telling the truth becomes a revolutionary
act
- George Orwell
12 years, 1 month
Sudo, is this valid?
by Frank Murphy
Checking beore any snafu.
visudo
add the following
# Clamav User Commands
clamav ALL=/usr/bin/clamd.clamav /sbin/systemctl
# Hopefully this will allow clamav to run
# systemctl reload clamd.clamav.service
--
Regards,
Frank
"Jack of all, fubars"
12 years, 1 month
