Hi,
Several misc questions regarding grml-debootstrap...
- Does debootstrap download packages? If yes, where does it place downloaded packages?
- Since grml-debootstrap also install packages defined in /etc/debootstrap/packages into the chroot system, is it a good idea to bind mount /var/cache/apt/archives into the chroot system as well, so as to save the downloading and cleaning up?
- furthermore, I think over 99% people would have same apt/sources.list and apt/preferences in host and chroot system. If so, would it be a good idea for the same bind-mount option bind mount /etc/apt/sources.list & /etc/apt/preferences into the chroot system as well?
- is it a good idea to pre-seed package configurations with
dpkg --set-selections
thanks
* T o n g mlist4suntong@yahoo.com [20080902 23:09]:
Several misc questions regarding grml-debootstrap...
- Does debootstrap download packages? If yes, where does it place
downloaded packages?
Yes, they are located in /var/cache/apt/archives of the target system.
- Since grml-debootstrap also install packages defined in
/etc/debootstrap/packages into the chroot system, is it a good idea to bind mount /var/cache/apt/archives into the chroot system as well, so as to save the downloading and cleaning up?
I'm not sure about that, I've to check this out in reallife usage. :) But if you have any patches or implementation details it would be great if you could share them with us.
Added to our BTS to make sure it won't get lost:
http://bts.grml.org/grml/issue517
- furthermore, I think over 99% people would have same apt/sources.list and
apt/preferences in host and chroot system. If so, would it be a good idea for the same bind-mount option bind mount /etc/apt/sources.list & /etc/apt/preferences into the chroot system as well?
No, that's a bit dangerous as a default IMO (because there might be just too many problematic situations when booting a grml based on unstable and installing a Debian/stable system).
But you can use /etc/debootstrap/etc/.... to copy files from the source to the target system, check out the grml-debootstrap manpage.
Disclaimer: I'm aware of the fact that the documentation isn't yet ready and does not provide all the glory details. I'm working on that and highly appreciate any help.
- is it a good idea to pre-seed package configurations with
dpkg --set-selections
Of course you can do that, nice idea! I'll try to provide a feature like FAI does so you can configure and use it with mainline grml-debootstrap out-of-the-box. I added it to our BTS as well:
http://bts.grml.org/grml/issue518
regards, -mika-
On Tue, 02 Sep 2008 23:36:30 +0200, Michael Prokop wrote:
- Does debootstrap download packages? If yes, where does it place
downloaded packages?
Yes, they are located in /var/cache/apt/archives of the target system.
- Since grml-debootstrap also install packages defined in
/etc/debootstrap/packages into the chroot system, is it a good idea to bind mount /var/cache/apt/archives into the chroot system as well, so as to save the downloading and cleaning up?
I'm not sure about that, I've to check this out in reallife usage. :) But if you have any patches or implementation details it would be great if you could share them with us.
The bind mounting /var/cache/apt/archives is a trick that I've been using for years. Never cause me any problem. Since the bind mounting apt configure files are dangerous, thus adding a bind-mount option is not necessary, I think it is pretty safe to add the following line at the end of function mount_target() in grml-debootstrap
mount --bind /var/cache/apt/archives $MNTPOINT/var/cache/apt/archives
then umount it somewhere during clean up.
Each Debian system would have such /var/cache/apt/archives directory, so I think it is pretty safe to do so. This will allows us to do grml-debootstrap over and over without downloading Debian packages more then once.
In fact, this is what I do before calling grml-debootstrap:
mount -o bind /path/to/my/customized/debootstrap /etc/debootstrap
So that I can keep my own customized /etc/debootstrap without worrying it interfering with grml-debootstrap default settings, and the troubles when upgrading grml-debootstrap.
- furthermore, I think over 99% people would have same apt/sources.list
and apt/preferences in host and chroot system. If so, would it be a good idea for the same bind-mount option bind mount /etc/apt/sources.list & /etc/apt/preferences into the chroot system as well?
No, that's a bit dangerous as a default IMO (because there might be just too many problematic situations when booting a grml based on unstable and installing a Debian/stable system).
But you can use /etc/debootstrap/etc/.... to copy files from the source to the target system, check out the grml-debootstrap manpage.
Ah, good idea. Then please add '--dereference' whenever 'cp' files from host into chroot system. I want to symlink them into /etc/debootstrap/etc/ instead of copying them over.
Further, not for this release, please log to bts to add an option to remove packages. There are packages that I don't need, e.g., nano, tasksel, tasksel-data, gcc-4.2-base, etc. An option that allows us to remove would be nice.
Thanks,
T o n g wrote:
On Tue, 02 Sep 2008 23:36:30 +0200, Michael Prokop wrote:
The bind mounting /var/cache/apt/archives is a trick that I've been using for years. Never cause me any problem. Since the bind mounting apt configure files are dangerous, thus adding a bind-mount option is not necessary, I think it is pretty safe to add the following line at the end of function mount_target() in grml-debootstrap
mount --bind /var/cache/apt/archives $MNTPOINT/var/cache/apt/archives
then umount it somewhere during clean up.
Each Debian system would have such /var/cache/apt/archives directory, so I think it is pretty safe to do so. This will allows us to do grml-debootstrap over and over without downloading Debian packages more then once.
This is dangerous und not possibel as apt locks /var/cache/apt/archives/lock. Thus it would be impossibel to run 2 parallel grml-debootstraps or use apt-get in the host system.
Instead a hint to approx would be much better (maybe even automatic handling).
e.g apt-get install approx echo 'debian http://ftp.at.debian.org/debian' >>/etc/approx/approx.conf Restart approx
cu, michael
On Wed, 03 Sep 2008 00:44:52 +0200, Michael Gebetsroither wrote:
necessary, I think it is pretty safe to add the following line at the end of function mount_target() in grml-debootstrap
mount --bind /var/cache/apt/archives $MNTPOINT/var/cache/apt/archives
of course, need mkdir -p $MNTPOINT/var/cache/apt/archives beforehand.
then umount it somewhere during clean up.
Each Debian system would have such /var/cache/apt/archives directory, so I think it is pretty safe to do so. This will allows us to do grml-debootstrap over and over without downloading Debian packages more then once.
This is dangerous und not possibel as apt locks /var/cache/apt/archives/lock. Thus it would be impossibel to run 2 parallel grml-debootstraps or use apt-get in the host system.
Instead a hint to approx would be much better (maybe even automatic handling).
Yes, that does make sense.
However, I'm using grml-debootstrap to build a minimum system, thus I'm incline to install the extra approx into both host and chroot environment, just to eliminate a risk that is rather low. Furthermore, approx has a big overhead, I don't want to pull in OCaml just for it.
I will never need to run 2 parallel grml-debootstraps or use apt-get in the host system, so bind-mount is a more suitable solution for me, which does not bring in any other extra dependencies.
T o n g wrote:
On Wed, 03 Sep 2008 00:44:52 +0200, Michael Gebetsroither wrote:
necessary, I think it is pretty safe to add the following line at the end of function mount_target() in grml-debootstrap
mount --bind /var/cache/apt/archives $MNTPOINT/var/cache/apt/archives
of course, need mkdir -p $MNTPOINT/var/cache/apt/archives beforehand.
then umount it somewhere during clean up.
Each Debian system would have such /var/cache/apt/archives directory, so I think it is pretty safe to do so. This will allows us to do grml-debootstrap over and over without downloading Debian packages more then once.
This is dangerous und not possibel as apt locks /var/cache/apt/archives/lock. Thus it would be impossibel to run 2 parallel grml-debootstraps or use apt-get in the host system.
Instead a hint to approx would be much better (maybe even automatic handling).
Yes, that does make sense.
However, I'm using grml-debootstrap to build a minimum system, thus I'm incline to install the extra approx into both host and chroot environment, just to eliminate a risk that is rather low. Furthermore, approx has a big overhead, I don't want to pull in OCaml just for it.
You know that you do _not_ need approx in the chroot?
I will never need to run 2 parallel grml-debootstraps or use apt-get in the host system, so bind-mount is a more suitable solution for me, which does not bring in any other extra dependencies.
So you just propose to break everyone others setup (including the host system during the boostrap process)?
The mount --bind is a quick-hack which might be of interest for a one-way shot install in a live environment. A commandline option should be fine but it should _never_ be the default!
cu, michael
On Wed, 03 Sep 2008 05:20:02 +0200, Michael Gebetsroither wrote:
I'm using grml-debootstrap to build a minimum system. . .
You know that you do _not_ need approx in the chroot?
Oh, I didn't know. sorry for my ignorance for the hacky suggestion.
In fact, I had been looking into the package caching solutions, namely, apt-proxy, apt-cacher and approx, but haven't figure out which one is the easiest to install/config, and suit a home-linux system.
Is the following all it takes for approx to work?
apt-get install approx echo 'debian http://ftp.at.debian.org/debian' >>/etc/approx/approx.conf Restart approx
Are there any more configurations? Do I need to configure apt-get to use approx? Can anyone list all your tweaks, and post all your tweaked approx related configuration files please?
Thanks a lot.
T o n g wrote:
Is the following all it takes for approx to work?
apt-get install approx echo 'debian http://ftp.at.debian.org/debian' >>/etc/approx/approx.conf Restart approx
Are there any more configurations? Do I need to configure apt-get to use approx? Can anyone list all your tweaks, and post all your tweaked approx related configuration files please?
for approx itself, yes.
You need to make apt-get use your approx.
approx.conf: debian http://ftp.at.debian.org/debian grml http://deb.grml.org
sources.list (if approx runs on localhost) deb http://localhost:9999/debian sid main contrib non-free deb http://localhost:9999/grml grml-testing main
and on grml-debootstrap you would simply use --mirror http://127.0.0.1:9999/debian
cu, michael
On Wed, 03 Sep 2008 23:05:26 +0200, Michael Gebetsroither wrote:
approx? Can anyone list all your tweaks, and post all your tweaked approx related configuration files please?
for approx itself, yes.
You need to . . .
Thanks a lot!!! that really helps.
have a nice day.
On Tue, 02 Sep 2008 21:09:06 +0000, T o n g wrote:
Several misc questions regarding grml-debootstrap...
# kernel version which should be installed # do not forget to adjust according to architecture, for example # use 2.6-686 for i386 and 2.6-amd64 for amd64 # KERNEL='2.6-686'
I want to install the kernel that I'm using now:
$ uname -rm 2.6.23-grml i686
how do I specify KERNEL=? 2.6.23-grml-686?
- is it a good idea to pre-seed package configurations with
dpkg --set-selections
Oh, sorry, I meant to say 'debconf-set-selections' to pre-seed package configurations (debconf database).
Thanks
On Tue, 02 Sep 2008 21:09:06 +0000, T o n g wrote:
Several misc questions regarding grml-debootstrap...
About making sure that services do not start up when chroot into the new system. I know it is handled in install_policy_rcd() in chroot-script.
My question is, when will the services start? Right when we chroot into the sub system, or ...?
I thought those services are started right when we chroot into the sub system. If so, shouldn't we move install_policy_rcd() out of chroot- script and move it into grml-debootstrap before calling chroot-script?
thanks.
* T o n g mlist4suntong@yahoo.com [20081001 00:24]:
On Tue, 02 Sep 2008 21:09:06 +0000, T o n g wrote:
Several misc questions regarding grml-debootstrap...
About making sure that services do not start up when chroot into the new system. I know it is handled in install_policy_rcd() in chroot-script.
My question is, when will the services start? Right when we chroot into the sub system, or ...?
I thought those services are started right when we chroot into the sub system. If so, shouldn't we move install_policy_rcd() out of chroot- script and move it into grml-debootstrap before calling chroot-script?
Huh?! Services won't be started in the chroot at all. That's why we install our own /usr/sbin/policy-rc.d and remove it at the end.
So sorry, what do you mean? :)
regards, -mika-
On Wed, 01 Oct 2008 00:43:27 +0200, Michael Prokop wrote:
I thought those services are started right when we chroot into the sub system. . .
Huh?! Services won't be started in the chroot at all. That's why we install our own /usr/sbin/policy-rc.d and remove it at the end.
Ah, ok, I understand it now. the /usr/sbin/policy-rc.d is used to prevent aptitude from starting services when installing packages right? I saw a message in debian-mlist titled "Prevent aptitude from starting services", and got the impression that services are started right when we chroot into the sub system.
thanks for clarification.
* T o n g mlist4suntong@yahoo.com [20081001 01:17]:
On Wed, 01 Oct 2008 00:43:27 +0200, Michael Prokop wrote:
I thought those services are started right when we chroot into the sub system. . .
Huh?! Services won't be started in the chroot at all. That's why we install our own /usr/sbin/policy-rc.d and remove it at the end.
Ah, ok, I understand it now. the /usr/sbin/policy-rc.d is used to prevent aptitude from starting services when installing packages right? I saw a message in debian-mlist titled "Prevent aptitude from starting services", and got the impression that services are started right when we chroot into the sub system.
Yes. policy-rc.d can exit with different return codes depending on what you would like to get. This is great for example for preventing any services to start up in a chroot where you don't want it to - as we need it in grml-debootstrap. :)
When executing "chroot /path" you just change your NEWROOT, it's not an init system - so no need to hassle with services then. :)
BTW: We at grml provide this mechanism to the user ready-to-go:
% cat /etc/policy-rc.d.conf # Filename: /etc/policy-rc.d.conf # Purpose: configuration file for /usr/sbin/grml-policy-rc.d # Authors: grml-team (grml.org), (c) Michael Prokop mika@grml.org # Bug-Reports: see http://grml.org/bugs/ # License: This file is licensed under the GPL v2. # Latest change: Sam Jul 08 01:29:41 CEST 2006 [mika] ################################################################################
# Do you want to run invoke-rc.d? EXITSTATUS='0'
# 0 - action allowed # 1 - unknown action (therefore, undefined policy) # 100 - unknown initscript id # 101 - action forbidden by policy # 102 - subsystem error # 103 - syntax error # 104 - [reserved] # 105 - behaviour uncertain, policy undefined. # 106 - action not allowed. Use the returned fallback actions # (which are implied to be "allowed") instead.
# More information: # http://people.debian.org/~hmh/invokerc.d-policyrc.d-specification.txt
## END OF FILE #################################################################
Now when I have a big Debian update where several services should *NOT* be restarted I just set EXITSTATUS to 101 and package grml-policyrcd and policyrcd-script-zg2 do the rest for me. When the upgrade finishes I just restore it to the default again (EXITSTATUS='0') and the system behaves as "usual". Small but nifty feature. :)
thanks for clarification.
you're welcome.
regards, -mika-
On Tue, 02 Sep 2008 21:09:06 +0000, T o n g wrote:
Several misc questions regarding grml-debootstrap...
what will happen if I grml-debootstrap/debootstrap into a directory that has already been debootstrap'd. I.e., the "--target" is not an empty directory, but a fully setup chroot system?
I just tried it, but failed. I'm wondering why it fails. The output has two rounds of "I: Validating " each package, and "I: Extracting" each package. I.e., the same "I: Validating "/"I: Extracting" sequence happened twice. but failed at the end of the second round.
Any comment?
thanks
* T o n g mlist4suntong@yahoo.com [20081001 06:46]:
On Tue, 02 Sep 2008 21:09:06 +0000, T o n g wrote:
Several misc questions regarding grml-debootstrap...
what will happen if I grml-debootstrap/debootstrap into a directory that has already been debootstrap'd. I.e., the "--target" is not an empty directory, but a fully setup chroot system?
"It might fail" ;)
I just tried it, but failed. I'm wondering why it fails. The output has two rounds of "I: Validating " each package, and "I: Extracting" each package. I.e., the same "I: Validating "/"I: Extracting" sequence happened twice. but failed at the end of the second round.
Running debootstrap itself twice in a row seems to work just fine, I see "I: Base system installed successfully." both times at the end of the run. So it might be a limitation of grml-debootstrap (I'm usually just installing on plain devices). Care to investigate?
regards, -mika-
participants (3)
-
Michael Gebetsroither -
Michael Prokop -
T o n g