Why do we need initramfs and initrd
Clash Royale CLAN TAG#URR8PPP
up vote
3
down vote
favorite
For example we have exotic file system on the disk and in order to load system we need mount root filesystem. But we cannot because there is no suitable driver exists in kernel image.
Let me explain how I understand kernel
and initrd
.
- When kernel is compiled we can select different modules to be included into kernel image (one single file)
- For example my root filesystem is
reiserfs
and I have configured kernel not to includemodule
for this filesystem - In this case kernel doesn't know how to mount such filesystem and it needs some help -> so load
initramfs
into the memory - Find proper module in ram fs (lib/modules or etc)
- Load this module to the kernel
- Now kernel can mount
reiserfs
it mounts and than unloads (frees) memory occupied byramfs
Am I right ?
But I don't understand why do we need initramfs
in every distro ( I have seen it in every distro I have ever installed) if most of specific drivers are already present in kernel image (single file) furthermore we only need drivers for filesystems when kernel boots other drivers can be loaded from the filesystem after it is mounted.
So is it really essential part of any distro ?
P.S What is used more often initramfs
or initrd
and why ?
kernel boot init initramfs initrd
add a comment |
up vote
3
down vote
favorite
For example we have exotic file system on the disk and in order to load system we need mount root filesystem. But we cannot because there is no suitable driver exists in kernel image.
Let me explain how I understand kernel
and initrd
.
- When kernel is compiled we can select different modules to be included into kernel image (one single file)
- For example my root filesystem is
reiserfs
and I have configured kernel not to includemodule
for this filesystem - In this case kernel doesn't know how to mount such filesystem and it needs some help -> so load
initramfs
into the memory - Find proper module in ram fs (lib/modules or etc)
- Load this module to the kernel
- Now kernel can mount
reiserfs
it mounts and than unloads (frees) memory occupied byramfs
Am I right ?
But I don't understand why do we need initramfs
in every distro ( I have seen it in every distro I have ever installed) if most of specific drivers are already present in kernel image (single file) furthermore we only need drivers for filesystems when kernel boots other drivers can be loaded from the filesystem after it is mounted.
So is it really essential part of any distro ?
P.S What is used more often initramfs
or initrd
and why ?
kernel boot init initramfs initrd
This wiki.debian.org/initramfs will answer a lot of your questions.
– Peschke
Jun 9 '16 at 21:01
add a comment |
up vote
3
down vote
favorite
up vote
3
down vote
favorite
For example we have exotic file system on the disk and in order to load system we need mount root filesystem. But we cannot because there is no suitable driver exists in kernel image.
Let me explain how I understand kernel
and initrd
.
- When kernel is compiled we can select different modules to be included into kernel image (one single file)
- For example my root filesystem is
reiserfs
and I have configured kernel not to includemodule
for this filesystem - In this case kernel doesn't know how to mount such filesystem and it needs some help -> so load
initramfs
into the memory - Find proper module in ram fs (lib/modules or etc)
- Load this module to the kernel
- Now kernel can mount
reiserfs
it mounts and than unloads (frees) memory occupied byramfs
Am I right ?
But I don't understand why do we need initramfs
in every distro ( I have seen it in every distro I have ever installed) if most of specific drivers are already present in kernel image (single file) furthermore we only need drivers for filesystems when kernel boots other drivers can be loaded from the filesystem after it is mounted.
So is it really essential part of any distro ?
P.S What is used more often initramfs
or initrd
and why ?
kernel boot init initramfs initrd
For example we have exotic file system on the disk and in order to load system we need mount root filesystem. But we cannot because there is no suitable driver exists in kernel image.
Let me explain how I understand kernel
and initrd
.
- When kernel is compiled we can select different modules to be included into kernel image (one single file)
- For example my root filesystem is
reiserfs
and I have configured kernel not to includemodule
for this filesystem - In this case kernel doesn't know how to mount such filesystem and it needs some help -> so load
initramfs
into the memory - Find proper module in ram fs (lib/modules or etc)
- Load this module to the kernel
- Now kernel can mount
reiserfs
it mounts and than unloads (frees) memory occupied byramfs
Am I right ?
But I don't understand why do we need initramfs
in every distro ( I have seen it in every distro I have ever installed) if most of specific drivers are already present in kernel image (single file) furthermore we only need drivers for filesystems when kernel boots other drivers can be loaded from the filesystem after it is mounted.
So is it really essential part of any distro ?
P.S What is used more often initramfs
or initrd
and why ?
kernel boot init initramfs initrd
kernel boot init initramfs initrd
edited Nov 17 at 20:25
Rui F Ribeiro
38.2k1475123
38.2k1475123
asked Jun 9 '16 at 20:56
solderingiron
585
585
This wiki.debian.org/initramfs will answer a lot of your questions.
– Peschke
Jun 9 '16 at 21:01
add a comment |
This wiki.debian.org/initramfs will answer a lot of your questions.
– Peschke
Jun 9 '16 at 21:01
This wiki.debian.org/initramfs will answer a lot of your questions.
– Peschke
Jun 9 '16 at 21:01
This wiki.debian.org/initramfs will answer a lot of your questions.
– Peschke
Jun 9 '16 at 21:01
add a comment |
3 Answers
3
active
oldest
votes
up vote
4
down vote
The strength comes from all the other things you can do besides loading modules. Basically it gives you a userspace and the possibility of doing all the things you can do from that.
An example: I use an initrd to have an encrypted root fs, setting that up requires code that there's no point having in kernel.
The "Rationale" section of the Wikipedia page on initrd has more examples.
initramfs is a newer (but still fairly old) implementation of the same idea, but the name initrd has survived often to refer to the image used as the early user space.
A totally different reason I just thought of: Embedded devices, they may not have enough memory to cope with a kernel that includes everything.
add a comment |
up vote
2
down vote
There are many reason to have an initramfs, some are below.
- When you need have a separate /usr,/var as some distros depends on having these directories in /
- When you want to encrypt / but you like to have /boot on a usb stick since you can't have an encrypted /boot
- When you don't want to have stuff in kernel builtin but instead as module, that way you only load what you need and this is done in early user space
- When using dmraid on /
- When you need more fine controls i.e You have a remote server which you encrypted / on which now requires that it setups a network in early user space along with dropbear (tiny ssh daemon) to allow you to decrypt your / and proceed with normal boot ;)
I can go on and on with reason why you need an initramfs, but in the end if there is software that needs to run before 'switch_root ...' you will need an initramfs for that.
Having an initramfs makes sense on PC-style hardware with lots of hot-pluggable devices. On the other hand, it makes no sense to boot an embedded operating system using an initramfs. Just use a kernel that supports the particular hardware configuration it is built for.
– fpmurphy1
Jun 10 '16 at 9:50
add a comment |
up vote
1
down vote
I suppose it's true that modern hardware wouldn't mind e.g. a 50MB kernel. You could argue that loading everything as separate modules has not been as important for a while now.
However the initial ram system allows bootstrapping of any possible configuration, without needing any special handling in the kernel. Writing kernel code is a Big Deal. The initial ram system is the correct solution. We can use lots of similar code to the main system, e.g. systemd
;-).
Booting from an encrypted filesystem is one great example of this. Kernel doesn't have to prompt for the passphrase.
An example every modern install uses is finding the root filesystem by UUID (or maybe LVM volume name). This is useful because otherwise your boot breaks when you remove an unrelated partition, because they're all renumbered. Or when you move disks around or between computers. Or when the disk is a live CD.
Why do we need a ram filesystem? Because we don't want to be tightly coupled to the firmware / boot loader. It can just hand us the data as a block of memory, and we're done. We want to keep the boot process as simple we can. Bootup is both critical, and a special case. We don't need a complex interface with other special-case software. Especially the firmware case. Firmware is such a special case, so we wouldn't care about it the rest of the time, it'll be riddled with bugs no-one noticed. And firmware is so critical, that any fixes to it are very risky. Used to be it was ROM and you couldn't patch it at all.
add a comment |
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
4
down vote
The strength comes from all the other things you can do besides loading modules. Basically it gives you a userspace and the possibility of doing all the things you can do from that.
An example: I use an initrd to have an encrypted root fs, setting that up requires code that there's no point having in kernel.
The "Rationale" section of the Wikipedia page on initrd has more examples.
initramfs is a newer (but still fairly old) implementation of the same idea, but the name initrd has survived often to refer to the image used as the early user space.
A totally different reason I just thought of: Embedded devices, they may not have enough memory to cope with a kernel that includes everything.
add a comment |
up vote
4
down vote
The strength comes from all the other things you can do besides loading modules. Basically it gives you a userspace and the possibility of doing all the things you can do from that.
An example: I use an initrd to have an encrypted root fs, setting that up requires code that there's no point having in kernel.
The "Rationale" section of the Wikipedia page on initrd has more examples.
initramfs is a newer (but still fairly old) implementation of the same idea, but the name initrd has survived often to refer to the image used as the early user space.
A totally different reason I just thought of: Embedded devices, they may not have enough memory to cope with a kernel that includes everything.
add a comment |
up vote
4
down vote
up vote
4
down vote
The strength comes from all the other things you can do besides loading modules. Basically it gives you a userspace and the possibility of doing all the things you can do from that.
An example: I use an initrd to have an encrypted root fs, setting that up requires code that there's no point having in kernel.
The "Rationale" section of the Wikipedia page on initrd has more examples.
initramfs is a newer (but still fairly old) implementation of the same idea, but the name initrd has survived often to refer to the image used as the early user space.
A totally different reason I just thought of: Embedded devices, they may not have enough memory to cope with a kernel that includes everything.
The strength comes from all the other things you can do besides loading modules. Basically it gives you a userspace and the possibility of doing all the things you can do from that.
An example: I use an initrd to have an encrypted root fs, setting that up requires code that there's no point having in kernel.
The "Rationale" section of the Wikipedia page on initrd has more examples.
initramfs is a newer (but still fairly old) implementation of the same idea, but the name initrd has survived often to refer to the image used as the early user space.
A totally different reason I just thought of: Embedded devices, they may not have enough memory to cope with a kernel that includes everything.
edited Jun 10 '16 at 6:50
answered Jun 9 '16 at 21:23
Henrik
3,5151419
3,5151419
add a comment |
add a comment |
up vote
2
down vote
There are many reason to have an initramfs, some are below.
- When you need have a separate /usr,/var as some distros depends on having these directories in /
- When you want to encrypt / but you like to have /boot on a usb stick since you can't have an encrypted /boot
- When you don't want to have stuff in kernel builtin but instead as module, that way you only load what you need and this is done in early user space
- When using dmraid on /
- When you need more fine controls i.e You have a remote server which you encrypted / on which now requires that it setups a network in early user space along with dropbear (tiny ssh daemon) to allow you to decrypt your / and proceed with normal boot ;)
I can go on and on with reason why you need an initramfs, but in the end if there is software that needs to run before 'switch_root ...' you will need an initramfs for that.
Having an initramfs makes sense on PC-style hardware with lots of hot-pluggable devices. On the other hand, it makes no sense to boot an embedded operating system using an initramfs. Just use a kernel that supports the particular hardware configuration it is built for.
– fpmurphy1
Jun 10 '16 at 9:50
add a comment |
up vote
2
down vote
There are many reason to have an initramfs, some are below.
- When you need have a separate /usr,/var as some distros depends on having these directories in /
- When you want to encrypt / but you like to have /boot on a usb stick since you can't have an encrypted /boot
- When you don't want to have stuff in kernel builtin but instead as module, that way you only load what you need and this is done in early user space
- When using dmraid on /
- When you need more fine controls i.e You have a remote server which you encrypted / on which now requires that it setups a network in early user space along with dropbear (tiny ssh daemon) to allow you to decrypt your / and proceed with normal boot ;)
I can go on and on with reason why you need an initramfs, but in the end if there is software that needs to run before 'switch_root ...' you will need an initramfs for that.
Having an initramfs makes sense on PC-style hardware with lots of hot-pluggable devices. On the other hand, it makes no sense to boot an embedded operating system using an initramfs. Just use a kernel that supports the particular hardware configuration it is built for.
– fpmurphy1
Jun 10 '16 at 9:50
add a comment |
up vote
2
down vote
up vote
2
down vote
There are many reason to have an initramfs, some are below.
- When you need have a separate /usr,/var as some distros depends on having these directories in /
- When you want to encrypt / but you like to have /boot on a usb stick since you can't have an encrypted /boot
- When you don't want to have stuff in kernel builtin but instead as module, that way you only load what you need and this is done in early user space
- When using dmraid on /
- When you need more fine controls i.e You have a remote server which you encrypted / on which now requires that it setups a network in early user space along with dropbear (tiny ssh daemon) to allow you to decrypt your / and proceed with normal boot ;)
I can go on and on with reason why you need an initramfs, but in the end if there is software that needs to run before 'switch_root ...' you will need an initramfs for that.
There are many reason to have an initramfs, some are below.
- When you need have a separate /usr,/var as some distros depends on having these directories in /
- When you want to encrypt / but you like to have /boot on a usb stick since you can't have an encrypted /boot
- When you don't want to have stuff in kernel builtin but instead as module, that way you only load what you need and this is done in early user space
- When using dmraid on /
- When you need more fine controls i.e You have a remote server which you encrypted / on which now requires that it setups a network in early user space along with dropbear (tiny ssh daemon) to allow you to decrypt your / and proceed with normal boot ;)
I can go on and on with reason why you need an initramfs, but in the end if there is software that needs to run before 'switch_root ...' you will need an initramfs for that.
answered Jun 9 '16 at 22:17
likewhoa
1456
1456
Having an initramfs makes sense on PC-style hardware with lots of hot-pluggable devices. On the other hand, it makes no sense to boot an embedded operating system using an initramfs. Just use a kernel that supports the particular hardware configuration it is built for.
– fpmurphy1
Jun 10 '16 at 9:50
add a comment |
Having an initramfs makes sense on PC-style hardware with lots of hot-pluggable devices. On the other hand, it makes no sense to boot an embedded operating system using an initramfs. Just use a kernel that supports the particular hardware configuration it is built for.
– fpmurphy1
Jun 10 '16 at 9:50
Having an initramfs makes sense on PC-style hardware with lots of hot-pluggable devices. On the other hand, it makes no sense to boot an embedded operating system using an initramfs. Just use a kernel that supports the particular hardware configuration it is built for.
– fpmurphy1
Jun 10 '16 at 9:50
Having an initramfs makes sense on PC-style hardware with lots of hot-pluggable devices. On the other hand, it makes no sense to boot an embedded operating system using an initramfs. Just use a kernel that supports the particular hardware configuration it is built for.
– fpmurphy1
Jun 10 '16 at 9:50
add a comment |
up vote
1
down vote
I suppose it's true that modern hardware wouldn't mind e.g. a 50MB kernel. You could argue that loading everything as separate modules has not been as important for a while now.
However the initial ram system allows bootstrapping of any possible configuration, without needing any special handling in the kernel. Writing kernel code is a Big Deal. The initial ram system is the correct solution. We can use lots of similar code to the main system, e.g. systemd
;-).
Booting from an encrypted filesystem is one great example of this. Kernel doesn't have to prompt for the passphrase.
An example every modern install uses is finding the root filesystem by UUID (or maybe LVM volume name). This is useful because otherwise your boot breaks when you remove an unrelated partition, because they're all renumbered. Or when you move disks around or between computers. Or when the disk is a live CD.
Why do we need a ram filesystem? Because we don't want to be tightly coupled to the firmware / boot loader. It can just hand us the data as a block of memory, and we're done. We want to keep the boot process as simple we can. Bootup is both critical, and a special case. We don't need a complex interface with other special-case software. Especially the firmware case. Firmware is such a special case, so we wouldn't care about it the rest of the time, it'll be riddled with bugs no-one noticed. And firmware is so critical, that any fixes to it are very risky. Used to be it was ROM and you couldn't patch it at all.
add a comment |
up vote
1
down vote
I suppose it's true that modern hardware wouldn't mind e.g. a 50MB kernel. You could argue that loading everything as separate modules has not been as important for a while now.
However the initial ram system allows bootstrapping of any possible configuration, without needing any special handling in the kernel. Writing kernel code is a Big Deal. The initial ram system is the correct solution. We can use lots of similar code to the main system, e.g. systemd
;-).
Booting from an encrypted filesystem is one great example of this. Kernel doesn't have to prompt for the passphrase.
An example every modern install uses is finding the root filesystem by UUID (or maybe LVM volume name). This is useful because otherwise your boot breaks when you remove an unrelated partition, because they're all renumbered. Or when you move disks around or between computers. Or when the disk is a live CD.
Why do we need a ram filesystem? Because we don't want to be tightly coupled to the firmware / boot loader. It can just hand us the data as a block of memory, and we're done. We want to keep the boot process as simple we can. Bootup is both critical, and a special case. We don't need a complex interface with other special-case software. Especially the firmware case. Firmware is such a special case, so we wouldn't care about it the rest of the time, it'll be riddled with bugs no-one noticed. And firmware is so critical, that any fixes to it are very risky. Used to be it was ROM and you couldn't patch it at all.
add a comment |
up vote
1
down vote
up vote
1
down vote
I suppose it's true that modern hardware wouldn't mind e.g. a 50MB kernel. You could argue that loading everything as separate modules has not been as important for a while now.
However the initial ram system allows bootstrapping of any possible configuration, without needing any special handling in the kernel. Writing kernel code is a Big Deal. The initial ram system is the correct solution. We can use lots of similar code to the main system, e.g. systemd
;-).
Booting from an encrypted filesystem is one great example of this. Kernel doesn't have to prompt for the passphrase.
An example every modern install uses is finding the root filesystem by UUID (or maybe LVM volume name). This is useful because otherwise your boot breaks when you remove an unrelated partition, because they're all renumbered. Or when you move disks around or between computers. Or when the disk is a live CD.
Why do we need a ram filesystem? Because we don't want to be tightly coupled to the firmware / boot loader. It can just hand us the data as a block of memory, and we're done. We want to keep the boot process as simple we can. Bootup is both critical, and a special case. We don't need a complex interface with other special-case software. Especially the firmware case. Firmware is such a special case, so we wouldn't care about it the rest of the time, it'll be riddled with bugs no-one noticed. And firmware is so critical, that any fixes to it are very risky. Used to be it was ROM and you couldn't patch it at all.
I suppose it's true that modern hardware wouldn't mind e.g. a 50MB kernel. You could argue that loading everything as separate modules has not been as important for a while now.
However the initial ram system allows bootstrapping of any possible configuration, without needing any special handling in the kernel. Writing kernel code is a Big Deal. The initial ram system is the correct solution. We can use lots of similar code to the main system, e.g. systemd
;-).
Booting from an encrypted filesystem is one great example of this. Kernel doesn't have to prompt for the passphrase.
An example every modern install uses is finding the root filesystem by UUID (or maybe LVM volume name). This is useful because otherwise your boot breaks when you remove an unrelated partition, because they're all renumbered. Or when you move disks around or between computers. Or when the disk is a live CD.
Why do we need a ram filesystem? Because we don't want to be tightly coupled to the firmware / boot loader. It can just hand us the data as a block of memory, and we're done. We want to keep the boot process as simple we can. Bootup is both critical, and a special case. We don't need a complex interface with other special-case software. Especially the firmware case. Firmware is such a special case, so we wouldn't care about it the rest of the time, it'll be riddled with bugs no-one noticed. And firmware is so critical, that any fixes to it are very risky. Used to be it was ROM and you couldn't patch it at all.
edited Jun 9 '16 at 23:09
answered Jun 9 '16 at 22:49
sourcejedi
21.8k43396
21.8k43396
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f288806%2fwhy-do-we-need-initramfs-and-initrd%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
This wiki.debian.org/initramfs will answer a lot of your questions.
– Peschke
Jun 9 '16 at 21:01