r00t2/bdisk
1
0
Fork 0
Code Issues Pull Requests Projects Releases Activity

i cannot believe i just wiped out an entire night's worth of work.

Browse Source
This commit is contained in:
brent s.
2018-05-20 10:14:48 -04:00
parent b2498ba98d
commit f4f131890d
55 changed files with 2371 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

83
docs/manual/faq/ALTERNATIVES.adoc Normal file
View File

@@ -0,0 +1,83 @@
== I don't like BDisk. Are there any other alternatives?
First, I'm sorry to hear that BDisk doesn't suit your needs. If you want any features you think are missing or encounter any <<FURTHER.adoc#bug_reports_feature_requests, bugs>>, please report them!
But yes; there are plenty of alternatives! I encourage you to search for yourself, but I've tried to be as impartial as I can for the below.
NOTE: Only *currently maintained projects* are listed here.
=== https://wiki.archlinux.org/index.php/archboot[Archboot^]
Written in Bash
[frame="topbot",options="header,footer"]
|======================
|Pros|Cons
|Highly featureful|Arch-only live media
|Includes an assisted Arch install script|Inaccessible to non-Arch users
|Can create tarballs too|Not very customizable by default
|Supports hybrid ISOs|Infrequent stable releases
|Supports PXE-booting infrastructure|Requires a systemd build host
|Supports SecureBoot|Not a secure setup by default
|Supports GRUB2's "ISO-loopback" mode|Builds a much larger image
|Official Arch project|Some graphical bugs
||Much more disk space is necessary for the tool itself
||*Only* runs in RAM, so not ideal for RAM-constrained systems
||Based on/requires an Arch build host
||Requires an x86_64 build host
||Has a large amount of dependencies
||Manual intervention required for build process
||Minimal documentation
||
|======================
=== https://wiki.archlinux.org/index.php/archiso[Archiso^]
Written in Bash.
[frame="topbot",options="header,footer"]
|======================
|Pros|Cons
|Used to build the official Arch ISO|Requires an x86_64 build host
|Supports custom local on-disk repositories|Not very featureful as far as customization goes
|Supports arbitrary file placement in finished image|Requires an Arch build host
|Supports hybrid ISOs|Has odd quirks with package selection
|Supports Secureboot|Manual intervention required for build process
|Official Arch project|Does not start networking by default
|Can run in RAM or from media|Very minimal environment
||Arch-only live meda
||Documentation is lacking
||
|======================
=== Debian's https://wiki.debian.org/Simple-CDD[Simple-CDD^]
Written in Bash (some Python).
[frame="topbot",options="header,footer"]
|======================
|Pros|Cons
|Supports custom packages to be installed|Very limited -- no customization beyond package listing
|Lightweight; quick to set up|Takes a long time for preparation; requires a clone of many .deb packages first.
||Doesn't seem to work as according to https://wiki.debian.org/Simple-CDD/Howto[the documentation^]
||Documentation is sparse
||Full featureset unknown due to ISO not building on Debian Jessie (8.0)
||
|======================
=== Fedora's https://fedoraproject.org/wiki/Livemedia-creator-_How_to_create_and_use_a_Live_CD[Livemedia-creator^]
Written in Bash.
[frame="topbot",options="header,footer"]
|======================
|Pros|Cons
|Somewhat customizable|Requires manual initialization of chroot(s) via https://github.com/rpm-software-management/mock/wiki[mock^]
|Uses kickstart configurations|*Requires* a kickstart configuration in order to be useful
|Simple/easy to use|Full featureset unknown; documentation is sparse
||Limited configuration/customization
||
|======================
=== https://github.com/rhinstaller/livecd-tools[LiveCD Tools^]
Written in Python 2, some Bash.
[frame="topbot",options="header,footer"]
|======================
|Pros|Cons
|Can use kickstarts|*Requires* a kickstart configuration
|Simple/easy to use to use|Limited configuration/customization
|Automatically builds chroots|Full featureset unknown; documentation is sparse
||
|======================

3
docs/manual/faq/GETVERSION.adoc Normal file
View File

@@ -0,0 +1,3 @@
== How do I get the version/build of an ISO?
This can be found in a multitude of places. The full-size ISO file should have the version right in the filename. If you want more detailed information (or perhaps you renamed the file), you can mount the ISO as loopback in GNU/Linux, *BSD, or Mac OS X/macOS and check `/path/to/mounted/iso/VERSION_INFO.txt`. Lastly, within the runtime itself (especially handy if booting via iPXE), you can check `/root/VERSION_INFO.txt` to get information about the build of the currently running live environment.

5
docs/manual/faq/INDEX.adoc Normal file
View File

@@ -0,0 +1,5 @@
include::WHYARCH.adoc[]
include::LONGTIME.adoc[]
include::ISOBIG.adoc[]
include::GETVERSION.adoc[]
include::ALTERNATIVES.adoc[]

5
docs/manual/faq/ISOBIG.adoc Normal file
View File

