I had a semi-functional build that was broken with a lot of stuff, and even though only 1/2 of the stuff needed was implemented, it increased in size by 50K.
Well, I am really relieved that Epoch's current state will suffice for you. I am cleaning up any obvious remaining bugs and I will be working to decrease memory usage a little. It'll be ready soon. :^)

The mechanism that an initrd uses to launch your REAL init on your REAL filesystem after the initrd is done doing it's thing. You can't just call it with exec(), because then it'll try to use the root (the /) that the initrd has, and fail. You need to ask the kernel to make the new filesystem your new root fs before you execute the new init.

The mechanism that an initrd uses to launch your REAL init on your REAL filesystem after the initrd is done doing it's thing. You can't just call it with exec(), because then it'll try to use the root (the /) that the initrd has, and fail. You need to ask the kernel to make the new filesystem your new root fs before you execute the new init.

you can have quite a bit more fun with pivot_root as well. like, you can pivot / to some other place during shutdown to unmount / itself. although a plain chroot would probably get the job done that pivot_root is trying to do._________________"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland

The mechanism that an initrd uses to launch your REAL init on your REAL filesystem after the initrd is done doing it's thing. You can't just call it with exec(), because then it'll try to use the root (the /) that the initrd has, and fail. You need to ask the kernel to make the new filesystem your new root fs before you execute the new init.

you can have quite a bit more fun with pivot_root as well. like, you can pivot / to some other place during shutdown to unmount / itself. although a plain chroot would probably get the job done that pivot_root is trying to do.

Yes chroot works but init must be made aware that the root changed otherwise it will spawn services with the wrong root. Basically, reading busybox source code, the real root (the first) cannot be changed, older linuxes used a different method but than a pivot_root syscall was introduced to simplify things a bit.
working in a chroot (I do it all the times) is a good method but you cannot count on init, unless there is a way to signal it the change of root. IIRC with init pivot_root can be called only during sysinit phase, probably for safety reasons a rootkit could take total control of your machine calling pivot_root._________________True ignorance is not the absence of knowledge, but the refusal to acquire it.
A posse ad esse non valet consequentia
Πάντα ῥεῖ

The mechanism that an initrd uses to launch your REAL init on your REAL filesystem after the initrd is done doing it's thing. You can't just call it with exec(), because then it'll try to use the root (the /) that the initrd has, and fail. You need to ask the kernel to make the new filesystem your new root fs before you execute the new init.

you can have quite a bit more fun with pivot_root as well. like, you can pivot / to some other place during shutdown to unmount / itself. although a plain chroot would probably get the job done that pivot_root is trying to do.

Yes chroot works but init must be made aware that the root changed otherwise it will spawn services with the wrong root. Basically, reading busybox source code, the real root (the first) cannot be changed, older linuxes used a different method but than a pivot_root syscall was introduced to simplify things a bit.
working in a chroot (I do it all the times) is a good method but you cannot count on init, unless there is a way to signal it the change of root. IIRC with init pivot_root can be called only during sysinit phase, probably for safety reasons a rootkit could take total control of your machine calling pivot_root.

uhm, actually, first: if you're using a custom init, then it could just handle that. and second: you could just exec init after chrooting form your initrd script and it would do precisely what you wanted it to. 'cause, you know, your initrd script is supposed to run as PID=1, and after an exec that PID=1 is replaced with the new one, so if you chrooted into your real root before then, then shit just works like you wanted it to, even on old kernels. because your init's namespace's root directory will then be in that real root directory.

... also, pivot_root will actually work just fine even way after booting. the thing is just that it only modifies the current process's namespace, not the one init is living in. which is why you can safely use it from an initrd script: it's running as PID=1 so it really counts as init. the one advantage of pivot_root is that the old root mountpoint doesn't get "lost", so you can get rid of it afterwards._________________"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland

