Subject: [alpine-user] Lack of a minimal documentation on Alpine's overall architecture, run-from-RAM feature, mkinitfs, modloop etc.

From: Timur Fayzrakhmanov <[email-masked]>
Date: Wed, 28 Mar 2018 23:38:54 +0300

Dear all,

I think Alpine Linux is the most technical-grounded (and clean)
distribution I've ever seen among wide-spread ones. That is why I want to
thank you all who participate in such a "hardened" project. However, it
comes to price if you're newbie you're probably doomed to search solutions
by your own and unlikely get help or much of documentation. My last point -
before I decided to write this messege - was no response for week after I
posted two questions on Alpine's forum and SuperUser. The one that is still
good to get attention:
https://forum.alpinelinux.org/forum/installation/what-%E2%80%9Cmodloop%E2%80%9D-option-alpine.
Yep, sometimes Arch's wiki helps and it's a good resource if you didn't
find Alpine's corresponding one. But in many cases it isn't enough.

So let's get more constructive. I faced with a situation when there is so
little information for one of the most thoroughly designed Alpine's feature
(besides security) and the least covered topic on how it's actually
organized/designed. It's run-from-RAM feature. Another example can be
mkinitramfs tool. It is quite complex script with almost 1k LOC of logic
for init. However, there is no even one line of readme (there same goes for
source code) where one can understand what's going on inside, if you are
not Natanael Copa however. He works like a machine. Certainly, God bless
him. But getting back - I found a lot of such repos. I think the things
getting like "one knows everything and everyone else do it on trust" :).
It's ok but understand things on conceptual level in our activity is
"highly recommended" :).

There are other things in question:
- Alpine overall architecture;
- What is modloop!?
  (certainly set of kernel modules but what the design decision behind is
unknown)
- Booting process description;
  (from Alpine originator's perspective)
- How kernel, initramfs (its init script) and init (OpenRC) are related to
each other;
  (you can doubt it but Alpine tends to adopt things in its own way and I
think it should be covered somehow)

Please, don't get me wrong. I'm not trying to criticise someone or
complain. I'm really inspired by Alpine and spend a lot of time to dig in.
I just want to make an attention to the quite fundamental things
(especially) from newbie perspective.

Live long and prosper,
Timur Fayzrakhmanov.

---

From: Cág <[email-masked]>
Date: Mon, 9 Apr 2018 13:53:39 +0000

Hi,

Sorry for the late reply.

> - Alpine overall architecture;

What do you mean by that? The base of Alpine is BusyBox/musl/apk.

> - What is modloop!?

Modloop is a kernel module for loop devices.

> - How kernel, initramfs (its init script) and init (OpenRC) are
> related to each other;

OpenRC is not init on Alpine, it's a service manager. /sbin/init is
a link to /bin/busybox. The openrc package also provides init scripts.
/etc/inittab describes the boot process, which is:

/sbin/init -> /sbin/openrc sysinit -> /sbin/openrc boot ->
	/sbin/openrc default -> ttys are spawned

initramfs is caught by the kernel and the bootloader, only after it is
started /sbin/init is being executed. Read more about the Linux booting
process and initramfs on Wikipedia or elsewhere, I myself never use it.

> (you can doubt it but Alpine tends to adopt things in its own way and
> I think it should be covered somehow)

It doesn't really. 

--
caóc

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Joshua Haase <[email-masked]>
Date: Mon, 09 Apr 2018 22:22:26 -0500

Cág (2018-04-09 13:53):

| Hi,
|
| Sorry for the late reply.
|
|> - What is modloop!?
|
| Modloop is a kernel module for loop devices.

>From a newbie perspective, you can think of it as a way to mount files
as if they were disks.

---

---

From: Steffen Nurpmeso <[email-masked]>
Date: Tue, 10 Apr 2018 13:56:40 +0200

Joshua Haase <[email-masked]> wrote:
 |Cág (2018-04-09 13:53):
 || Sorry for the late reply.
 ||
 ||> - What is modloop!?
 ||
 || Modloop is a kernel module for loop devices.
 |
 |>From a newbie perspective, you can think of it as a way to mount files
 |as if they were disks.

There was or is TinyCoreLinux, where packages are not unpacked and
installed, but kept as balls and the simply mounted in via modloop.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

---

---

From: Joshua Haase <[email-masked]>
Date: Tue, 10 Apr 2018 12:58:13 -0500

Steffen Nurpmeso (2018-04-10 13:56):

| Joshua Haase <[email-masked]> wrote:
|
|  |From a newbie perspective, you can think of it as a way to mount files
|  |as if they were disks.
|
| There was or is TinyCoreLinux, where packages are not unpacked and
| installed, but kept as balls and the simply mounted in via modloop.

I think that is done using unionfs over loop devices (at least i think
that's how slax did it). But the analogy still applies.

Hope this clarifies some things for Timur.

---

---

From: Steffen Nurpmeso <[email-masked]>
Date: Tue, 10 Apr 2018 20:45:18 +0200

Joshua Haase <[email-masked]> wrote:
 |Steffen Nurpmeso (2018-04-10 13:56):
 || Joshua Haase <[email-masked]> wrote:
 ||
 |||From a newbie perspective, you can think of it as a way to mount files
 |||as if they were disks.
 ||
 || There was or is TinyCoreLinux, where packages are not unpacked and
 || installed, but kept as balls and the simply mounted in via modloop.
 |
 |I think that is done using unionfs over loop devices (at least i think
 |that's how slax did it). But the analogy still applies.

I have forgotten how it worked, actually.  Linux has bind mounts
(now, and is very, very cool in that respect), FreeBSD has nullfs.
Do not ask me no questions...

..But, just in case you refer to some ML thread long ago and
somewhere else: i continue not to like unionfs if that prevents me
from using getdents*(2) because mess in userspace is used to
overcome some filesystem shortcomings.  ..That cannot be
represented as secondary "whiteout" files.  I want getdents.  What
is wrong with getdents?  I would also take the same bytestream via
open(2)..read(2), but that is more and more forbidden, everywhere.
Last that i have seen who changed it was OpenBSD.

 |Hope this clarifies some things for Timur.

Yeah, i realized he will not be able to get anything from that,
but then the message was away for some time already.

--steffen
|

---