Creating a Slackware chroot: installpkg --root option and doinst.sh
I install a modest amount of packages using SlackBuilds.org (125 on one machine, 133 on another currently). I run multilib on both, which can cause problems with compiling a few packages. Due to this, and also because it just "feels" right, I want to compile my SlackBuilds on a clean system.
There a few different ways to go about this, see [1] for example. I decided that creating a chroot would be best for me, using [2], [3], and [4] as my starting point. It basically boils down to doing Code:
installpkg --root /chrootarget a/*.txz ap/*.txz d/*.txz k/*.txz l/*.txz n/*.txz x/*.txz xap/*.txz Code:
### MPlayer-1.2_20160125-x86_64-3 doinst.sh (snippet)### Code:
### xterm-325-x86_64-1 doinst.sh ### Yes. It turns out that all but glibc-solibs of the absolutely essential packages needed for a functioning chroot can "safely" be installed using the --root option of installpkg. The few remaining needed libraries I manually copy from the host system to the new chroot environment, and then I can simply call installpkg from within the chroot. Here it is, my script that installs Slackware into a chroot without affecting the host system: Code:
#!/bin/bash Code:
init: /dev/initctl: No such file or directory How did I come up with these two "special" lists of packages? BASE_PKGS are all the packages needed to be able to call installpkg. Basically bash and it's dependencies, and the various utilites (tar, xz, rev) and their dependencies. The second list (glibc-solibs, texinfo, etc.) provides the various binaries called by some of the various doinst.sh scripts. You can see I've named this particular chroot installation 14.2-release. My plan is to, using overlayfs, layer 14.2-patched on top of this, and then add a 3rd temporary layer for all my SBo builds. That part I haven't gotten to yet. [1] http://www.linuxquestions.org/questi...ent-4175585169 [2] http://docs.slackware.com/howtos:gen...ackware_chroot [3] http://www.linuxquestions.org/questi...8/#post4093831 [4] http://www.linuxquestions.org/questi...9/#post5579695 [5] http://alt.os.linux.slackware.narkiv...nstallpkg-12-1 --- Additional material --- Before I realized I could simply get the doinst.sh scripts from /var/log/scripts I created this script to extract them: Code:
#!/bin/sh Code:
#!/bin/sh |
Quote:
This is highly important and highly significant, installpkg and upgradepkg have already done a cd to the specified root directory, so it is using the host system's program (/usr/bin/update-desktop-database) to update the database in the alternative root (usr/share/applications). This means that you can (usually) update an x86_64 root from an i586 host, and even use an Intel installation to upgrade packages on a mounted Slackware ARM filesystem. You should not confuse --root and chroot. They are not the same thing, you've forgotten about the much more important use case of updating another mounted filesystem. Basically, it all works better how it is right now. Sorry. |
Quote:
Code:
# There's no need to chroot and do this during initial And here is blinken for another example: Code:
if [ -x /usr/bin/update-desktop-database ]; then |
Clearly pkgtools excels at installing new systems and keeping systems up-to-date. It has decades of experience. But my point is are there any gotchas when installing into a chroot? I believe yes there are, and installing from within the chroot avoids potential problems.
|
Quote:
Quote:
|
i talk arround this in other post ..but no lucky.
installpkg using root parameter not working ever. glibc , install this in separate dir and check how create files out of folders. see my thread ...but no solution. http://www.linuxquestions.org/questi...on-4175587290/ |
Hi,
You might try to use installer's initrd to do the whole thing. This way, you would have an environment as if you were installing from DVD. Have a look at the necessary steps I described here for remote server. Instead of installing on remote server as the text explains, you'll be installing on local machine. Also you don't have to partition the drive and instead of setup, you can probably use installpkg only. What I mean, is that by using installer's initrd and chroot'ing into it, you should have the "proper" installation environment and all the necessary tools. -- Best regards, Andrzej Telszewski |
Quote:
Code:
( cd usr/share/zoneinfo ; rm -rf localtime ) Code:
# ls -l /root/build/14.2-release/usr/share/zoneinfo/localtime But, you do correctly point out that a doinst.sh can potentially modify the host system - nothing in pkgtools prevents that from happening. It is up to each individual doinst.sh to only modify the system relative to $ROOT. That brings up a good question: what are the goals and non-goals of pkgtools? Perhaps using pkgtools to manage a chroot Slackware install is a non-goal. To me that's perfectly acceptable, I've just never seen it stated anywhere. However, my goal is to create a full Slackware install for a chroot, using pkgtools. Based on what I've read elsewhere (as documented in my first post) I thought it would be as simple as "installpkg --root $MY_NEW_ROOT */*.t?z". But I now have a new conclusion, as documented in my install-release.sh. Install a minimum number of packages using installpkg --root, manually examining the doinst.sh scripts to make sure they don't touch the host system, and then install everything else while inside the chroot. In this way I don't have to worry about what the doinst.sh scripts do, because they are called from within a chroot. Andrzej, that is a good suggestion! I will have to look into it. That should also guarantee that the host system isn't inadvertently modified by a doinst.sh script. |
sorry for my bad english.
basically i say same as you , if someone, use --root parameter , doinst.sh can do something strange in some cases. when i put --root=MYFOLDER y spect ,doinst.sh go to work inside $MYFOLDER , same as when run in to / but sometimes "post-install",actions work out or bad , in $MYFOLDER. if you test to install glibc , in a custom folder. ... you can see , symlinks OUT OF $MYFOLDER/etc ..point to good dir, but symlinks , out of spected dir. spected $MYFOLDER/etc/symlinks reality $MYFOLDER/symlinks SEE , symlinks not in /etc ... :=) |
Yes, the glibc doinst.sh does not play nicely in this case. It thinks that you are upgrading your running system. It tries to determine whether it is being run from the install initrd or a running system. As written, the test thinks that you are upgrading because /sbin/ldconfig exists. On my system, I have reworked this test so that it does the right thing when installing using ROOT -it creates the links manually instead of running ldconfig.
|
All times are GMT -5. The time now is 02:59 AM. |