1) If you delete the commands out of your $PATH, your shell scripts can't run
more commands, but you can't start using dynamically linked _new_ commands
until after you do the chroot because the path to the dynamic linker is wrong.
So there's a step that needs to be sort of atomic but can't be as a shell
script. (You can work around this with static linking or very carefully laid
out paths and sequencing, but it's brittle, ugly, and non-obvious.)

2) The "find | rm" bit will acually delete everything because the mount points
still show up (even if their contents don't), and rm -rf will then happily zap
that. So the first line is an oversimplification of what you need to do _not_
to descend into other filesystems and delete their contents.

The reason we do this is to free up memory, by the way. Since initramfs is a
ramfs, deleting its contents frees up the memory it uses. (We leave it with
one remaining dentry for the new mount point, but that's ok.)

Note that you cannot ever umount rootfs, for approximately the same reason you
can't kill PID 1. The kernel tracks mount points as a doubly linked list, and
the pointer to the start/end of that list always points to an entry that's
known to be there (rootfs), so it never has to worry about moving that pointer
and it never has to worry about the list being empty. (Back around 2.6.13
there _was_ a bug that let you umount rootfs, and the system locked hard the
instant you did so endlessly looping to find the end of the mount list and
never stopping. They fixed it.)

Oh, and the reason we mount --move _and_ do the chroot is due to the way "/"
works. Each process has two special symlinks, ".", and "/". Each of them
points to the dentry of a directory, and give you a location paths can start
from. (Historically ".." was also special, because you could enter a
directory via a symlink so backing out to the directory you came from doesn't
necessarily mean the one physically above where "." points to. These days I
think it's just handed off to the filesystem.)

Anyway, path resolution starts with "." or "/" (although the "./" at the start
of the path may be implicit), meaning it's relative to one of those two
directories. Your current directory, and your current root directory. The
chdir() syscall changes where "." points to, and the chroot() syscall changes
where "/" points to. (Again, both are per-process which is why chroot only
affects your current process and its child processes.)

Note that chroot() does _not_ change where "." points to, and back before they
put crazy security checks into the kernel your current directory could be
somewhere you could no longer access after the chroot. (The command line
chroot does a cd as well, the chroot _syscall_ is what I'm talking about.)

The reason mounting something new over / has no obvious effect is the same
reason mounting something over your current directory has no obvious effect:
the . and / links aren't recalculated after a mount, so they still point to
the same dentry they did before, even if that dentry is no longer accessible
by other means. Note that "cd ." is a NOP, and "chroot /" is a nop; both look
up the cached dentry and set it right back. They don't re-parse any paths,
because they're what all paths your process uses would be relative to.

That's why the careful sequencing above: we cd into the new mount point before
we do the mount --move. Moving the mount point would otherwise make it
totally inaccessible to is because cd-ing to the old path wouldn't give it to
us anymore, and cd "/" just gives us the cached dentry from when the process
was created (in this case the old initramfs one). But the "." symlink gives
us the dentry of the filesystem we just moved, so we can then "chroot ." to
copy that dentry to "/" and get the new filesystem. If we _didn't_ save that
dentry in "." we couldn't get it back after the mount --move.

(Yes, this is all screwy and I had to email questions to Linus Torvalds to get
it straight myself. I keep meaning to write up a "how mount actually works"
document someday...)

_________________True ignorance is not the absence of knowledge, but the refusal to acquire it.
A posse ad esse non valet consequentia
Πάντα ῥεῖ

I'm not sure what you're trying to argue here. I know how the pivot_root and chroot syscalls work, I've *used them* in *a custom init programme*. Rather successfully, too. The guy even says they're really only doing it to free up initrd memory - which may or may not be what you'd want to do. What he says has nothing to do with using the pivot_root syscall for other purposes - such as unmounting the proper root at shutdown. It's quite possible and a really short programme at that: https://github.com/jyujin/eINIT/blob/master/src/last-rites.c

So, what is the point you're trying to argue? That you need to use pivot_root for your purposes? OK, you wanna free RAM, that's cool. Depending on how your INIT is designed, however, it may actually be worthwhile keeping the initrd around - as a place for INIT to live in, provided it can handle chroots on its own for stuff it spawns. I'm kind of saddened to see nobody seems to have gone this road before, initrds always seem to contain just enough to run shell scripts instead of an actual, proper programme (which would be smaller and faster)._________________"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland

Actually I am arguing anything
I just found that explanation (from the source of busybox) interesting. And I am also not in a particular need for a custom init that can handle pivot_root. I am just curious.
And as the busybox guy explains the biggest problem is the dynamic loader it is hardcoded in /lib/, that is why most initrd contains a static busybox.
a custom gcc could also compile programs with a dynamic loader elsewhere, like LFS does

Actually my idea is to avoid the initrd, but atm I am still at odds with ADSL/ATM and bridge, it funny, no idea what I did wrong but right now all wlan and eth are in the same bridge, the eth connect each other, the wlan connect each other but I cannot connect a wlan to an eth ......
ebtables? iptables? bridge?

atm I'm just talking about init and pivot_roots _________________True ignorance is not the absence of knowledge, but the refusal to acquire it.
A posse ad esse non valet consequentia
Πάντα ῥεῖ

The dynamic linker isn't that big a problem, really. Just means you either have to add the dynamic linker to your initrd or you need to compile your binaries statically. No need to get funkeh with modding the compiler . And since this IS a thread ABOUT a custom INIT..._________________"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland

The dynamic linker isn't that big a problem, really. Just means you either have to add the dynamic linker to your initrd or you need to compile your binaries statically. No need to get funkeh with modding the compiler . And since this IS a thread ABOUT a custom INIT...

like dracut does.

the kernel just execve the init= from the boot command line or the first program found from a list. Recent kernels added an option:

Code:

<*> Kernel support for scripts starting with #!

to use a script as the the first init.
probably is the best option.
and reading Documentation/filesystems/ramfs-rootfs-initramfs.txt also give good hints:

Quote:

All 2.6 Linux kernels contain a gzipped "cpio" format archive, which is
extracted into rootfs when the kernel boots up. After extracting, the kernel
checks to see if rootfs contains a file "init", and if so it executes it as PID
1. If found, this init process is responsible for bringing the system the
rest of the way up, including locating and mounting the real root device (if
any). If rootfs does not contain an init program after the embedded cpio
archive is extracted into it, the kernel will fall through to the older code
to locate and mount a root partition, then exec some variant of /sbin/init
out of that.

Basically pivot_root only works with the old initrd code, using an initramfs (or passing a cpio.gz as a initrd) needs a different code._________________True ignorance is not the absence of knowledge, but the refusal to acquire it.
A posse ad esse non valet consequentia
Πάντα ῥεῖ

The dynamic linker isn't that big a problem, really. Just means you either have to add the dynamic linker to your initrd or you need to compile your binaries statically. No need to get funkeh with modding the compiler . And since this IS a thread ABOUT a custom INIT...

like dracut does.

the kernel just execve the init= from the boot command line or the first program found from a list. Recent kernels added an option:

Code:

<*> Kernel support for scripts starting with #!

to use a script as the the first init.
probably is the best option.
and reading Documentation/filesystems/ramfs-rootfs-initramfs.txt also give good hints:

Quote:

All 2.6 Linux kernels contain a gzipped "cpio" format archive, which is
extracted into rootfs when the kernel boots up. After extracting, the kernel
checks to see if rootfs contains a file "init", and if so it executes it as PID
1. If found, this init process is responsible for bringing the system the
rest of the way up, including locating and mounting the real root device (if
any). If rootfs does not contain an init program after the embedded cpio
archive is extracted into it, the kernel will fall through to the older code
to locate and mount a root partition, then exec some variant of /sbin/init
out of that.

Basically pivot_root only works with the old initrd code, using an initramfs (or passing a cpio.gz as a initrd) needs a different code.

uh, no, the kernel forks(), then execve()s. otherwise there would be no kernel.

and pivot_root still works fine in recent versions, just gotta know how to use it. stop spreading weird ideas about whether it works or not

i would consider the practice of using a script in an initrd quite horrid actually..._________________"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland

uh, no, the kernel forks(), then execve()s. otherwise there would be no kernel.

actually don't think the kernel forks, but I might be wrong. it actually kernel_execve() init.

mdeininger wrote:

and pivot_root still works fine in recent versions, just gotta know how to use it. stop spreading weird ideas about whether it works or not

It is not me, it is the kernel docs, write an email to linus and tell him to fix the kernel documentation

mdeininger wrote:

i would consider the practice of using a script in an initrd quite horrid actually...

seems diffused now, since several initrd requires that option to be set in the kernel.
BTW are you talking about an initrd or an initramfs or an initrd loaded into a initramfs?_________________True ignorance is not the absence of knowledge, but the refusal to acquire it.
A posse ad esse non valet consequentia
Πάντα ῥεῖ

Last edited by erm67 on Wed Jan 08, 2014 12:08 pm; edited 1 time in total

uh, no, the kernel forks(), then execve()s. otherwise there would be no kernel.

actually don't think the kernel forks, but I might be wrong. it actually kernel_execve() init.

well it creates a process and then makes that execve . i'm just pointing it out because there actually is a way to have the kernel exec() something, which replaces the kernel image with a new one: kexec.

erm67 wrote:

mdeininger wrote:

and pivot_root still works fine in recent versions, just gotta know how to use it. stop spreading weird ideas about whether it works or not

It is not me, it is the kernel docs, write an email to linus and tell him to fix the kernel documentation

the part you quoted there says nothing about that. it just describes how the kernel acquires an init binary to execute: it will first search the initrd/initramfs for an init binary, then if that fails it'll do the old-fashioned mount-root-yerself-and-exec-init.

pivot_root on the other hand is a syscall with a very specific function: it modifies the current namespace context by switching around two mount points. it has nothing to do with init, even though it is extremely useful in initrds/initramfs. It would not technically have been necessary but it does allow freeing up some memory. It is not bound to the init process in any way: any process with sufficient privileges can execute the syscall at any time during the course of the machine being up. I mean it: http://linux.die.net/man/2/pivot_root <-- that sucker doesn't even mention init other than to say that the typical use is for an initrd. It's not the required use. You CAN actually use this at any time you like.

erm67 wrote:

mdeininger wrote:

i would consider the practice of using a script in an initrd quite horrid actually...

seems diffused now, since several initrd requires that option to be set in the kernel.

yeah that's people doing weird stuff where they shouldn't. dragging in busybox just to run something that a 100 line C programme could do is idiotic at best. doubly so when you're writing for a space-constrained system like, i dunno, a router distribution or an old pda.

erm67 wrote:

BTW are you talking about an initrd or an initramfs or an initrd loaded into a initramfs?

there is no real functional distinction here when talking about the init part. the kernel sets things up so you have the contents of the initramfs set up to your liking - using an integrated cpio or using a provided external image. or, in a way, using an actual root filesystem - cept then its not an initramfs ofc, but that is of no consequence to the kernel or the init. the fun starts after that, once your PID 1 process is running. pivot_root also doesn't come into play any earlier than that. at that point, i.e. when PID 1 is up, the kernel couldn't care less about what the root filesystem of that process looks like. it's all in the hands of that process._________________"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland

uh, no, the kernel forks(), then execve()s. otherwise there would be no kernel.

actually don't think the kernel forks, but I might be wrong. it actually kernel_execve() init.

well it creates a process and then makes that execve . i'm just pointing it out because there actually is a way to have the kernel exec() something, which replaces the kernel image with a new one: kexec.

well the root kernel thread starts the init thread that ends with a call to kernel_execve(init), so basically init is running into a kernel thread. The init_thread also initializes forks allocating memory.
kexec is very nice when it works ........

mdeininger wrote:

erm67 wrote:

mdeininger wrote:

and pivot_root still works fine in recent versions, just gotta know how to use it. stop spreading weird ideas about whether it works or not

It is not me, it is the kernel docs, write an email to linus and tell him to fix the kernel documentation

the part you quoted there says nothing about that. it just describes how the kernel acquires an init binary to execute: it will first search the initrd/initramfs for an init binary, then if that fails it'll do the old-fashioned mount-root-yerself-and-exec-init.

pivot_root on the other hand is a syscall with a very specific function: it modifies the current namespace context by switching around two mount points. it has nothing to do with init, even though it is extremely useful in initrds/initramfs. It would not technically have been necessary but it does allow freeing up some memory. It is not bound to the init process in any way: any process with sufficient privileges can execute the syscall at any time during the course of the machine being up. I mean it: http://linux.die.net/man/2/pivot_root <-- that sucker doesn't even mention init other than to say that the typical use is for an initrd. It's not the required use. You CAN actually use this at any time you like.

erm67 wrote:

mdeininger wrote:

i would consider the practice of using a script in an initrd quite horrid actually...

seems diffused now, since several initrd requires that option to be set in the kernel.

yeah that's people doing weird stuff where they shouldn't. dragging in busybox just to run something that a 100 line C programme could do is idiotic at best. doubly so when you're writing for a space-constrained system like, i dunno, a router distribution or an old pda.

erm67 wrote:

BTW are you talking about an initrd or an initramfs or an initrd loaded into a initramfs?

there is no real functional distinction here when talking about the init part. the kernel sets things up so you have the contents of the initramfs set up to your liking - using an integrated cpio or using a provided external image. or, in a way, using an actual root filesystem - cept then its not an initramfs ofc, but that is of no consequence to the kernel or the init. the fun starts after that, once your PID 1 process is running. pivot_root also doesn't come into play any earlier than that. at that point, i.e. when PID 1 is up, the kernel couldn't care less about what the root filesystem of that process looks like. it's all in the hands of that process.

Well the kernel docs explains that there is indeed a BIG difference, kernels after 2.6 ALWAYS mount a ramfs on the rootfs (the first node in the hierarchical FS), this initial ramfs can be empty (as per default) but can also be used either embedding an initaramfs in the kernel or extracting a cpio.gz into it.
That rootfs cannot be changed, you can mount something over it but cannot be moved, so if using a regular initrd the init process mounts something over rootfs and pivot_root.

Quote:

- When switching another root device, initrd would pivot_root and then
umount the ramdisk. But initramfs is rootfs: you can neither pivot_root
rootfs, nor unmount it. Instead delete everything out of rootfs to
free up the space (find -xdev / -exec rm '{}' ';'), overmount rootfs
with the new root (cd /newmount; mount --move . /; chroot .), attach
stdin/stdout/stderr to the new /dev/console, and exec the new init.

Since this is a remarkably persnickity process (and involves deleting
commands before you can run them), the klibc package introduced a helper
program (utils/run_init.c) to do all this for you. Most other packages
(such as busybox) have named this command "switch_root".

_________________True ignorance is not the absence of knowledge, but the refusal to acquire it.
A posse ad esse non valet consequentia
Πάντα ῥεῖ

well the root kernel thread starts the init thread that ends with a call to kernel_execve(init), so basically init is running into a kernel thread. The init_thread also initializes forks allocating memory.
kexec is very nice when it works ........

that's how init is "special" in that it's not allowed to die . it's still a separate thread though - and a process is really just a collection of threads, so... yeah.

never had kexec fail on me, btw. does exactly what it says...

erm67 wrote:

Well the kernel docs explains that there is indeed a BIG difference, kernels after 2.6 ALWAYS mount a ramfs on the rootfs (the first node in the hierarchical FS), this initial ramfs can be empty (as per default) but can also be used either embedding an initaramfs in the kernel or extracting a cpio.gz into it.
That rootfs cannot be changed, you can mount something over it but cannot be moved, so if using a regular initrd the init process mounts something over rootfs and pivot_root.

Quote:

- When switching another root device, initrd would pivot_root and then
umount the ramdisk. But initramfs is rootfs: you can neither pivot_root
rootfs, nor unmount it. Instead delete everything out of rootfs to
free up the space (find -xdev / -exec rm '{}' ';'), overmount rootfs
with the new root (cd /newmount; mount --move . /; chroot .), attach
stdin/stdout/stderr to the new /dev/console, and exec the new init.

Since this is a remarkably persnickity process (and involves deleting
commands before you can run them), the klibc package introduced a helper
program (utils/run_init.c) to do all this for you. Most other packages
(such as busybox) have named this command "switch_root".

well, as i said it's not really a functional concern for init itself. init is a programme that is being run by the kernel after a minimal root filesystem is up. init doesn't have to care about what kind of filesystem it's on and neither does the kernel. if you do try to use pivot_root in certain situations then it may fail, but so what? that's true for all syscalls and there's plenty of things an init trying to pivot_root can do instead.

and that was not the alternate use case i suggested for pivot_root - mainly unmounting a physical root filesystem sitting on a drive somewhere. it also doesn't interfere with using pivot_root in general at any point the system is properly 'up' - unless you intend to run directly from that kind of root filesystem. but if you did, then you wouldn't have any use for pivot_root and there would be no need to unmount that filesystem, so i still fail to see the relevance.

I'm afraid you're quite confusing in what you're trying to say... it would seem you're really just infodumping all sorts of information losely related to pivot_root at this point?_________________"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland

well the root kernel thread starts the init thread that ends with a call to kernel_execve(init), so basically init is running into a kernel thread. The init_thread also initializes forks allocating memory.
kexec is very nice when it works ........

that's how init is "special" in that it's not allowed to die . it's still a separate thread though - and a process is really just a collection of threads, so... yeah.

I use systemd so I know exactly what happens when pid eins dies unexpectedly

mdeininger wrote:

well, as i said it's not really a functional concern for init itself. init is a programme that is being run by the kernel after a minimal root filesystem is up. init doesn't have to care about what kind of filesystem it's on and neither does the kernel. if you do try to use pivot_root in certain situations then it may fail, but so what? that's true for all syscalls and there's plenty of things an init trying to pivot_root can do instead.

In fact busybox only provides a way to restart itself (re-execing) after the root has been set up, and basically that was my original question, how should that work in epoch? Epoch's website recommends that /proc should not be unmounted at shutdown because epoch needs it, and well also during (before/after) a pivot_root(2) that '/proc required' problem should be handled in some way, ok epoch could just keep using the old but it is not clean.

I still had no time to test the built-in pivot_root capabilities, but could be handy in some situations, just not in an initramfs (that unfortunately is the most widely used kind of initrd today).
But, as you say, someone could freely use pivot_root for all other situation he/she might find it useful, just not to boot from an initramfs that is the only situation someone could desire to use it today (apart some special cases, like remount / rw in a running system).

Basically it works this way with kernel >2.6, sysinit script sets up the root using pivot_root or switch_root, sends sigquit to init that restarts itself in the new root. init doesn't do anything special but there must be a way to tell him to restart itself in the new root becouse of that special kernel thread before, it is not possible for a script to kill and restart init. That is all init have to care about.

When I looked at Subsentient code and noticed it was actually taking care of the pivot_root, I imagined it could be useful on a small router to switch from readonly / to rw / at runtime. I just complained it was too bad it can't be used in an initramfs.

Basically if you read back your posts, it looks like you are just remembering vaguely how kernel 2.4 worked.

mdeininger wrote:

and that was not the alternate use case i suggested for pivot_root - mainly unmounting a physical root filesystem sitting on a drive somewhere. it also doesn't interfere with using pivot_root in general at any point the system is properly 'up' - unless you intend to run directly from that kind of root filesystem. but if you did, then you wouldn't have any use for pivot_root and there would be no need to unmount that filesystem, so i still fail to see the relevance.

I'm afraid you're quite confusing in what you're trying to say... it would seem you're really just infodumping all sorts of information losely related to pivot_root at this point?

Ok I am confused, right, but I am curious: did you updated e-init to kernel >2.6 before the project stalled?

Butts McCracken wrote:

Some of these sound easy to exploit

well it all happens in what they call early userspace, usually the system init (the second init) ignores sigquit exactly for that reason_________________True ignorance is not the absence of knowledge, but the refusal to acquire it.
A posse ad esse non valet consequentia
Πάντα ῥεῖ

2.4 kernel? that's waaaaay older than eINIT. I've designed it on 2.6 with no regard for 2.4 whatsoever. well, linux 2.6, openbsd 6+ and 2008+ darwins, anyway. and i just tried it on a 3.2 'buntu box on which it worked quite fine, so... yeah... pretty sure my interpretation was solid after all ._________________"Confident, lazy, cocky, dead." -- Felix Jongleur, Otherland

Well guys, I need testers for the final lump that's to become 1.0 stable (just use git/master). I especially need testers for the new PivotPoint commands, the syntax for which is inside InitConfig() as a strncmp argument, towards the end of the function. Don't look too hard though, that's one ugly function.
My energy levels have been too low to do much of anything useful as of late, so development has been a little slow, but we're about ready to release 1.0, and all I need is some generous souls to do some real testing for me. Here's what would be most useful:

1. Build an initrd that uses Epoch, and make it do something useful.
2. Write an epoch.conf from scratch
3. Test with uClibc and dietlibc.
4. Put lots of weird garbage values in config, like ObjectIDfgrtgrtgrtjkgrtgkjhrtgkrtgrtkhgrg and EnableLogging=turnip, and tell me if it gives you any trouble. I never found any.
5. Test out all the applets listed by 'epoch help'.

What time frame are you looking for? I usually don't mess around with init stuff, but it's on my list. I might be able to lend some minor / tertiary testing._________________lolgov. 'cause where we're going, you don't have civil liberties.

Epoch's website recommends that /proc should not be unmounted at shutdown because epoch needs it, and well also during (before/after) a pivot_root(2) that '/proc required' problem should be handled in some way, ok epoch could just keep using the old but it is not clean.

No, Epoch will work fine with that. There should be no issues if you unmount /proc before the reexecution, but it's strongly recommended you mount /proc on the new root if the new init is Epoch. Of course, Epoch will do that for you if you specify everything with 'MountVirtual' :^)

erm67 wrote:

When I looked at Subsentient code and noticed it was actually taking care of the pivot_root, I imagined it could be useful on a small router to switch from readonly / to rw / at runtime. I just complained it was too bad it can't be used in an initramfs.