[SOLVED] permission denied on everything using debian 7

sfzombie13 · 04-17-2014, 11:35 PM

well, i was having issues with the lfs build i was trying on my suse box, so i swapped out the hard drive and installed debian 7. it is acting worse than the suse. almost every command i give has to be sudo or it says permission denied. i got up the the binutils build doing this, pain in the butt, but workable. when i got to the gcc build, it wouldn't change the default dynamic linker. i tried putting sudo in front of the first lins, but i get the error message that says "sudo: command for not found". i set all the permissions like the book said, followed step by step. i have been all the way through this build five times now and haven't gotten past this part for one reason or another. hell, if i ever got to the next one i should have found ways around everything that could happen.

ReaperX7 · 04-17-2014, 11:46 PM

Only Slackware is a recommended distribution to build Linux From Scratch with by the members of this forum. Other distributions take work to make them useable, or don't work at all. As per notice regarding this, we can not help you "make" a distribution B/LFS build compliant. You either have to use Slackware, or a derivative, or roll the gambling dice.

Did you follow all the instructions in the book exactly as they were written?

Are you building LFS as root and not through sudo?

sfzombie13 · 04-18-2014, 06:51 AM

slackware it is then. i was trying to stay away from that because i am familiar with suse and debian, but i would also like to get this finished. on the plus side, it only takes me about an hour and a half to get to the gcc make instead of all day like the first time. and i am learning a lot, really the whole point here.

