--- Xavier <shiningxc@gmail.com> wrote:
Hi again,
(and sorry again for any split lines)
Okay, so I was fooling around with the --root
again, and after I realized from one of Xavier's
On Mon, Aug 20, 2007 at 10:38:26PM -0400, Mister Dobalina wrote: option posts
that pre/post install scriptlets won't be run at all until /bin/sh (from bash) is installed, I figured I should install the packages twice. This led to two issues. I have a bash script (attached) that basically does:
I'm missing some basic *nix knowledge here :) When I saw this problem, I added /bin/sh and /bin/bash to my empty chroot, but it still didn't work.
Just bash in an empty chroot won't run because of missing shared libraries -- an ldd of /bin/bash shows it needs some libraries from readline, ncurses, and glibc.
Now, I just made an installation of filesystem and all its dependencies, and it seemed to work. The filesystem scriptlet complained though because grep was missing, but at least it was run.
pkglist=( ... bunch o' base packages ... ) mkdir /tmp/pacman.test pacman -U --root /tmp/pacman.test ${pkglist[*]} pacman -U --root /tmp/pacman.test ${pkglist[*]}
The second install of coreutils causes:
error: cannot remove file '/tmp/pacman.test/usr/bin/sleep': Read-only file system error: failed to commit transaction (transaction aborted) error: failed to release transaction (could not commit transaction)
First Issue: CPU usage then goes to 100%, so I assume that pacman has gone into an infinite loop somewhere.
I think this is the same issue as described there (in the quoted mails) :
http://www.archlinux.org/pipermail/pacman-dev/2007-August/009084.html
ie, when a -U operation failed, pacman always looped when trying to unregister the databases. My fix has just recently been pushed to git.
Ok great, glad you already knew about it.
Second Issue: the real concern is the "Read-only file system" error, since /tmp is on a tmpfs and is definitely not read-only. My / partition is read-only though, and
# ls -l /tmp/pacman.test/usr/bin/sleep
lrwxrwxrwx 1 root root 10 2007-08-16 16:13 /tmp/pacman.test/usr/bin/sleep -> /bin/sleep
So pacman was following the absolute symlink *out* of the --root and trying to remove /bin/sleep from my main arch install ??
Hmm, the question I would rather ask is wtf is that symlink in the first place ? sleep isn't a symlink here, it's a regular file.
/usr/bin/sleep should be a symlink to /bin/sleep on your system. This is actually due to a bug report I filed when I first started using archlinux a few years ago. sleep was originally being installed in /usr/bin, but this made it inaccessible during parts of rc.sysinit/rc.shutdown for people who have /usr on a separate partition. I always add a sync; sleep 5 at the end of rc.shutdown, because my hard drive has a large cache, and archlinux runs so quickly that it was powering down my computer before the hard drive cache was finished being written out to disk, causing an fsck run on every boot. Anyways, Judd agreed that sleep should go into /bin, but put a symlink in /usr/bin for anybody that wasn't expecting sleep to move.
But even then, all other symlinks I've in the --root are correct, they don't point to somewhere outside it.
I guess it depends on whether the package maintainer made it a relative or absolute symlink?
$ ls -l foo/bin/sh lrwxrwxrwx 1 root root 4 mai 15 21:14 foo/bin/sh -> bash* $ ls -l foo/bin/sleep -rwxr-xr-x 1 root root 14380 aoû 16 22:13 foo/bin/sleep*
foo/bin/sh -> bash is a relative symlink, points to the same directory that the link itself is in. And foo/bin/sleep is indeed the actually binary as it is supposed to be installed. But you should really be trying # ls -l foo/usr/bin/sleep to see where it points. cheers, Jeremy Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail at http://mrd.mail.yahoo.com/try_beta?.intl=ca