On Thu, Oct 10, 2013 at 08:08:08PM -0400, Fred Smith wrote:
Gang:
I'm puzzled...
I rebooted a while ago (and in between the down and up, I installed Fedora 20 Beta on a USB hard drive, making sure it wouldn't mess with my Centos system). The install went fine, but afterwards, when I reboot Centos, it comes up with a black screen and a clock as the mouse cursor (small clock).
Tried CTRL-ALT-BKSP and the clock disappears and reappears.
I did "init 3" to stop the apparently busted X server, removed the X lock file from /tmp and attempted "startx", which didn't work either. when startx is run I get a bunch of messages ending with:
Initializing built-in extension XFree86-VidModeExtension Initializing built-in extension XFree86-DGA Initializing built-in extension XFree86-DRI Initializing built-in extension DRI2 Loading extension GLX Loading extension NV-GLX Loading extension NV-CONTROL Loading extension XINERAMA xinit: Permission denied (errno 13): cannot open /dev/null: Permission denied
waiting for X server to shut down Server terminated successfully (0). Closing log file.
curiously, when I log in on a console I also get this:
-bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied
So something is seriously hosed here. Can anyone give me a clue?
thanks!
So, I don't know what the heck happened, but I have what looks like a solution: a number of important files in /dev somehow had their permissions changed. I had to do the following:
chmod a+rw /dev/null chmod a+rw /dev/urandom chmod a+rw /dev/zero chmod a+rw /dev/full chmod a+rw /dev/random
After which X started and the complaints about /dev/null went away. As I worked thru fixing first /dev/null, each step got me a bit further, with more complaints about inaccessable /dev/ entries, so I just kept fixing them until the complaints went away.
I also compared permissions in /dev against my Fedora 19 netbook, which is how I knew what permissions to use for the rest, as well as being where I found correct permissions, as well as /dev/zero and /dev/full being wrong.
I have NO CLUE what hosed the permissions, and I can't be sure that there may not be some other items also wrong (that I can't see because they don't appear on the F19 system).
Can anyone suggest an accurate way to have the system fix all the permissions in /dev? some arcane options on rpm, perhaps?
thanks!
Fred
-- ---- Fred Smith -- fredex@fcshome.stoneham.ma.us ----------------------------- God made him who had no sin to be sin for us, so that in him we might become the righteousness of God." --------------------------- Corinthians 5:21 ---------------------------------
On Thu, Oct 10, 2013 at 09:08:06PM -0400, Fred Smith wrote:
On Thu, Oct 10, 2013 at 08:08:08PM -0400, Fred Smith wrote:
Gang:
I'm puzzled...
I rebooted a while ago (and in between the down and up, I installed Fedora 20 Beta on a USB hard drive, making sure it wouldn't mess with my Centos system). The install went fine, but afterwards, when I reboot Centos, it comes up with a black screen and a clock as the mouse cursor (small clock).
Tried CTRL-ALT-BKSP and the clock disappears and reappears.
I did "init 3" to stop the apparently busted X server, removed the X lock file from /tmp and attempted "startx", which didn't work either. when startx is run I get a bunch of messages ending with:
Initializing built-in extension XFree86-VidModeExtension Initializing built-in extension XFree86-DGA Initializing built-in extension XFree86-DRI Initializing built-in extension DRI2 Loading extension GLX Loading extension NV-GLX Loading extension NV-CONTROL Loading extension XINERAMA xinit: Permission denied (errno 13): cannot open /dev/null: Permission denied
waiting for X server to shut down Server terminated successfully (0). Closing log file.
curiously, when I log in on a console I also get this:
-bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied -bash: /dev/null: Permission denied
So something is seriously hosed here. Can anyone give me a clue?
thanks!
So, I don't know what the heck happened, but I have what looks like a solution: a number of important files in /dev somehow had their permissions changed. I had to do the following:
chmod a+rw /dev/null chmod a+rw /dev/urandom chmod a+rw /dev/zero chmod a+rw /dev/full chmod a+rw /dev/random
After which X started and the complaints about /dev/null went away. As I worked thru fixing first /dev/null, each step got me a bit further, with more complaints about inaccessable /dev/ entries, so I just kept fixing them until the complaints went away.
I also compared permissions in /dev against my Fedora 19 netbook, which is how I knew what permissions to use for the rest, as well as being where I found correct permissions, as well as /dev/zero and /dev/full being wrong.
I have NO CLUE what hosed the permissions, and I can't be sure that there may not be some other items also wrong (that I can't see because they don't appear on the F19 system).
Can anyone suggest an accurate way to have the system fix all the permissions in /dev? some arcane options on rpm, perhaps?
thanks!
Ah, it was too good to be true. Reboot returns those files to the incorrect permissions.
Suggestions on where to look will be welcomed.
Fred
-- ---- Fred Smith -- fredex@fcshome.stoneham.ma.us ----------------------------- God made him who had no sin to be sin for us, so that in him we might become the righteousness of God." --------------------------- Corinthians 5:21 ---------------------------------
-- ---- Fred Smith -- fredex@fcshome.stoneham.ma.us ----------------------------- The Lord detests the way of the wicked but he loves those who pursue righteousness. ----------------------------- Proverbs 15:9 (niv) ----------------------------- _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
From: Fred Smith fredex@fcshome.stoneham.ma.us
I rebooted a while ago (and in between the down and up, I installed Fedora 20 Beta on a USB hard drive, making sure it wouldn't mess with my Centos system). The install went fine, but afterwards, when I reboot Centos, it comes up with a black screen and a clock as the mouse cursor (small clock).
chmod a+rw /dev/null chmod a+rw /dev/urandom chmod a+rw /dev/zero chmod a+rw /dev/full chmod a+rw /dev/random
Can anyone suggest an accurate way to have the system fix all the permissions in /dev? some arcane options on rpm, perhaps?
Nothing at all in the logs...? Global check: rpm -qVa Maybe check udev confs...?
JD
On Fri, Oct 11, 2013 at 02:50:14AM -0700, John Doe wrote:
From: Fred Smith fredex@fcshome.stoneham.ma.us
I rebooted a while ago (and in between the down and up, I installed Fedora 20 Beta on a USB hard drive, making sure it wouldn't mess with my Centos system). The install went fine, but afterwards, when I reboot Centos, it comes up with a black screen and a clock as the mouse cursor (small clock).
chmod a+rw /dev/null chmod a+rw /dev/urandom chmod a+rw /dev/zero chmod a+rw /dev/full chmod a+rw /dev/random
Can anyone suggest an accurate way to have the system fix all the permissions in /dev? some arcane options on rpm, perhaps?
Nothing at all in the logs...?
Nothing I can see in the logs looks particularly damning.
Global check: rpm -qVa
running that right now, will post again if anything interesting turns up.
Maybe check udev confs...?
I was thinking of that, but the amount I know aobut udev wouldn't cover the head of a pin. Open to suggestions, though.
On Fri, Oct 11, 2013 at 09:41:08AM -0400, Fred Smith wrote:
On Fri, Oct 11, 2013 at 02:50:14AM -0700, John Doe wrote:
From: Fred Smith fredex@fcshome.stoneham.ma.us
I rebooted a while ago (and in between the down and up, I installed Fedora 20 Beta on a USB hard drive, making sure it wouldn't mess with my Centos system). The install went fine, but afterwards, when I reboot Centos, it comes up with a black screen and a clock as the mouse cursor (small clock).
chmod a+rw /dev/null chmod a+rw /dev/urandom chmod a+rw /dev/zero chmod a+rw /dev/full chmod a+rw /dev/random
Can anyone suggest an accurate way to have the system fix all the permissions in /dev? some arcane options on rpm, perhaps?
Nothing at all in the logs...?
Nothing I can see in the logs looks particularly damning.
Global check: rpm -qVa
running that right now, will post again if anything interesting turns up.
Maybe check udev confs...?
I was thinking of that, but the amount I know aobut udev wouldn't cover the head of a pin. Open to suggestions, though.
Looking in /lib/udev/rules.d/50-udev-default.rules I see:
KERNEL=="ptmx", GROUP="tty", MODE="0666" KERNEL=="null|zero|full|random|urandom", MODE="0666"
so if I understand them right, /dev/ptmx, /dev/null, /dev/zero, /dev/full, /dev/random, and /dev/urandom should all come up as 'rw' for all users after a system boot, but they don't. I reboot and they all come up as 0644, crw-rw----. grepping for "null" in /lib/udev finds only that single entry in all of the files, as does "ptmx".
So, I wonder if something is preventing this file from being run (which seems unlikely, given that it contains a ton of rules which would all be skipped). I note that /etc/udev/rules.d contains a rules file with exactly the same name (which sets up some firewire stuff) and wonder if that's a problem,... anyone know?
On Fri, Oct 11, 2013 at 02:06:19PM -0400, Fred Smith wrote:
On Fri, Oct 11, 2013 at 09:41:08AM -0400, Fred Smith wrote:
On Fri, Oct 11, 2013 at 02:50:14AM -0700, John Doe wrote:
From: Fred Smith fredex@fcshome.stoneham.ma.us
I rebooted a while ago (and in between the down and up, I installed Fedora 20 Beta on a USB hard drive, making sure it wouldn't mess with my Centos system). The install went fine, but afterwards, when I reboot Centos, it comes up with a black screen and a clock as the mouse cursor (small clock).
chmod a+rw /dev/null chmod a+rw /dev/urandom chmod a+rw /dev/zero chmod a+rw /dev/full chmod a+rw /dev/random
Can anyone suggest an accurate way to have the system fix all the permissions in /dev? some arcane options on rpm, perhaps?
Nothing at all in the logs...?
Nothing I can see in the logs looks particularly damning.
Global check: rpm -qVa
running that right now, will post again if anything interesting turns up.
Maybe check udev confs...?
I was thinking of that, but the amount I know aobut udev wouldn't cover the head of a pin. Open to suggestions, though.
Looking in /lib/udev/rules.d/50-udev-default.rules I see:
KERNEL=="ptmx", GROUP="tty", MODE="0666" KERNEL=="null|zero|full|random|urandom", MODE="0666"
so if I understand them right, /dev/ptmx, /dev/null, /dev/zero, /dev/full, /dev/random, and /dev/urandom should all come up as 'rw' for all users after a system boot, but they don't. I reboot and they all come up as 0644, crw-rw----. grepping for "null" in /lib/udev finds only that single entry in all of the files, as does "ptmx".
So, I wonder if something is preventing this file from being run (which seems unlikely, given that it contains a ton of rules which would all be skipped). I note that /etc/udev/rules.d contains a rules file with exactly the same name (which sets up some firewire stuff) and wonder if that's a problem,... anyone know?
sigh. the problem, had this been a car, could have been diagnosed as: "There's a loose nut behind the wheel." I.e., me. it's exactly due to the duplicate udev rules filenames, one in /etc/udev/rules.d and the other in lib/udev/rules.d. Self-inflicted damage. PROBLEM SOLVED.
-
Fred Smith -
John Doe