yes, followed exactly, and i am even cutting and pasting now to eliminate most of my typo errors. and i did the whole thing through sudo while logged in as lfs user. most of the commands would not work unless i did sudo. another plus, when i sudo a bunch of commands in a row, i only have to put the password in once in a while and not every command like i used to have to do (can't remember which distro that was but it was a while ago).

one more reinstall and i'll give it another try. slackware can't be too hard to figure out. thanx for the advice and i hope to not to be posting here again for a while. enjoy the beautiful weekend all! happy earth day!

stoat · 04-18-2014, 07:40 AM

I second the Slackware idea. I now use my last BLFS system as host for new systems, but the last time I used a distro for that it was Slackware. But IMO, your GCC problems were not related to Debian. You were "making adjustments", doing "workarounds", renaming things, moving folders and tarballs, thinking the book was wrong, and so on. You never had even slightest chance of moving past GCC like that.

Regarding sudo, it's useful when scripting LFS builds. But sudo expects to be followed by a command. So you have to watch out for certain things copied from the book and then put after a sudo command. For example, for-do loops, if-fi statments, &&, ||, /, and so on. To use sudo in scripts, I had to reorganize blocks of commands copied straight from the book to break apart or "reconnect" long commands continued with /, or multiple commands run with &&, or to put sudo inside for-do loops and if-fi statements. Things like that. So with all the issues you currently are having merely typing or copying the book's commands as written, I recommend against any method or situation that requires you to modify anything.

P.S.: For a "distro" on a six-month release schedule, all this v7.5 stuff now can be considered sort of "mature", IMO. The LFS 7.5 book has no published errata at all. And the only errata published for BLFS 7.5 is about that openssl-1.0.1f security issue. I have built LFS 7.5 probably ten times by script, and I have built my usual BLFS system from the v7.5 book by hand, all without any issues. I only mention this stuff to encourage you to move "the book is wrong" way down your list of troubleshooting ideas. It's always possible, but unlikely at this point in your case. All meant in the kindest possible way.

sfzombie13 · 04-18-2014, 09:48 AM

stoat, i am with you completely. the book should be right, but i can assure you it is not. example, in the gcc build, it tells you at the top to untar the source then move into that directory. then under the mpfr, mpc, and gmp parts, it tells you to mkdir -v ../gcc-build and cd ../gcc-build. now that's just minor thing, but it is out of sequence, and i could be reading it wrong, but i think it is right. took me a while and my first question to get that one. this is my third question, and now i have installed slackware 14.1, with everything except the laptop option, and am at it again. when i got to the part about setting up the environment, 4.4, it gives me a permission denied after the EOF of the script. this is the same as suse and the same as debian.
i am not upset, i learned a great deal with these errors and the week of trying to build lfs, not to mention that now i have three hard drives with different distros of linux that i can plug and play. my ultimate goal is to link a dozen old boxes into a super computer. but i digress.

so, do i sudo the commands, and then go with it? and if so, how the hell am i supposed to figure out how to break up the scripts and such to make them work? i was looking for a way to figure out how to compile and lock down linux from nothing, but this is turning into a programming course, which i am not ready to sign on for. if there is an easy switch, say in the sudo file giving the lfs group or user full root privileges, that would be cool. as i said, this has really got it's hooks into me, but i don't have much more time to devote to it full time. thanx for the answers and advice, have a great weekend!

Code:

bash-4.2# mkdir -v $LFS/tools
mkdir: created directory '/mnt/lfs/tools'
bash-4.2# ln -sv $LFS/tools /
'/tools' -> '/mnt/lfs/tools'
bash-4.2# echo $LFS
/mnt/lfs
bash-4.2# groupadd lfs
bash-4.2# useradd -s /bin/bash -g lfs -m -k /dev/null lfs
useradd: warning: the home directory already exists.
Not copying any file from skel directory into it.
bash-4.2# passwd lfs
Changing password for lfs
Enter the new password (minimum of 5 characters)
Please use a combination of upper and lower case letters and numbers.
New password: 
Bad password: too simple.  
Warning: weak password (enter it again to use it anyway).
New password: 
Re-enter new password: 
passwd: password changed.
bash-4.2# chown -v lfs $LFS/tools
changed ownership of '/mnt/lfs/tools' from root to lfs
bash-4.2# chown -v lfs $LFS/sources
changed ownership of '/mnt/lfs/sources' from root to lfs
bash-4.2# su - lfs

Unix, n:
        A computer operating system, once thought to be flabby and
        impotent, that now shows a surprising interest in making off
        with the workstation harem.

lfs@barney:~$ cat > ~/.bash_profile << "EOF"
> exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
> EOF
-su: /home/lfs/.bash_profile: Permission denied
lfs@barney:~$ cat > ~/.bashrc << "EOF"
> set +h
> umask 022
> LFS=/mnt/lfs
> LC_ALL=POSIX
> LFS_TGT=$(uname -m)-lfs-linux-gnu
> PATH=/tools/bin:/bin:/usr/bin
> export LFS LC_ALL LFS_TGT PATH
> EOF
-su: /home/lfs/.bashrc: Permission denied

ReaperX7 · 04-18-2014, 01:12 PM

LFS should be built as root, not sudo. One of the core administrative fundamentals taught by Slackware, Gentoo, and CRUX is that you should have control over the software of your system, not the software of your system having control over you.

Administrative tasks can be ran via sudo, but there are times when you need to have root login capabilities and many distributions are somewhat convoluted in that aspect that you don't need root login and can use sudo. Then again these systems aren't really designed with developers in mind, but end users. Software development is an after-thought for many mainstream distributions.

Several key reason we recommend those four distributions above is:

1. They all come with a compiler and most, if not all, required tool-kits.

2. They are centered around you having complete control of the OS.

3. These systems are a good insight into LFS regarding building packages and having to manually do things such as dependency resolution. Gentoo has some dependency resolution, but not everything is always in portage.

stoat · 04-18-2014, 01:46 PM

Quote:

Originally Posted by sfzombie13

...the book should be right, but i can assure you it is not. example, in the gcc build, it tells you at the top to untar the source then move into that directory. then under the mpfr, mpc, and gmp parts, it tells you to mkdir -v ../gcc-build and cd ../gcc-build. now that's just minor thing, but it is out of sequence...

Well, I'm sorry that you still maintain that belief. But you simply don't understand the book's steps. That GCC stuff has been like that for years. Many people have built LFS systems over the years with the GCC section just as it is now. That right there should be a hint to you that you might not understand it. Anyway, I have failed you by not being able to explain it in a way you can accept and do. Try going to the lfs-support mailing list and reporting what you think is wrong with the GCC instructions. Maybe the actual developers can choose words that are more convincing than mine.

Quote:

Originally Posted by sfzombie13

so, do i sudo the commands, and then go with it? and if so, how the hell am i supposed to figure out how to break up the scripts and such to make them work?

I never told you to use sudo. You decided to do that on your own and posted here about the errors caused by building with sudo. I merely attempted to explain why that happened and how sudo will act up if you try entering commands from the book that have bash stuff in them (&&, ||, /, etc.). I only said that sudo is used by people who script the LFS book commands and that it requires changes to certain commands when they are put into a script. I never ever intended for those comments to be interpreted as recommendations for you. I still firmly recommend that you trust the book and follow the steps exactly as written. So far, you have done neither of those two things.

Quote:

Originally Posted by sfzombie13

...this is turning into a programming course, which i am not ready to sign on for.

I am truly sorry things happened this way. But I repeat in the kindest possible way and with best intentions, that you are solely and completely responsible for the way things have turned out.

ReaperX7 · 04-18-2014, 02:01 PM

Try not to think too heavily on what's right or wrong.

I suggest getting familiarized with Slackware first before you leap into B/LFS any further. Familiarize yourself with hands-on administration techniques and low-level system management using shell commands, shell scripts, and text based configurations. Basically put, get back to basics with GNU/Linux. Learning GNU/Linux is a key aspect to using B/LFS successfully and even building it.

You're not expected to know everything about coding and programming. The most you'll ever get into that is drafting a shell script, and nothing more. If you you can handle that, the rest will be easy enough.

There's one thing all of us B/LFSers will tell you...

Unless it's the SVN... the book is NEVER wrong. Only the SVN book is allowed to be wrong, because it's a developmental edition that can have flaws.

sfzombie13 · 04-18-2014, 02:35 PM

thanx to all of you for the extreme patience you have shown with my idiotic questioning. i am going to give it a run as root as suggested, and this is what makes sense to me also. the only thing i have left to say about the book, and it is most likely due to me and not the book, is why it asked me to create the user lfs, and the group lfs, then log into the user lfs and finish, even going so far as to say "make sure you are lfs when unpacking" at one point, if in fact, i should be root when i build lfs?

trust me, after a week of delving into the command line and researching to fix the issues which have cropped up that did not make it into these questions, i have very much reconnected with my linux from long ago. and when run with a kde desktop environment, it is really hard to tell the difference between slackware, debian and suse. some minor things, but very familiar. thanx again to those who have the patience to try to assist boneheads such as myself.

stoat · 04-18-2014, 04:01 PM

Quote:

Originally Posted by sfzombie13

the only thing i have left to say about the book, and it is most likely due to me and not the book, is why it asked me to create the user lfs, and the group lfs, then log into the user lfs and finish, even going so far as to say "make sure you are lfs when unpacking" at one point, if in fact, i should be root when i build lfs?

To clarify that particular thing... The lfs user does every step in chapter 5. Beginning with chapter 6, the root user does every command to the end of the book. I think that misunderstanding came about from comments related only to the momentary diversion into a discussion about sudo. I wish that had never taken place, but that originated with you in post #3. It was proper IMO to address that, but it may have eventually led to a misunderstanding. In chaper 5 of the LFS book root (and sudo) has no role until the very end in section 5.36.

sfzombie13 · 04-18-2014, 04:45 PM

you know, that's funny. the only way i can get the gcc to compile correctly is with logging in as root. i had never thought of that, so when i tried it, it went past the prepare compile part with the script and i thought i was home free. then, when i tried to make it, it failed pretty quickly. i looked at the config.log and it said that

Code:

configure:4232: checking for C compiler default output file name
configure:4254: gcc    conftest.c  >&5
gcc: error trying to exec 'cc1': execvp: No such file or directory
configure:4258: $? = 1
configure:4295: result: 
configure: failed program was:
| /* confdefs.h */

when i went back to the system prerequisites and ran the script, sure enough,

Code:

bash, version 4.2.45(2)-release
/bin/sh -> /bin/bash
Binutils: (Linux/GNU Binutils) 2.23.52.0.1.20130226
bison (GNU Bison) 2.7
/usr/bin/yacc -> /usr/bin/yacc
bzip2,  Version 1.0.6, 6-Sept-2010.
Coreutils:  8.21
diff (GNU diffutils) 3.3
find (GNU findutils) 4.4.2
GNU Awk 4.1.0, API: 1.0 (GNU MPFR 3.1.2, GNU MP 5.1.3)
/usr/bin/awk -> /bin/gawk-4.1.0
gcc (GCC) 4.8.2
g++ (GCC) 4.8.2
(GNU libc) 2.17
grep (GNU grep) 2.14
gzip 1.6
Linux version 3.10.17-smp (root@hive) (gcc version 4.8.2 (GCC) ) #2 SMP Wed Oct 23 17:13:14 CDT 2013
m4 (GNU M4) 1.4.17
GNU Make 3.82
GNU patch 2.7
Perl version='5.18.1';
sed (GNU sed) 4.2.2
tar (GNU tar) 1.26
xz (XZ Utils) 5.0.5
g++: error trying to exec 'cc1plus': execvp: No such file or directory
g++ compilation failed
libgmp.la: found
libmpfr.la: found
libmpc.la: found

i hadn't thought to check it first like i did with the others. i looked at the package list for the .iso i downloaded and installed this morning and it lists the version of gcc as 4.8.2. now i truly am stumped. perhaps it was a corrupted install of the gcc or something? and is there an easy way to fix it or should i just blow the whole thing and reinstall? that's not a problem to me, it just always seemed like a last ditch effort. when i worked at tech support, i finally accepted that sometimes that was the fix. i am not quick to jump to it, but if a fix takes a day to find and an hour to implement, and reinstalling takes an hour to do and an hour to get back to this point, then i am all for it at this point. i took a week to get to 5.5, and if this hadn't come up, i could have gotten done today.

edit: it appears that when i try slackpkg update gpg after uncommenting a mirror in the slackpkg folder, it gives me the error, command not found. if it has the floder, it should be installed, no? i don't know how to resolve dependencies manually, i remember that is what kept me out of linux in the early days. if i could get the compiler working, it should be a snap from here. should be.

sfzombie13 · 04-18-2014, 10:52 PM

well, marking as solved. turns out that rebooting tow more times (that was the first thing i tried) got the compiler working, but didn't help with anything else, so i reinstalled, again, and lo and behold, it is working. i am finally doing a make install on gcc-4.8.2!! as this was the hump i had to get over, hopefully i should have fewer bumps from here on out. sometimes a reinstall is the answer. thanx for all the help guys, have a great earth day.

sfzombie13 · 04-19-2014, 10:55 AM

stoat, i am calling you out! fantastic job on making me see the light!!! all of the errors i had were caused by a blown install. when i reinstalled, i started step-by-step cut and paste by the book, and now i am in chapter 6!! you, sir, rock! i am hard headed and will argue when i think i am right, and in this case indeed i thought i was. your last post finally convinced me to reinstall and try again, and it worked. i have learned so much that now i can interpret the meanings of the long commands before i read them. thank you and have a great weekend!

eta: not to downplay the advice given by reaper, it was absolutely correct, and very much appreciated. happy earth day to everyone!