Re: [gentoo-user] Question about genkernel's default kernel config
2016-08-14 16:45 GMT+05:00 Raymond Jennings : > Hey, just curious about something: > > How is genkernel's "default" kernel config maintained? Is it fixed, or is > it maintained as a diff against upstream, or what? > > I'm curious because I'm considering if I should just go straight to the > kernel's own built in defaults. > > I know a lot of it sets up most things as modules instead of > builtin/disabled. > Default config is maintained by genkernel developers ( https://gitweb.gentoo.org/proj/genkernel.git/tree/defaults). Definitely you should build own kernel configuration, and genkernel can significantly ease this task. genkernel supports --menuconfig and --oldconfig (which placed into /etc/kernels by default) options, so you can customize and rebuild new versions of kernel based on customized config. I suggest to read https://wiki.gentoo.org/wiki/Genkernel for final enlightenment. -- >From Siberia with Love!
Re: [gentoo-user] Re: Question about genkernel's default kernel config
On Sunday, August 14, 2016 08:38:42 PM Mike Gilbert wrote: > On Sun, Aug 14, 2016 at 4:29 PM, J. Roeleveld wrote: > > On August 14, 2016 8:55:32 PM GMT+02:00, Neil Bothwick wrote: > >>On Sun, 14 Aug 2016 11:48:08 -0700, Ian Zimmerman wrote: > >>> Don't you still need genkernel if you want to build an initramfs? > >> > >>No, dracut. > >> > >>> The handbook (amd64) seems to imply you do, and I don't know of an > >> > >>easy > >> > >>> way to build an initramfs just with the bare kernel source. > >> > >>Dracut. > >> > > Dracut if you just want something quick and easy. > > If you want something small and reliable, build your own. > > A homegrown initramfs created by a novice is going to be more reliable > than one created by dracut or genkernel? Seems unlikely. The ones created by genkernel or dracut always need a few iterations before they work semi-reliably and are not flexible enough. I have 2 disks in my laptop. Both are encrypted using LUKS and the same passphrase. Neither genkernel nor dracut have the intelligence to ask me once and try the key on both, only asking for a 2nd key when the provided one doesn't work for both. I ended up writing my own, which has proven more reliable and stable. The reduced size also makes maintenance less of an issue. -- Joost
Re: [gentoo-user] Re: Question about genkernel's default kernel config
On Monday, August 15, 2016 09:48:14 AM Jeroen Mathon wrote: > I have used genkernel for my initramfs. > > The dracut one seems to hang on a kernel panic(Implying that it did not > load the correct modules for luks and lvm). In my experience, normal for both... > Besides the size of your initramfs should not matter since its only used > to mount the partitions and do the pre-kernel loading. Agreed, except for the next part: > The only thing that you will win by making your own initramfs would be > size and boot speed. If done sanely, the reduced complexity makes debugging and maintenance a lot easier. > Correct me if im wrong btw. > > On 15-08-16 02:45, Rich Freeman wrote: > > On Sun, Aug 14, 2016 at 7:38 PM, Mike Gilbert wrote: > >> On Sun, Aug 14, 2016 at 4:29 PM, J. Roeleveld wrote: > >>> On August 14, 2016 8:55:32 PM GMT+02:00, Neil Bothwick wrote: > On Sun, 14 Aug 2016 11:48:08 -0700, Ian Zimmerman wrote: > > Don't you still need genkernel if you want to build an initramfs? > > No, dracut. > > > The handbook (amd64) seems to imply you do, and I don't know of an > > easy > > > way to build an initramfs just with the bare kernel source. > > Dracut. > >>> > >>> Dracut if you just want something quick and easy. > >>> If you want something small and reliable, build your own. > >> > >> A homegrown initramfs created by a novice is going to be more reliable > >> than one created by dracut or genkernel? Seems unlikely. > > > > This is a silly argument. Everybody knows that anybody who wants > > something reliable just writes their own kernel in the first place.
Re: [gentoo-user] Re: Question about genkernel's default kernel config
On Mon, Aug 15, 2016 at 4:10 AM, J. Roeleveld wrote: > > The ones created by genkernel or dracut always need a few iterations before > they work semi-reliably and are not flexible enough. > I have 2 disks in my laptop. Both are encrypted using LUKS and the same > passphrase. Neither genkernel nor dracut have the intelligence to ask me once > and try the key on both, only asking for a 2nd key when the provided one > doesn't work for both. > > I ended up writing my own, which has proven more reliable and stable. The > reduced size also makes maintenance less of an issue. > Nothing wrong with this if you know what you're doing. Dracut is designed to be one-size-fits-all with a lot of logic to figure out what your system needs to boot. It is also somewhat dependent on a correct fstab. Don't take that for granted: the kernel doesn't look at fstab at all when mounting root, and neither do most of the other tools, so if your root partition isn't correctly defined in fstab you might never know it and dracut will get confused. If nothing else once it does have it correctly mounted it will read fstab and then mess it up when it re-mounts root per "your" instructions. If you just need to tweak dracut behavior you may be better off with a dracut module. They're just shell scripts and pretty simple to write. That lets you tweak something at some point during boot without having to build the entire thing yourself. And since it uses udev it is fairly robust against things like adding a drive and now the kernel re-letters everything. If you tweak it to use the same password for all drives I wouldn't be surprised if upstream accepts the patch... -- Rich
Re: [gentoo-user] Re: Question about genkernel's default kernel config
On Mon, 15 Aug 2016 10:10:22 +0200, J. Roeleveld wrote: > > A homegrown initramfs created by a novice is going to be more reliable > > than one created by dracut or genkernel? Seems unlikely. > > The ones created by genkernel or dracut always need a few iterations > before they work semi-reliably and are not flexible enough. Yes, I usually have to rerun dracut a few times after tweaking its options, because I don't use the full-fat defaults. However, when I rolled my own initramfs, there were several more iterations after making changes. In my experience, once you have a sensible config, dracut just works - your comments about multiple LUKS partitions notwithstanding. -- Neil Bothwick Biology is the only science in which multiplication means the same thing as division. pgpYg7sYNYLnD.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Question about genkernel's default kernel config
On Mon, 15 Aug 2016 12:27:43 +0500, Azamat Hackimov wrote: > Definitely you should build own kernel configuration, and genkernel can > significantly ease this task. > genkernel supports --menuconfig and --oldconfig (which placed into > /etc/kernels by default) options, so you can customize and rebuild new > versions of kernel based on customized config. How is that "significantly easier" than typing make oldconfig? -- Neil Bothwick Drive not ready: (R)etry (G)o to Impulse (C)all Engineering pgp0SXA9xXdvd.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Re: Question about genkernel's default kernel config
On Monday, August 15, 2016 04:32:29 AM Rich Freeman wrote: > On Mon, Aug 15, 2016 at 4:10 AM, J. Roeleveld wrote: > > The ones created by genkernel or dracut always need a few iterations > > before > > they work semi-reliably and are not flexible enough. > > I have 2 disks in my laptop. Both are encrypted using LUKS and the same > > passphrase. Neither genkernel nor dracut have the intelligence to ask me > > once and try the key on both, only asking for a 2nd key when the provided > > one doesn't work for both. > > > > I ended up writing my own, which has proven more reliable and stable. The > > reduced size also makes maintenance less of an issue. > > Nothing wrong with this if you know what you're doing. Dracut is > designed to be one-size-fits-all with a lot of logic to figure out > what your system needs to boot. > > It is also somewhat dependent on a correct fstab. Don't take that for > granted: the kernel doesn't look at fstab at all when mounting root, > and neither do most of the other tools, so if your root partition > isn't correctly defined in fstab you might never know it and dracut > will get confused. If nothing else once it does have it correctly > mounted it will read fstab and then mess it up when it re-mounts root > per "your" instructions. I understand what you're saying. Except in my case, that wasn't the cause. > If you just need to tweak dracut behavior you may be better off with a > dracut module. They're just shell scripts and pretty simple to write. > That lets you tweak something at some point during boot without having > to build the entire thing yourself. This actually had (or has, not bothered to check current status) a distinct lack of usable documentation. Looking for clear howto's on creating my own (embedded into the kernel) initramfs was a lot quicker. > And since it uses udev it is fairly robust against things like adding > a drive and now the kernel re-letters everything. If I were using normal partitioning, I wouldn't need an initramfs. > If you tweak it to use the same password for all drives I wouldn't be > surprised if upstream accepts the patch... If it were properly documented where it does this, I would be willing to try. Right now, my init-script is 45 lines (including white-space) My laptop has 2 disks. Both are fully encrypted (apart from a small /boot). On top of the encrypted parts I have LVM, which contains my partitions. It asks for a password, decrypts both drives, enables LVM, checks if it needs to resume from "suspend to disk", if not, mounts the partitions and boots. If it does need to resume, it simply resumes. If it fails anywhere, it drops me into a busybox shell. I can then simply "cat" the init script to see what commands I need to run to boot, replacing anything that is no longer valid. With dracut and genkernel, the init-script is too convoluted to simply follow. Which means it is not allowed to fail. -- Joost
Re: [gentoo-user] Question about genkernel's default kernel config
2016-08-15 13:43 GMT+05:00 Neil Bothwick : > On Mon, 15 Aug 2016 12:27:43 +0500, Azamat Hackimov wrote: > > > Definitely you should build own kernel configuration, and genkernel can > > significantly ease this task. > > genkernel supports --menuconfig and --oldconfig (which placed into > > /etc/kernels by default) options, so you can customize and rebuild new > > versions of kernel based on customized config. > > How is that "significantly easier" than typing make oldconfig? > > > -- > Neil Bothwick > > Drive not ready: (R)etry (G)o to Impulse (C)all Engineering > Well, at least for me it's much easier just type genkernel --oldconfig=/etc/kernels/ than cp config make oldconfig make make modules make install grub2-mkconfig -o /boot/grub/grub.cfg -- >From Siberia with Love!
Re: [gentoo-user] Question about genkernel's default kernel config
On 08/15/2016 03:27 AM, Azamat Hackimov wrote: I suggest to read https://wiki.gentoo.org/wiki/Genkernel for final enlightenment. From Siberia with Love! As well as:: https://wiki.gentoo.org/wiki/Initramfs/Guide hth, James
Re: [gentoo-user] Re: Question about genkernel's default kernel config
On Mon, Aug 15, 2016 at 5:06 AM, J. Roeleveld wrote: > On Monday, August 15, 2016 04:32:29 AM Rich Freeman wrote: >> >> It is also somewhat dependent on a correct fstab. Don't take that for >> granted: the kernel doesn't look at fstab at all when mounting root, >> and neither do most of the other tools, so if your root partition >> isn't correctly defined in fstab you might never know it and dracut >> will get confused. If nothing else once it does have it correctly >> mounted it will read fstab and then mess it up when it re-mounts root >> per "your" instructions. > > I understand what you're saying. Except in my case, that wasn't the cause. > Oh, I agree. I just said that in lieu of replying to every single other email in this thread. :) >> If you just need to tweak dracut behavior you may be better off with a >> dracut module. They're just shell scripts and pretty simple to write. >> That lets you tweak something at some point during boot without having >> to build the entire thing yourself. > > This actually had (or has, not bothered to check current status) a distinct > lack of usable documentation. Looking for clear howto's on creating my own > (embedded into the kernel) initramfs was a lot quicker. Yeah, I found this frustrating as well. This may or may not be helpful: https://rich0gentoo.wordpress.com/2012/01/21/a-quick-dracut-module/ In general the benefits of using dracut are the benefits of using anything that somebody else maintains. You could replace openrc with a single shell script as well, or a fair bit of systemd. That doesn't mean that this is really the optimal approach. >> And since it uses udev it is fairly robust against things like adding >> a drive and now the kernel re-letters everything. > If I were using normal partitioning, I wouldn't need an initramfs. An initramfs is beneficial even if you don't "need" one. To start with it allows you to build a more modular kernel, which is especially beneficial if you aren't customizing your kernel for every host. It also tends to be more robust when something goes wrong. You end up having a rescue shell even if root doesn't mount, more robust fsck/etc during early boot, and it is going to be a lot smarter when you add/remove a drive (since root can be identified by UUID or label). Dracut is becoming common enough that I think it is worth learning... -- Rich
Re: [gentoo-user] EAPI packages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/13/2016 09:40 AM, hw wrote:
> Fernando Rodriguez schrieb:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 08/12/2016 08:44 AM, Jeroen Mathon wrote:
>>> Is it perhaps an idea to mask the gentoolkit package when updating portage?
>>
>> Since that version of gentoolkit doesn't depend on a specific version of
>> portage
>> but does depend on portage with the same python_targets use flags, I think
>> the problem
>> is that you're trying to emerge portage and gentoolkit with different
>> python_target_XXX
>> flags, So just make sure they're the same.
>
> I have removed gentoolkit, and it still fails:
>
> emerge --ask --update --newuse portage
> [...]
> WARNING: One or more updates/rebuilds have been skipped due to a dependency
> conflict:
>
> sys-apps/portage:0
>
> (sys-apps/portage-2.2.28:0/0::gentoo, ebuild scheduled for merge) conflicts
> with
>
> sys-apps/portage[python_targets_python2_7(-),python_targets_python3_3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-)]
> required by (app-admin/webapp-config-1.52-r1:0/0::gentoo, installed)
>
>
Now it's app-admin/webapp-config it has the same dep on portage
(sys-apps/portage[${PYTHON_USEDEP}]) only when the portage use flag is enabled.
You're trying to build portage with a new python target when everything else is
built for a different
python version. Either change portage's to the same as everythhing else or
remerge all packages that depend
on portage first.
- --
Fernando Rodriguez
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQIbBAEBCAAGBQJXsb/LAAoJEPbOFX/5UlwcNXYP90frLRuF6wdEiagkMJys40Bo
CTqdEpBlFmVRxqKFORspK6cnqqOQwpUII58nGkITp7XoNSK0FfQRtZH7ANvW9VL4
s4C54VjMzd8avjxlf06nV0VSdLD/Et8UzqXwYrKMKwJtXDVzVBUEgqSsz2CoPDoi
295PFoLRhlShJ+MXZGOTCwc3U+WJ1NJmotgzQkwprKLifAZLQguXyZW1yEVfrT2E
1Q+boC5gcCat6DkSsMFoQd/GMlXabeoiHUowFD5bbv8hyDOdQokmDbIuSJkF3miO
6UJ7LC7CWezqxl7X7u2ZDc6jntTQO3j+CkRyNkvNeJEpLpuNgi1NWgSFwEJBS22P
X+X0wEpakyUTokV/IEZ++l7Z78qkn+Bspqokqp0vkMU/5QEu9EgPMe2zdfoX+BRy
NRjX0Ntgf850uzDlvjTKcDVdThW+W0o7hhBOTrd6C0jIZp6htL2RUb79b/qbIeg3
r7/XGip7Iq9ehWIwRui/Uj4k5vHVporXVE+zFcnBrvoME0DZfVI5OuhVv040V+Nj
P64pDr9edgCWxuIqesAITbtaHH5Fjc8zTx5+67uqUb+wwn0aVn3ptKQjJqy5364r
o38VEZ5a/Uypxf1Q03NL/mJgVswLv21D1tURosE7p9oduGa4LGszPnBDSi9oIkh1
lYV7vHU1nyy0vGY9M+E=
=7ftw
-END PGP SIGNATURE-
Re: [gentoo-user] EAPI packages
On 08/15/2016 09:12 AM, Fernando Rodriguez wrote:
> On 08/13/2016 09:40 AM, hw wrote:
>> Fernando Rodriguez schrieb:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA256
>>>
>>> On 08/12/2016 08:44 AM, Jeroen Mathon wrote:
Is it perhaps an idea to mask the gentoolkit package when updating portage?
>>>
>>> Since that version of gentoolkit doesn't depend on a specific version of
>>> portage
>>> but does depend on portage with the same python_targets use flags, I think
>>> the problem
>>> is that you're trying to emerge portage and gentoolkit with different
>>> python_target_XXX
>>> flags, So just make sure they're the same.
>
>> I have removed gentoolkit, and it still fails:
>
>> emerge --ask --update --newuse portage
>> [...]
>> WARNING: One or more updates/rebuilds have been skipped due to a dependency
>> conflict:
>
>> sys-apps/portage:0
>
>> (sys-apps/portage-2.2.28:0/0::gentoo, ebuild scheduled for merge)
>> conflicts with
>>
>> sys-apps/portage[python_targets_python2_7(-),python_targets_python3_3(-),-python_single_target_python2_7(-),-python_single_target_python3_3(-)]
>> required by (app-admin/webapp-config-1.52-r1:0/0::gentoo, installed)
>
>
>
> Now it's app-admin/webapp-config it has the same dep on portage
> (sys-apps/portage[${PYTHON_USEDEP}]) only when the portage use flag is
> enabled.
>
> You're trying to build portage with a new python target when everything else
> is built for a different
> python version. Either change portage's to the same as everythhing else or
> remerge all packages that depend
> on portage first.
Actually rebuilding everything that depends on python won't work because the
--newuse would've pull
them if it was a global change. You must've changed just for portage on
package.use at some point.
What is the output of "equery uses app-admin/webapp-config sys-apps/portage"?
--
Fernando Rodriguez
Re: [gentoo-user] Re: Choice of MUA
On Saturday 13 Aug 2016 09:21:14 I wrote: > Thanks all for your contributions. I meant to add that I'd found this page[0], which lists more MUAs than you could shake a stick at, but sadly only a few extant. [0] http://linuxmafia.com/faq/Mail/muas.html -- Rgds Peter
Re: [gentoo-user] Re: Choice of MUA
It mostly depends on your preference and what you use most. If you have a DE focussed on CLI(awesomewm,i3) then stick to mail clients like mutt, otherwise use something like geary,evolution,thunderbird On Mon, 15 Aug 2016, 17:54 Peter Humphrey, wrote: > On Saturday 13 Aug 2016 09:21:14 I wrote: > > > Thanks all for your contributions. > > I meant to add that I'd found this page[0], which lists more MUAs than you > could shake a stick at, but sadly only a few extant. > > [0] http://linuxmafia.com/faq/Mail/muas.html > > -- > Rgds > Peter > > >
Re: [gentoo-user] Question about genkernel's default kernel config
On Mon, 15 Aug 2016 07:57:02 -0400, james wrote: > > I suggest to read https://wiki.gentoo.org/wiki/Genkernel for final > > enlightenment. > > As well as:: > > > https://wiki.gentoo.org/wiki/Initramfs/Guide If you want to look at rolling your own, see /usr/src/linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt -- Neil Bothwick WindowError:01B Illegal error. Do NOT get this error. pgp4nQ1DmCY84.pgp Description: OpenPGP digital signature
[gentoo-user] Sweet Sweet Portage
Well, I brought this up before. No need for argument, just test it out for yourself. Multiple times (over the last few weeks) I have run 'emerge -uDNvp @world' and there are issues to deal with manually. For example 'One or more updates/rebuilds have been skipped due to a dependency conflict', type of fudd and other types of fudd is the result, not all the time, but maybe 50% of the time. Now, routinely, all I do is immediately issue this command 'emerge -uDt @world' and go have a coffee. An AMD 8 core, 32G workstation does it's thang, leaving me a with just a smile after the work is complete. No other actions, nadda, ziltch. Immediately, I then run 'emerge -uDNvp world' (again, and routinely I get:: "These are the packages that would be merged, in order: Calculating dependencies... done! Total: 0 packages, Size of downloads: 0 KiB" Just try it for yourself. It's like clockwork now. Smooth. I have over 1500 packages installed on a mostly stable but hacked out /usr/local/portage/ and maybe 10% of the packages, that are much newer, but portage is sweet, sweet, sweet now. There is inherent magic now, but, I do not have time to ferret it out. Sure I can dive in, manually, and I have done this to fix things, but, 'emerge -uDt @world' fixes things, automagically; dozens of times as I update 3 or 4 times a week. YMMV. --livin the dream, brah, livin the dream. hth, James
Re: [gentoo-user] Sweet Sweet Portage
On 16/08/2016 00:02, james wrote: > Well, > > I brought this up before. No need for argument, just test it out > for yourself. > > Multiple times (over the last few weeks) I have run 'emerge -uDNvp > @world' and there are issues to deal with manually. > > For example 'One or more updates/rebuilds have been skipped due to a > dependency conflict', type of fudd and other types of fudd is the > result, not all the time, but maybe 50% of the time. > > > Now, routinely, all I do is immediately issue this command > 'emerge -uDt @world' and go have a coffee. An AMD 8 core, 32G > workstation does it's thang, leaving me a with just a smile after the > work is complete. No other actions, nadda, ziltch. Immediately, I then > run 'emerge -uDNvp world' (again, and routinely I get:: > > "These are the packages that would be merged, in order: > > Calculating dependencies... done! > > Total: 0 packages, Size of downloads: 0 KiB" > > > Just try it for yourself. It's like clockwork now. Smooth. I have over > 1500 packages installed on a mostly stable but hacked out > /usr/local/portage/ and maybe 10% of the packages, that are much newer, > but portage is sweet, sweet, sweet now. There is inherent magic now, but, > I do not have time to ferret it out. Sure I can dive in, manually, > and I have done this to fix things, but, 'emerge -uDt @world' fixes > things, automagically; dozens of times as I update 3 or 4 times a week. Please post the output of layman -l > > > > YMMV. --livin the dream, brah, livin the dream. > hth, > James > > -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Sweet Sweet Portage
Please post the output of layman -l alunduil java pentoo science sunrise torbrower ultrabug xmw It works on the portage tree James
Re: [gentoo-user] Sweet Sweet Portage
On Mon, Aug 15, 2016 at 06:02:27PM -0400, james wrote What response do you get with... emerge --backtrack=30 -pvuDt @world Note that I've included "pv" to turn it into a "dummy run" with verbose output. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] Re: Question about genkernel's default kernel config
On Monday, August 15, 2016 08:41:31 AM Rich Freeman wrote: > On Mon, Aug 15, 2016 at 5:06 AM, J. Roeleveld wrote: > > On Monday, August 15, 2016 04:32:29 AM Rich Freeman wrote: > >> It is also somewhat dependent on a correct fstab. Don't take that for > >> granted: the kernel doesn't look at fstab at all when mounting root, > >> and neither do most of the other tools, so if your root partition > >> isn't correctly defined in fstab you might never know it and dracut > >> will get confused. If nothing else once it does have it correctly > >> mounted it will read fstab and then mess it up when it re-mounts root > >> per "your" instructions. > > > > I understand what you're saying. Except in my case, that wasn't the cause. > > Oh, I agree. I just said that in lieu of replying to every single > other email in this thread. :) > > >> If you just need to tweak dracut behavior you may be better off with a > >> dracut module. They're just shell scripts and pretty simple to write. > >> That lets you tweak something at some point during boot without having > >> to build the entire thing yourself. > > > > This actually had (or has, not bothered to check current status) a > > distinct > > lack of usable documentation. Looking for clear howto's on creating my own > > (embedded into the kernel) initramfs was a lot quicker. > > Yeah, I found this frustrating as well. > > This may or may not be helpful: > https://rich0gentoo.wordpress.com/2012/01/21/a-quick-dracut-module/ It shows where to find it and add custom steps. For my scenario, I'd need to first find where the code is that currently handles it. Disable that and insert my own in its place. The majority works, except for it asking for my passphrase multiple times, which, in Dracut, might actually be handled by "cryptsetup" itself. In which case I'm stuck. In my script it's handled via: # Obtain key through loop device /sbin/losetup /dev/loop0 /key.iso || rescue_shell /sbin/cryptsetup -T 5 luksOpen /dev/loop0 key || rescue_shell # Unlock the root partition /sbin/cryptsetup --key-file /dev/mapper/key luksOpen --allow-discards /dev/sda2 sda2 || rescue_shell /sbin/cryptsetup --key-file /dev/mapper/key luksOpen --allow-discards /dev/sdb2 sdb2 || rescue_shell # Clean up the loop device /sbin/cryptsetup luksClose key /sbin/losetup -d /dev/loop0 > In general the benefits of using dracut are the benefits of using > anything that somebody else maintains. You could replace openrc with > a single shell script as well, or a fair bit of systemd. That doesn't > mean that this is really the optimal approach. If I'd need the level of complexity Dracut allows, I'd look into it. But all I need to do is maintain a few small and simple files and the kernel-build handles all the heavy lifting. > >> And since it uses udev it is fairly robust against things like adding > >> a drive and now the kernel re-letters everything. > > > > If I were using normal partitioning, I wouldn't need an initramfs. > > An initramfs is beneficial even if you don't "need" one. To start > with it allows you to build a more modular kernel, which is especially > beneficial if you aren't customizing your kernel for every host. It > also tends to be more robust when something goes wrong. You end up > having a rescue shell even if root doesn't mount, more robust fsck/etc > during early boot, and it is going to be a lot smarter when you > add/remove a drive (since root can be identified by UUID or label). > > Dracut is becoming common enough that I think it is worth learning... For binary distributions, I tend to stick with the supplied kernel and initramfs. Those are usually for running software from big vendors like Oracle or IBM. For the rest, it's quicker to make the few changes needed to the init-script. I don't have a large serverfarm requiring that level of standardisation. -- Joost
