Summary: | [patch] sys-kernel/genkernel-3.4.9: support for booting tarballs into a ramdisk | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Stefan Nickl <snickl> |
Component: | genkernel | Assignee: | Gentoo Genkernel Maintainers <genkernel> |
Status: | IN_PROGRESS --- | ||
Severity: | enhancement | CC: | sping |
Priority: | High | Keywords: | Inclusion |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 245389 | ||
Attachments: |
Add tarball rootfs support
Updated patch for genkernel 3.4.10 Bump to git version, untested |
Description
Stefan Nickl
2008-03-01 14:08:41 UTC
Created attachment 145003 [details, diff]
Add tarball rootfs support
The busybox wget applet should probably be enabled for all platforms if this is applied
Created attachment 169176 [details, diff]
Updated patch for genkernel 3.4.10
Update to latest genkernel, also adds tmprootsize option which is passed through to the size mount option of tmpfs.
I apologize that this has taken so long, but genkernel development went on hiatus for a bit while we split off to our own development hosting. Could you rebase the patch against the repository at git://git.wolf31o2.org/projs/genkernel.git instead? We'll be using that to develop 3.4.11 and it's much easier to work with patches that apply cleanly into the repository. Thanks Created attachment 170648 [details, diff]
Bump to git version, untested
I've committed the first half of this patch (the busy-config changes). Is the tmprootsize=foo parameter really necessary? By default, a tmpfs's size is half of physical memory. I know that if you're dealing with a system with 32MB of RAM, that's not very much, but are you really using a genkernel-build kernel/initramfs on a system with 32MB RAM? :) Also, what "formats" (123, 123k, 123m, etc.) does the 'size' parameter for a tmpfs take? I actually added this parameter after trying to run my stuff on a board with just 1GB RAM instead of 8GB boards as before and needed a quick fix when the 512M had run out. Stepping back I think I could do without it as there is a big chunk that is not part of the image itself, but loaded by the image later in the boot process, so the tmpfs could be resized before that chunk comes in. In case you wonder, it's a diagnosis/upgrade image for the boards and the "big chunk" is mostly an FPGA update toolkit :) The parameter didn't feel quite right to me either, and assuming that the above alternative works I won't miss it. The size qualifiers are found in mount(8): Mount options for tmpfs The following parameters accept a suffix k, m or g for Ki, Mi, Gi (binary kilo, mega and giga) and can be changed on remount. Before I commit this, have you boot-tested this with current git? Also, any reason that https can't be supported? The wget in busybox should work just fine with it. Boot-test performed, worked nicely. However I had some trouble since I usually use arguments like "console=tty0 console=ttyS0,115200n8" and output was dead after execution passed "# Redirect output to a specific tty"... Seems like busybox wget doesn't support SSL. But OTOH I can hardly imagine a situation in which one would would like boot over a insecure network. PS: Adding keyword "Inclusion" and "[patch] " prefix to better show this bugs nature in searches... |