initramfs-tools stable release 0.93.3
small random fixes all over the place, see belows shortlog or git clone git://git.debian.org/kernel/initramfs-tools.git
or online repo:
http://git.debian.org/git/kernel/initramfs-tools.git
Signature · 23 lines
maks
Loic Minier (1):
copy_exec: also avoid picking sse2, neon, and vfp hwcaps libs.
maximilian attems (11):
cleanup LABEL handling code
update-initramfs: Text exit code of command -v too.
hook-functions: Add i915 module for kms.
update-initramfs: Pass version to flash-kernel
update-initramfs: Don't hardcode path for lilo or elilo.
hook-functions: MODULES=dep error out if sysfs not mounted on /sys.
debian/control: No longer mention EVMS in long description.
hook-functions: MODULES=most fix old typo s/smc911x/smc91x/
mkinitramfs: Invoke dpkg --print-architecture
nuke useless old file
release 0.93.3
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.htmlA message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 2 lines · maximilian attems
hook-functions: Add i915 module for kms.
This is exactly the kind of bloat I want to avoid for the initramfs. The initramfs should do one thing only, that's mount the root filesystem and chain load into it.
Anything else is an extravagance.
Why load the KMS driver in the initramfs? Because it takes too long to get to the point in the real system where we can load it! Why does it take too long to get there? Because we spend so long in the initramfs!
Slimming the initramfs right down to the essentials reduces the boot time by over a second! Paradoxically, this means that the driver can be loaded in the real system at roughly the same time point as it would be loaded in a bloated initramfs.
Scott
Signature · 2 lines
Scott James Remnant scott-GeWIH/[email protected]
Quoted 7 lines · Scott James Remnant
Quoted 2 lines · maximilian attems
hook-functions: Add i915 module for kms.
This is exactly the kind of bloat I want to avoid for the initramfs. The initramfs should do one thing only, that's mount the root filesystem and chain load into it.
well it is useful to resume or to load acpi modules early so boxes don't overheat. also there are quite some different scenarios your root can be on.
Quoted 5 lines
Anything else is an extravagance.
Why load the KMS driver in the initramfs? Because it takes too long to get to the point in the real system where we can load it! Why does it take too long to get there? Because we spend so long in the initramfs!
fb modules got scrammed in the initramfs from early on since the time of jbailey.
Quoted 4 lines
Slimming the initramfs right down to the essentials reduces the boot time by over a second! Paradoxically, this means that the driver can be loaded in the real system at roughly the same time point as it would be loaded in a bloated initramfs.
well afair the intel fast boot doesn't use initramfs in the fast path at all, what are you up to axe. on irc you mentioned locales (which are not in initramfs), fonts (detto), keymaps (only if you have cryptsetup installed), splash screen (you need to have the relevant installed) and kms.
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · maximilian attems
Quoted 2 lines · Scott James Remnant
On Wed, 2009-06-10 at 17:30 +0200, maximilian attems wrote:
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
hook-functions: Add i915 module for kms.
This is exactly the kind of bloat I want to avoid for the initramfs. The initramfs should do one thing only, that's mount the root filesystem and chain load into it.
well it is useful to resume or to load acpi modules early so boxes don't overheat.
If you don't include them in the initramfs, your initramfs will be smaller so quicker to load, decompress and unpack. If you then load them immediately after mounting the root filesystem, will they be loaded
(a) sooner or (b) later than before?
Research tends to suggest (a)
If you skip the initramfs, how are they loaded otherwise? In some cases they may never be loaded at all! In others, they're loaded by udev - which is used in the initramfs as well, so why force load them?
Quoted 3 lines
also there are quite some different scenarios your root can be on.
While true, changing the root format is a software configuration change not a hardware configuration change. Changing to/from software RAID, LVM, encrypted root, etc. is all a major enough change (including fstab, as well as raid config files, etc.) that it's ok to need to update your initramfs to include the necessary changes.
This is very different from changing your storage controller card.
Quoted 8 lines
Quoted 4 lines
Slimming the initramfs right down to the essentials reduces the boot time by over a second! Paradoxically, this means that the driver can be loaded in the real system at roughly the same time point as it would be loaded in a bloated initramfs.
well afair the intel fast boot doesn't use initramfs in the fast path at all
Our fast boot does use an initramfs.
Scott
Signature · 2 lines
Scott James Remnant scott-GeWIH/[email protected]
Scott James Remnant wrote:
[snip]
Quoted 8 lines
Quoted 7 lines
Quoted 4 lines
Slimming the initramfs right down to the essentials reduces the boot time by over a second! Paradoxically, this means that the driver can be loaded in the real system at roughly the same time point as it would be loaded in a bloated initramfs.
well afair the intel fast boot doesn't use initramfs in the fast path at all
Our fast boot does use an initramfs.
This is a bit offtopic: Do you have any more info about intel fast boot? I use an intel atom board at home which supposedly has intel fast boot, but I haven't found any info on how to make use of that.
Thanks,
Philippe
Quoted 2 lines
Scott
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · Seewer Philippe
Scott James Remnant wrote:
[snip]Quoted 7 lines
Quoted 7 lines
Quoted 4 lines
Slimming the initramfs right down to the essentials reduces the boot time by over a second! Paradoxically, this means that the driver can be loaded in the real system at roughly the same time point as it would be loaded in a bloated initramfs.
well afair the intel fast boot doesn't use initramfs in the fast path at all
Quoted 8 lines
Quoted 1 line
Our fast boot does use an initramfs.
This is a bit offtopic: Do you have any more info about intel fast boot? I use an intel atom board at home which supposedly has intel fast boot, but I haven't found any info on how to make use of that.
Thanks,
Philippe
Linux "fast boot" is purely a software feature. The most significant hardware feature is a BIOS which doesn't take too long before it loads the kernel.
Possibly the marketing people have confused you with their use of the word "supports". The closest match to "supports intel fast boot" would be "supported by Moblin". Moblin is the optimized distribution initially developed by Intel. One of the optimizations was to limit the supported hardware configurations. Intel Atom boards were obviously favoured ;-). Cynicism aside, it's well worth a look.
Alan
--
To unsubscribe from this list: send the line "unsubscribe initramfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html