@@ -0,0 +1,5 @@
== Why is the ISO so large?
This actually entirely depends on what <<changing_the_installed_software,packages you have chosen to install>> (and if you're building a <<code_multiarch_code,multiarch ISO>>). The default list is quite large.
If you build a minimal ISO (i.e. only the necessary components required for booting and nothing else, single-arch), the ISO is only about 570MB (but work is being done to make this even smaller).

70
docs/manual/faq/LONGTIME.adoc Normal file
View File

@@ -0,0 +1,70 @@
== Why does building take so long?
This typically occurs when you're building from within a LiveCD/LiveUSB situation, in a VM/container/etc., or on a headless server. If this is the case, you may run into what appears to be "stalling", especially while keys are generating for the chroots. Thankfully, there is an easy fix. You can install http://www.issihosts.com/haveged/[haveged^] and run it (this can be done safely while a build is executing). This will show an immediate and non-negligible improvement for the above contexts. If you have extra processing power to throw at the build process (or are using a dedicated build box) as well, I recommend enabling <<code_its_full_of_stars,`its_full_of_stars`>>. BDisk will then be more aggressive with its resource consumption.
=== Running a local mirror
Keep in mind also that the more packages you opt to install, the longer the build process will take. This process will also use quite a fair bit of bandwidth. If you plan on building regular images (e.g. nightly builds, etc.) or are undergoing some custom change testing, I recommend running a private repository mirror on-site. For Arch-based builds, this will not store AUR packages, as those will still be fetched and built (documentation on working around this is TODO) but setting up a local mirror is quite quick and easy. We'll of course use Arch as an example since that's the default guest environment (though I have a https://git.square-r00t.net/OpTools/tree/centos/repoclone[script^] for CentOS as well).
First, you'll need at least 90Gb of free disk space. Let's say our repository clone will be at `/srv/repo/arch/`.
You'll also need to find an Arch mirror, ideally one close to you that is up-to-date. The https://www.archlinux.org/mirrorlist/[mirrorlist generator^] and https://www.archlinux.org/mirrors/[mirror list^] will assist you here greatly.
NOTE: You'll need to find a mirror that supports _rsync_.
TIP: You can use ANY distro to run a repository mirror, as long as it has _rsync_ installed!
==== Set up the sync
I have https://git.square-r00t.net/OpTools/tree/arch/repoclone.py[written a script^] that does the heavy-lifting! https://git.square-r00t.net/OpTools/plain/arch/repoclone.py[Download it^] and mark it as executable (`chmod +x repoclone.py`). Make sure you read the --help option and edit `~/.config/optools/repoclone/arch.ini`.
Assuming you want to run the sync script every 6 hours, this is the cron entry you would use (`crontab -e`):
0 */6 * * * /path/to/repoclone.py
The first sync can take quite a while, but subsequent runs shouldn't take more than five minutes or so (depending on how many updates are available).
==== Configuring the local mirror
You'll need a way to serve this local mirror in a way pacman can understand. Luckily, it's fairly easy. I recommend using https://www.nginx.com/[nginx^] as it's available by default in many operating systems. You can of course use others such as https://www.lighttpd.net/[lighttpd^], https://httpd.apache.org/[apache/httpd^], etc. For the example configuration here, we're going to use an nginx configuration file.
```
server {
listen [::]:80;
access_log /var/log/nginx/repo.access.log main;
error_log /var/log/nginx/repo.error.log;
#error_log /var/log/nginx/repo.error.log debug;
autoindex on;
root /srv/repo/arch;
}
```
The configuration may vary according to your distribution's provided nginx default configuration, but you'll want this configuration to be served as the default (or set an appropriate `https://nginx.org/en/docs/http/server_names.html[server_name]` directive which you would then use in `<profile><build><paths><base>/etc/pacman.d/mirrorlist`).
==== Configuring BDisk
You'll then want to configure BDisk's chroots to use your local mirror first. However, if you want to use a LAN resource mirror, when doing so you run into an issue -- in the built image, install operations will take longer than they need to because the local mirror likely won't be available! This is a small issue as it's unexpected that you'll need to install software within the live environment, but I've run into cases where it was a necessity once or twice.
There is an https://devblog.square-r00t.net/articles/libvirt-spoof-domains-dns-records-redirect-to-another-ip[easy workaround^] if you're using libvirt to build -- you can simply tell your build VM to resolve to the IP address of the box that is running the mirror for the same FQDN that the "preferred" "real" mirror on the Internet and set that mirror at the top of `<profile><build><paths><base>/etc/pacman.d/mirrorlist`. However, that's not always feasible- most notably if you're building on a physical box and it's the same host as the repository clone. In that case you can set the specific local resolution -- e.g. `http://127.0.0.1/` -- at the top of `<profile><build><paths><base>/etc/pacman.d/mirrorlist` and then set a mirrorlist WITHOUT that entry in `<profile><build><paths><overlay>/etc/pacman.d/mirrorlist`. For more information on using these type of overrides, see <<advanced_customization>>.
If you're using the libvirt workaround, remember to configure nginx (or whatever you're using) with a virtual host and location block that matches the "real", upstream mirror. In our example below, we use *http://arch.mirror.square-r00t.net* as the mirror.
```
server {
listen [::]:80;
access_log /var/log/nginx/repo.access.log main;
error_log /var/log/nginx/repo.error.log;
#error_log /var/log/nginx/repo.error.log debug;
server_name arch.mirror.square-r00t.net;
autoindex on;
root /srv/repo/arch;
location /archlinux {
autoindex on;
rewrite ^/archlinux(/.*)$ /$1;
}
}
```

5
docs/manual/faq/WHYARCH.adoc Normal file
View File

@@ -0,0 +1,5 @@
== Why Arch Linux as the Recommended Guest?
Because it's a very easy-to-use, simple, https://wiki.archlinux.org/[well-documented^] distro. It's no-frills and incredibly flexible/customizable, and can be made rather slim (and is out of the box, in fact). It's also very friendly to run as a chroot inside any other distro or as a chroot host to any other distro.
Plus they release monthly tarball snapshots that are fairly small and create quick bootstrap environments.