aboutsummaryrefslogtreecommitdiff
path: root/content
diff options
context:
space:
mode:
authorGabriel Arakaki Giovanini <mail@gabrielgio.me>2023-08-09 17:23:53 +0200
committerGabriel Arakaki Giovanini <mail@gabrielgio.me>2023-08-09 17:24:48 +0200
commit06161b09d215e75d62a7b41b85fbf0dd14fb87ce (patch)
treed4185031eb5f59e9d8ebfa6dcb2452d64e71ce32 /content
parenta1df6513ecf317d937f7b5d76f73e2f4e3edd542 (diff)
downloadgabrielgio.me-06161b09d215e75d62a7b41b85fbf0dd14fb87ce.tar.gz
gabrielgio.me-06161b09d215e75d62a7b41b85fbf0dd14fb87ce.tar.bz2
gabrielgio.me-06161b09d215e75d62a7b41b85fbf0dd14fb87ce.zip
ref: Rephrase some ... phrases
Diffstat (limited to 'content')
-rw-r--r--content/posts/2023-04-30-using-data-mode-alpine.md93
1 files changed, 47 insertions, 46 deletions
diff --git a/content/posts/2023-04-30-using-data-mode-alpine.md b/content/posts/2023-04-30-using-data-mode-alpine.md
index d0e7623..f8465ed 100644
--- a/content/posts/2023-04-30-using-data-mode-alpine.md
+++ b/content/posts/2023-04-30-using-data-mode-alpine.md
@@ -6,23 +6,23 @@ tags: ['alpine', 'linux']
# Local testing
-To facilitate iteration and testing of this setup, we can use `qemu` and for the
-whole setup we will be using two disks: one for mounting the /var folder and
-another for storing lbu files (more on that later). To create the two images,
-follow these steps:
+To make testing easier, we can use `qemu`, which will allow us to test the
+configuration before going for the real machine. For this setup we will be
+using two disks: one for mounting the /var folder and another for storing lbu
+files (more on that later). To create the two images with `qemu` run:
```bash
qemu-img create -f qcow2 var.cow2 10G
qemu-img create -f qcow2 media.cow2 5G
```
-Those images have arbitrary sizes and probably won't even required that much for
-this setup so feel free to choose another size.
+Those images have arbitrary sizes and probably we won't even required that much
+for this setup so feel free to choose pick whatever size you want.
-Once you have created the images go to alpine download page[^1] and grab the
+Once we have created the images, go to alpine download page[^1] and grab the
latest virtual image.
-We all of that we can now start the virtual machine
+We all of that we can now start the virtual machine, run:
```bash
qemu-system-x86_64 \
@@ -36,20 +36,21 @@ qemu-system-x86_64 \
```
For more info about what are those parameters head to `qemu` documentation[^2].
-Just pay attention to the `-boot d` option which will force cdrom to boot first
-(more on that later as well).
+Just make sure to add `-boot d` option which will force cdrom to boot first
+(more on that later).
# Setting up environment
Before we can run `setup-alpine` we need to mount a persistent media folder so
-it can be picked up by the script and used to store the `lbu` files. To do so we
-need to install some extra package that are not available in the live ISO.
+it can be used by `lbu` to store backup files. To do so we need to install some
+extra package that are not available in the live ISO.
-Run `setup-interfaces` to configure interfaces. The default values will do.
-After that start the networking service `rc-service networking start`. Now we
-have internet we can setup a repository. You could edit `/etc/apk/repositories`
-directly but there is handy command for that already `setup-apkrepos`. Run it
-and pick any option you see fit. I'd go for `f` but `1` also works.
+First we need to connect to internet. Run `setup-interfaces` to configure
+interfaces, default values will do. After that start the networking service
+`rc-service networking start`. Now we should have internet. After that we need
+to setup a repository. You could edit `/etc/apk/repositories` directly but
+there is handy command that does that already `setup-apkrepos`. Run it and pick
+any option you see fit. I'd go for `f` but `1` also works.
Now we can install some packages required for the remaining of the setup:
@@ -81,49 +82,50 @@ mkdir /media/vdb
mount -t ext4 /dev/vdb /media/vdb
```
-To confirm if device is mounted you can run `df -h /media/vdb`, it shows the
-size and which device is mounted on that folder.
+To confirm if device is mounted you can run `df -h /media/vdb`, and it should
+show the size and which device is mounted on that folder.
# Setting up alpine on data mode
-Now we can run `setup-alpine`. Choose whatever options fits your need up to the
-point where it asks to choose the device. It may repeat some of the step we
-already did but it is be fine.
+Now we can run `setup-alpine`. Choose whatever options fits your need until up
+to the point where it asks to choose a device.
-When it asks to choose a disks to use enter the name of disk, which, in this
-particularly setup, is `vda`. Then it will ask to choose how you would like to
-run alpine[^3], pick `data`.
+When it asks to choose a disks to use enter the name of the data disk, which,
+in this particularly setup, is `vda`. Then it will ask to choose how you would
+like to run alpine[^3], pick `data`.
-Now it will prompt to choose which media device we want to use for storing the
+Now it will prompt to choose which media device we want to use for storing
`lbu` files. By default it should the media folder we mounted in the previous
-step, if not just enter `vdb`. Select place for cache. Default is fine.
+step, if not just enter `vdb`. Then select place for cache, default is fine.
-The cache folder is used to store the apk files we come to add. Since it does
-not have internet access when booting it needs to store those extra package in
-folder so later it can be restored.
+The cache folder is also used to store the apk files we come to add. Since it
+does not have internet access when booting it needs to store those extra
+package in folder so later it can be restored.
**Warning**, do not reboot now. We need to use `lbu` to make a backup of all
-changes we did, otherwise everything will be lost. Take a careful read of the
-`lbu` documentation[^4], it will provide the necessary information to understand
-how `lbu` works.
+changes we did, otherwise everything will be lost on reboot. Take a careful
+read on the `lbu` documentation[^4], it will provide the necessary information
+to understand how `lbu` works.
Run `lbu commit` to backup it. You can check the `apkvol` file stored in the
-`/media/vdb/`. Now you changes as saved and you are good to reboot.
+`/media/vdb/`. Now that we have saved our changes, we are good to reboot.
-The live ISO will look for `apkvol` files and try to restore it. That is why it
-is required the ISO to be the first to boot. There is no boot info store
-anywhere else since the one device is used to store `lbu` and the other one is
-mount on `/var` so we use live ISO to boot and restore the state.
+The `initramfs` of the live ISO will look for `apkvol` files and try to restore
+it and that is why cdroom is required to be the first thing to boot.
+
+We can also notice that there is no boot info stored anywhere else. One device is
+used to store the `lbu` files and the other one is used ,later after boot, to
+mount `/var`, so the live iso is required.
You can check here[^5] how that is possible and here [^6] how we can expand that
idea and netboot using the apkvol to boot any machine to specific state.
# Making changes
-After rebooting your system, you can now log into your fresh installation. You
+After rebooting your system, you can log into your fresh installation. You
can then install a new package, such as vim, using the command `apk add vim`.
However, if you reboot the system again, the vim package will be lost and you
-will need to reinstall it.
+will need to reinstall it again after boot.
If you run `lbu status` will show what was changed and in this case
`/etc/apk/world`. The world file store all the package you have installed and
@@ -135,12 +137,11 @@ package and its dependencies.
# Why /var?
-The /var folder is a directory in Linux that is used to store variable data
-files as the contents of this folder can change by the OS. This folder contains
-files that are not critical to the basic operation of the system, but are
-instead used for tasks such as logging, spooling, and caching. For example
-postgresql store all its data on the var folder allowing us to use a database on
-data mode and still have its data persistent between boots.
+The `/var` folder contains files that are not critical to the basic operation of the
+system, but are instead used for tasks such as logging, spooling, and caching.
+For example postgresql store all its data on the var folder, and by mouting the
+var folder into a persistent file system it allows us to use a database os
+running on a tmpfs and still have its data persistent between boots.
# In conclusion