Before it said that the directory /us/ doesn't exist, now it just says it can't cd to it.

I should just give up on Linux, for the 5th or so time. Every time I try to use it theres always some unsolvable error or problem that prevents me from doing anything I want to do. All distros are so broken, slow, incomplete, and user-unfriendly, even if you know what you're doing.

There is no directory "/us". There is a directory "/mnt/us". If you are inside "/mnt", "cd us" will get you into that directory. "cd /mnt/us" will get you into that directory whereever you currently are. "cd mnt/us" will get you into that directory if you are currently in "/".

It's all very logical, but it requires a little bit of learning and understanding. If you're not up to that task, then the developer's forum might be the wrong place.

I'm sorry if you are offended by this (I realize that I'm stating things quite bluntly), but the purpose of this forum is not to help newbies find their way around. Of course we try to help each other in gaining new insights, but at least a minimum of effort is also expected from your side.

This forum is mostly about the internals of the Kindle, that's why it's called the "developer's forum". Before poking around with the internals of a Linux system (which the Kindle is), you are at least expected to understand the basics of the system.

One thing to keep in mind when reading those sites, is that when dealing with a "Linux Powered Device" you are then dealing with something called: "Embedded Linux".

You will not find many web sites for "Embedded Linux Newbies" - embedded Linux isn't a newbie subject, not hardly.

Now the basics behind your posted confusion, this may help you past your current frustration point:

Linux uses a "Single Rooted" file system tree, rooted at the highest level directory seperator "/".
Operating systems based on Unix all have this sort of file system tree, not just Linux and Mac OSx.

Some other common operating systems use "Multiple Rooted" file system trees.
Those systems have a file system tree rooted at each storage device.
On those systems, a fully specified path includes the device name (that file system's root) as in C:, D:, E:, etc.

Likewise, on a single rooted system, a fully specified path includes the file system's root. In Linux, that file system root is written: / the same as a path seperator character.

So any time you enter a path that includes the root of the file system, the path is considered by the system as "absolute".

Any time you do not include the root of the file system in the path entered, the path is considered by the system as "relative to current location in the tree".

Where you are currently in the file system tree in a *nix system can be found with the:
pwd

The cd command works a bit differently between *nix systems and some other common systems.
In *nix, cd without any arguments changes the current directory to the "home" directory of the current user.
In some other common systems, cd without any arguments displays your current working directory.

This difference can get a user who isn't familar with the *nix behavior lost in the file tree in a hurry.

Now you should be able to navigate either type of file system if you know how to navigate in one of them.

Thank you for the explanation knc1. Sometimes I can get Telnet to work, but sometimes it just wants to give me errors all the time.

But, I had to uninstall Ubuntu since I couldn't boot into it anymore. Upon boot it said some partitions/drives were not ready or not responding, and to sip with S, except it had yet to load the drivers for my keyboard, so I couldn't press S.

So far I've tried Linux Mint and Ubuntu, and both wouldn't boot. Mint installed fine, but after 30 minutes, would freeze when I tried to boot into it. Now I'm thinking CentOS, for stability (hopefully more stability than I've experienced). Any suggestions for which distro to use would be appreciated.

Obviously if I'm going to learn to program for my Kindle than it'd be better to have a Linux OS on my computer; if only one would work!

I'm trying my best to learn how to use (embedded) Linux, since mobile devices have always been more alluring to me than desktops and laptops.

Thank you for the explanation knc1. Sometimes I can get Telnet to work, but sometimes it just wants to give me errors all the time.

But, I had to uninstall Ubuntu since I couldn't boot into it anymore. Upon boot it said some partitions/drives were not ready or not responding, and to sip with S, except it had yet to load the drivers for my keyboard, so I couldn't press S.

So far I've tried Linux Mint and Ubuntu, and both wouldn't boot. Mint installed fine, but after 30 minutes, would freeze when I tried to boot into it. Now I'm thinking CentOS, for stability (hopefully more stability than I've experienced). Any suggestions for which distro to use would be appreciated.

Obviously if I'm going to learn to program for my Kindle than it'd be better to have a Linux OS on my computer; if only one would work!

I'm trying my best to learn how to use (embedded) Linux, since mobile devices have always been more alluring to me than desktops and laptops.

