kubuntu apt-get not installed
Tried what you suggested Adam, and got 'command not found' for aptitude install apt. Also had 'command not found' for sudo aptitude install apt. In fact I also tried commands ls, man, sudo, and they all returned 'command not found'. Does this mean that all (most) of my commands are unavailable? About a week ago I went through the update procedure. I started with Dapper 6.06 (from live CD), updated to Edgy 6.10, then updated to Feisty 7.04. Things worked perfectly until last weekend when I tried to boot up linux and got this result. Would I presume that the live CD 6.06 would not now be of any use since I am 2 upgrades up? I've alo tried recover mode at Grub but doesn't work either - same results. Is there such a thing as a rescue disk that will repair my OS without losing my work? Fortunately I am dual booting with Win98 (wash my mouth out), but it is a right pain rebooting backwards and forwards. I look forward to any suggestions - elc
It gets to a point "the program 'apt-get' is currently not installed. You can install it by typing: apt-get install apt
Try
aptitude install apt (or possibly sudo aptitude install apt)
What I am trying to get to is my normal GUI or desktop.
It sounds like your machine might have serious problems, has anything changed recently or any other things that might be relevant to this problem?
Adam
On Tue, 2007-06-12 at 23:31 +0100, elc wrote:
Tried what you suggested Adam, and got 'command not found' for aptitude install apt. Also had 'command not found' for sudo aptitude install apt. In fact I also tried commands ls, man, sudo, and they all returned 'command not found'.
Does this mean that all (most) of my commands are unavailable?
Given that it worked for a while after the upgrade I am guessin that either your system volumes is not available or your path is wrong. What is the output of - echo $PATH (case sensitive) does /bin/ls work rather than ls on it's own ? or /usr/bin/apt-get ? Can you 'cd' to /bin or /usr/sbin ?
On 12-Jun-07 22:31:22, elc wrote:
Tried what you suggested Adam, and got 'command not found' for aptitude install apt. Also had 'command not found' for sudo aptitude install apt. In fact I also tried commands ls, man, sudo, and they all returned 'command not found'.
Does this mean that all (most) of my commands are unavailable?
Looks to me as though your PATH is empty, so your shell has nowhere to look for the commands.
From you command line, enter:
set and look down the resulting list for a line that starts with "PATH=...." If you do not find one, then you have an empty PATH and that is the problem. On the other hand, if you get a result which includes things like PATH=/usr/local/bin:/bin:/usr/bin:.... then you have real problems. In particular, the command 'ls' should be in /bin. and therefore found; the command 'man' should be in /usr/bin and likewise found. So in that case there is something seriously wrong with your installation. If you have an empty PATH, this means that some initial configuration is not taking place when you log in, and we can probably help you track that down (there are not a lot of possibilities for what could go wrong there). But if you get a PATH like the above, it's trouble! ('set', by the way, should work regardless of your PATH since it is a shell command and not a binary. On the other hand, if your PATH is empty, then 'echo $PATH' will not work, since 'echo' is in /bin. Nor will 'env', since it is also in /bin)). Hoping this helps. Let us know what you see! Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <ted.harding@nessie.mcc.ac.uk> Fax-to-email: +44 (0)870 094 0861 Date: 13-Jun-07 Time: 00:54:25 ------------------------------ XFMail ------------------------------
On Wed, 2007-06-13 at 00:54 +0100, ted.harding@nessie.mcc.ac.uk wrote:
('set', by the way, should work regardless of your PATH since it is a shell command and not a binary. On the other hand, if your PATH is empty, then 'echo $PATH' will not work, since 'echo' is in /bin. Nor will 'env', since it is also in /bin)).
A good point Ted ! of course if the path is the problem echo $PATH won't work 'set' is the way forward
On Wed, Jun 13, 2007 at 01:08:13AM +0100, Wayne Stallwood wrote:
On Wed, 2007-06-13 at 00:54 +0100, ted.harding@nessie.mcc.ac.uk wrote:
('set', by the way, should work regardless of your PATH since it is a shell command and not a binary. On the other hand, if your PATH is empty, then 'echo $PATH' will not work, since 'echo' is in /bin. Nor will 'env', since it is also in /bin)).
A good point Ted !
of course if the path is the problem echo $PATH won't work 'set' is the way forward
Errr, echo is a bash builtin, too (and has been for quite some time) - so, it *should* work - I don't know what half arsed shell Ted is using, but most of them have echo builtin as far as I'm aware. Thanks, -- Brett Parker
On 13-Jun-07 07:02:04, Brett Parker wrote:
On Wed, Jun 13, 2007 at 01:08:13AM +0100, Wayne Stallwood wrote:
On Wed, 2007-06-13 at 00:54 +0100, ted.harding@nessie.mcc.ac.uk wrote:
('set', by the way, should work regardless of your PATH since it is a shell command and not a binary. On the other hand, if your PATH is empty, then 'echo $PATH' will not work, since 'echo' is in /bin. Nor will 'env', since it is also in /bin)).
A good point Ted !
of course if the path is the problem echo $PATH won't work 'set' is the way forward
Errr, echo is a bash builtin, too (and has been for quite some time) - so, it *should* work - I don't know what half arsed shell Ted is using, but most of them have echo builtin as far as I'm aware.
True enough -- now that you point it out and I check it in "man bash". I'd been going on the result of "which echo" (--> /bin/echo) and on a mind-set established long before bash was born. So, indeed, echo $PATH whould work if bash is working, and is of course handier than picking through the output of 'set'. It follows (on this tangential thread) that you should also refer to "help echo" (for the shell one) rather than "man echo" (for the /bin/echo one), since there are (on my system at least) slight differences between these two implementations. -------------------------------------------------------------------- E-Mail: (Ted Harding) <ted.harding@nessie.mcc.ac.uk> Fax-to-email: +44 (0)870 094 0861 Date: 13-Jun-07 Time: 08:37:46 ------------------------------ XFMail ------------------------------
(Ted Harding) wrote:
On 13-Jun-07 07:02:04, Brett Parker wrote:
Errr, echo is a bash builtin, too (and has been for quite some time) - so, it *should* work - I don't know what half arsed shell Ted is using, but most of them have echo builtin as far as I'm aware.
True enough -- now that you point it out and I check it in "man bash".
I'd been going on the result of "which echo" (--> /bin/echo) and on a mind-set established long before bash was born.
Try "type echo" instead of "which echo" JD -- "They hang out in groups of five. That's because they have one fifth of a personality each. " - Eddie Izzard
On 13-Jun-07 08:07:29, Jon Dye wrote:
(Ted Harding) wrote:
On 13-Jun-07 07:02:04, Brett Parker wrote:
Errr, echo is a bash builtin, too (and has been for quite some time) - so, it *should* work - I don't know what half arsed shell Ted is using, but most of them have echo builtin as far as I'm aware.
True enough -- now that you point it out and I check it in "man bash".
I'd been going on the result of "which echo" (--> /bin/echo) and on a mind-set established long before bash was born.
Try "type echo" instead of "which echo"
JD
And, now that you point that out, type -a echo gives you the lot: $ type -a echo echo is a shell builtin echo is /bin/echo $ type -a type type is a shell builtin Which raises an interesting question: If "type -a" can find everything (including binaries), it must be making implicit reference to a PATH which presumably is the user's $PATH by default (though neither "help type" nor "man bash" is explicit about this). You can of course set a search-path with option "-P" to "type". So, since "type" is a shell built-in, it should work for elc whatever the PATH situation is. Therefore, going back to the "missing" commands, if elc enters, for instance, type -a ls and gets: $ type -a ls bash: type: ls: not found while "type -aP /bin ls" gives $type -aP /bin ls /bin/ls this is presumably a pretty sure-fire diagnostic of PATH problems. Best wishes to all, Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <ted.harding@nessie.mcc.ac.uk> Fax-to-email: +44 (0)870 094 0861 Date: 13-Jun-07 Time: 09:43:48 ------------------------------ XFMail ------------------------------
On Tuesday 12 June 2007 23:31:22 elc wrote:
Tried what you suggested Adam, and got 'command not found' for aptitude install apt. Also had 'command not found' for sudo aptitude install apt. In fact I also tried commands ls, man, sudo, and they all returned 'command not found'.
I look forward to any suggestions - elc
Your problem may well be disk errors, but in case you just want to get apt installed (which will be handy for helping to diagnose other problems) try this. (Note, however, that if your disk is /very/ broken, this is unlikely to work.) 1) Check dpkg and wget are still available: $ which dpkg /usr/bin/dpkg $ which wget /usr/bin/wget (if dpkg isn't there then, um, well I'm not sure what you'll do) (if wget is unavailable then you can just use a web browser) 2) Download the apt deb: $ wget http://www.mirror.ac.uk/mirror/archive.ubuntu.com/ubuntu/pool/main/a/apt/apt... [previous command all on one line] 3) install it: $ sudo dpkg -i apt_0.6.46.4ubuntu10_i386.deb And then you should have apt back on your box which will mean you can (re)install other useful things. e.g.: $ sudo apt-get --reinstall install coreutils May I also suggest smartmontools? To help diagnose any possible disk errors? Also, you may like to run an fsck (filesystem check; see $ man fsck). The easiest way to do this is to force one to be scheduled next time you boot. (fsck is most effective when run in single user mode.) $ sudo tune2fs -c 0 -i 30d -T 20070501 (This is a bit of a hack so I'd better explain: it makes tune2fs check the drive on boot every every 30 days ["-i 30d"], tells it not to schedule tests based on the number of times the drive has been mounted ["-c 0"] and tells it that the last time it was checked was 1st May 2007 which, assuming your computer's clock is about right, was more than 30 days ago; see also $ man tune2fs) This will do an fsck next time you boot. Cheers, Richard PS. I've just read the rest of this thread more carefully and now my message seems a bit unhelpful (seeing as how you don't seem to /any/ programs available). But I've typed it now, so I'm going to send it anyway. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Richard Lewis http://www.richard-lewis.me.uk/ JID: ironchicken@jabber.earth.li -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
On Tuesday 12 June 2007 23:31, elc wrote:
About a week ago I went through the update procedure. I started with Dapper 6.06 (from live CD), updated to Edgy 6.10, then updated to Feisty 7.04. Things worked perfectly until last weekend when I tried to boot up linux and got this result. Would I presume that the live CD 6.06 would not now be of any use since I am 2 upgrades up?
I wonder. Could you post me/the list the output of the following two commands please? cat /etc/fstab blkid Cheers :-) -- There are 10 types of people in this world, those who understand binary, and those who don't.
participants (7)
-
Brett Parker -
elc -
Jon Dye -
Richard Lewis -
ted.harding＠nessie.mcc.ac.uk -
Ten -
Wayne Stallwood