Hi,
this is actually an FAQ. That's why I post my reply to the mailing list.
On Wed, Aug 01, 2001 at 10:40:21PM +1000, Anthony Green wrote:
> Hi Guido,
>
> I am seeing the following error when trying to install the bash RPM package
> for freemint bash-2.03-4.m68kmint.rpm
>
> # rpm -ivh --force --nodeps /bin/bash-2.03-4.m68kmint.rpm
> bash ###################unpacking of archive failed on file /bin/bash: cpio: link failed - link across devices
>
> Do you know what this means and how I may be able to fix it?
Not really, I can only guess, but it looks familiar to me.
>
> I have tried many things, --nodeps was Frank Naumann's recommendation and --force that
> of a unix guru at work.
No, that won't work. The options --force or --nodeps are only useful if
you feel the need to override the dependency checking of rpm. But you
have no problems with dependencies here. There is - as the error message
suggests - a problem with a hard link where the file "/bin/bash" is
involved.
>
> I have /bin and /usr/bin in my path, /etc is define as a link. Frank suggested that
> this should all work if I use your rpm for bash. RPM sucessfully installed the
> less package, but I get this error every time. The shell I am using is a version of
> bash for mint off a CD-ROM of Atari software.
The problem is that /bin/bash and /bin/sh are hard links, i. e. they are
the same file. And unfortunately with hard links you may run into some
serious shortcomings/bugs of MiNT. Problems like yours with bash usually
occur because of the various top-level symlinks like
u:\bin -> g:\bin
u:\usr -> h:\usr
...
There are so many different combinations out there that it is impossible
to test them all. Another problem could be that /bin/sh (or /bin/bash) is
already a symbolic link to some other shell on your system. When rpm
tries to create the hard link bash -> sh, I'm not sure whether symbolic
links are followed or not ... a mess!
The easy-going workaround for stubborn packages is: Convert the package
into a .tgz file (for example using alien(1) or rpm2cpio(1)) and install
the files by hand from the resulting tarball. Drawback: Your rpm database
will not notice that the package is installed. If this is an issue for
you, then re-install the package but this time with the rpm option
--justdb:
rpm -ivh --justdb bash-2.04-5.m68kmint.rpm
The option --justdb will prevent rpm from actually installing anything but
it will update the database as if you had really installed the package
(what you have earlier done manually). I would try to re-install bash
without --justdb first; it is possible that your problems are already
fixed at this point of time and you can now go ahead the regular way. If
it doesn't work, then you can try it with --justdb.
Another drawback are the pre/post (un)install scripts that get executed
when you install/upgrade/uninstall a package. You should inquire the
package for such scripts with
rpm -qp --scripts bash-2.04-5.m68kmint.rpm
This will print all scripts on stdout. You have to figure out what is
happening and try to do that manually. In the case of bash you will for
instance see that /bin/bash and /bin/sh will be written to your
/etc/shells.
That was the easy way. The hard way is to make your directory structure
rpm-friendly. An rpm-friendly directory structure has all top-level
directories on _one_ partition (or drive if you prefer that). That means,
you should create something like this from your mint.cnf:
sln u:\bin g:\bin
sln u:\etc g:\etc
sln u:\home g:\home
sln u:\lib g:\lib
sln u:\opt g:\opt
sln u:\root g:\root
sln u:\sbin g:\sbin
sln u:\tmp g:\tmp
sln u:\usr g:\usr
sln u:\var g:\var
Of course all these directories on g: should exist.
Assume now that you want the top-level directories /home on drive h:, /tmp
on drive i:, /usr on drive j:, and /var on drive k:. You should still
leave them on drive g: but do the necessary soft-links by hand (and keep
them persistent):
rmdir /g/home /g/tmp /g/usr /g/var
ln -s /h/home /g/home
ln -s /i/tmp /g/tmp
ln -s /j/usr /g/usr
ln -s /k/var /g/var
All this boils down to:
1) Select one of your MiNT partitions to be your root partition.
2) All top-level directories (i. e. everything that appears in
/ on real Unix) must exists either as a directory or as a
soft link on that partition.
3) Symlink top-level directories that should not reside on your
root partition from your root partition to the actual location,
_not_ from your unified filesystem (virtual drive u:) to the
actual location.
Or even shorter:
All symbolic links created from mint.cnf _must_ point to the
same device (partition/drive)!
Such a setup comes closest to the situation on a real Unix, and therefore
comes closest to what rpm expects to exist. (It would be better resp.
cleaner if the kernel supported such a setup by a mint.cnf directive like
"ROOT=g" which would cause g to be the root partition, and all paths on
g: would automatically exist on u: too).
Why this setup? A simple example: In your mint.cnf you have
sln u:\usr g:\usr
sln u:\lib h:\lib
If you do "ls -l /" you will see something like
... usr -> /g/usr
... lib -> /h/lib
Now take an rpm that installs the file "/usr/lib/libfoo.a" but wants to
make it available as "/lib/libfoo.a", too. The rpm could contain
something like
ln -s /usr/lib/libfoo.a -> ../../lib/libfoo.a
This symbolic link would resolve to "/g/lib/libfoo.a" on that MiNT system
and without special precautions would point to lala land. You can only
circumvent this if you guarantee that "/g/lib" also exists and is
equivalent to "/lib", hence my suggested directory structure.
A little problem remains:
ln -s /usr/lib/libfoo.a -> ../../../../../../../../../lib/libfoo.a
No problem on a regular Unix box because /.. is always hard-linked to /.,
and no matter how many ".." you put into the target paths you can never go
any further than "/". On MiNT this may or may not work, depending on your
layout. Anyway, this should not really be a problem (and besides - as far
as I can see it without a MiNT box around - should even work with my
suggested setup).
> I do have the X11 Server application working on my Falcon and I can find my
> applications from the shell by typing the name.
Then you need to type the full name:
/usr/X11R6/bin/xeyes -bg black -fg red
Once you are fed up typing these long paths you may consider to add your
X11 directory to your $PATH
echo 'export PATH=$PATH:/usr/X11R6/bin' >>~/.bashrc
If that doesn't help, ask Ralph. The message "No such file or
directory" could actually origin not from the shell but from some other
part of the system that tries to automatically fire up your X server and
does not find it. I can't try that out here.
> What exactly does each # represent??
Nothing, it is an ASCII progress bar. Each hash/pound sign represents a
certain percentage of the installation progress.
Ciao
Guido
Attachment:
pgpgChjqj993y.pgp
Description: PGP signature