There seems to be a common thread in all of that, "hardware trouble" -
A failing disk drive would account for all that you mention above.

Rather than try to install a Linux distribution to this machine, why not run from a LiveCD or LiveDVD?
Those run in RAM (some support a persistent file), either boot from plastic or USB.
Since these releases run in RAM, they usually need at least 500Mbyte installed on your machine.
But, if something screws up - just power cycle the machine and start over.

Or any of the other links that have a "current/*.6.7.1.*" in their file tree.

You can fit the small (CD) version on a 4Gbyte usb stick with 3Gbyte of user filespace;
You can fit the large (DVD) version on a 8Gbyte usb stick with 3Gbyte of user filespace;
If your machine can't boot from USB (check your bios settings), then there is a "boot only" CD image that will let you use your cd drive to boot the system installed on USB stick.

That should elimenate any possible harddrive problems for the troubleshooting.

Now, the "connection refused" message -
Usually means that sshd (the server side) isn't running on the Kindle.

Try (dash double v):
ssh -vv where-ever
And post enough of the taling lines so we can see where it is failing at in the connection process.

No, it's over USB, not wifi. I forgot to mention, that telnet connects instantly, although every once in a while it will lose the connection.

Sorry, all these problems and issues with getting stuff to work is frustrating me. :P I'm calm now.

Yes, SSH over USB can be incredibly slow to connect on the DX and DXG as well as the K3. I usually just telnet in to save time. It was explained to me by another developer that this may be due to the version of openssl being used here requiring more CPU power than is available on these devices. SSL authentication requires a lot of CPU power by DESIGN, to make brute-forcing of SSL keys take a long time even with very fast computers. As I understand this, some versions of openssl for embedded systems use weaker security so that small devices can connect more quickly. Perhaps SSH connections can be made faster by using a faster openssl library in a static-linked dropbear package.

Yes, SSH over USB can be incredibly slow to connect on the DX and DXG as well as the K3. I usually just telnet in to save time.
- - snip - -
It was explained to me by another developer that this may be due to the version of openssl being used here requiring more CPU power than is available on these devices.

Close to most likely reason.

Subject came up this past week on the OpenSSL mailing list (again).

The most likely cause in these small, inactive, embedded devices is getting enough bytes out of /dev/random. Those bytes are needed while generating per-session keys, meaning the connection will not complete (whole process will stall) until /dev/random fills back up.
That can take a long time on an embedded device under Linux without other events happening.

Now if any reader here running into this "slow to connect" problem would just post the output of ssh -vv what-ever, we could see where the connection process is stalling.

Without the info from people having the problem we can only speculate.

The most likely cause in these small, inactive, embedded devices is getting enough bytes out of /dev/random. Those bytes are needed while generating per-session keys, meaning the connection will not complete (whole process will stall) until /dev/random fills back up.
That can take a long time on an embedded device under Linux without other events happening.

Now if any reader here running into this "slow to connect" problem would just post the output of ssh -vv what-ever, we could see where the connection process is stalling.

Without the info from people having the problem we can only speculate.

It was working fine for awhile, but now it's back to taking a long time to connect, if ever connecting, so I'll try that now that I have a working Linux distro available to me.

That is one cause of the delay, your OpenSSH is built against the FIPS validated OpenSSL which has to undergo its self testing at every startup of every instance even if OpenSSH never sets "FIPS_MODE=1" (check your environment strings).

Unless you are in an environment that demands the use of the FIPS validated OpenSSL library (such as a private or government agency) - try a copy of OpenSSH built against the non-validated OpenSSL.

That is the version string of a "locally built" OpenSSH, probably done by your security manager when they built the FIPS-enabled OpenSSH.Edit: My eye just caught your PS1 prompt - this is a copy of Fedora, a very security aware distribution. Well somebody has to deal with it, I guess we can tackle it in this thread.

Translation:
Set a address/name pair in /etc/hosts (as the other poster suggested)

Use public key authentication with an identity file on your client machine, the public key on the Kindle.

Find a copy of OpenSSH not built against the FIPS-140 validated OpenSSL and use that (if allowed within your organization).Edit: Under the Fedora distribution, this last may not be practical, but it is still valid, general advice.