On Mon, 19 Mar 2012 19:23:51 +
Bruce Dubbs bruce.du...@gmail.com wrote:
Pierre Labastie wrote:
Also, it might be interesting/necessary to copy the content of
/lib/firmware to $WDIR.
That directory has always been empty for me. What populates it?
I've always thought of that
Le 14/03/2012 00:34, Bruce Dubbs a écrit :
OK, try the updated scripts I just committed when you get a chance.
-- Bruce
Sorry it took some time because I had a few errors in my kernel config
(like not enabling devtmpfs, shame on me, and a problem with the radeon
driver, which was giving a
Pierre Labastie wrote:
Le 14/03/2012 00:34, Bruce Dubbs a écrit :
OK, try the updated scripts I just committed when you get a chance.
-- Bruce
Sorry it took some time because I had a few errors in my kernel config
(like not enabling devtmpfs, shame on me, and a problem with the radeon
Le 19/03/2012 20:18, Bruce Dubbs wrote:
Pierre Labastie wrote:
Also, it might be interesting/necessary to copy the content of /lib/firmware
to $WDIR.
That directory has always been empty for me. What populates it?
I've always thought of that directory to be for specialized video cards.
Pierre Labastie wrote:
Le 19/03/2012 20:18, Bruce Dubbs wrote:
Pierre Labastie wrote:
Also, it might be interesting/necessary to copy the content of
/lib/firmware to $WDIR.
That directory has always been empty for me. What populates it?
I've always thought of that directory to be for
On 03/20/12 01:23, Bruce Dubbs wrote:
So I agree that the mknod commands are not needed. I'll remove them.
-- Bruce
There are similar commands to create these nodes in LFS 6.2.1. Creating
Initial Device Nodes. Perhaps they should be removed from there too?
--
Lemon Lime wrote:
On 03/20/12 01:23, Bruce Dubbs wrote:
So I agree that the mknod commands are not needed. I'll remove them.
-- Bruce
There are similar commands to create these nodes in LFS 6.2.1. Creating
Initial Device Nodes. Perhaps they should be removed from there too?
That
Le 14/03/2012 00:34, Bruce Dubbs a écrit :
OK, try the updated scripts I just committed when you get a chance.
-- Bruce
Still needs the patch below (suppress lsmod from $binfiles,
since it is added later if needed, and the last space for cosmetics:-) ),
but it looks like it almost works (no
Pierre Labastie wrote:
Le 14/03/2012 00:34, Bruce Dubbs a écrit :
OK, try the updated scripts I just committed when you get a chance.
-- Bruce
Still needs the patch below (suppress lsmod from $binfiles,
since it is added later if needed, and the last space for cosmetics:-) ),
but it
Pierre posted a proposed patch to the initramfs instructions in ticket
3298. I'd like to discuss the changes here (not exactly in order).
- if [ $2 == lib ]; then
-file=$(PATH=/lib:/usr/lib type -p $1)
+ if [ $2 = lib ]; then
+file=$(find /lib /usr/lib -maxdepth 1 -name $1 | head -n
Pierre Labastie wrote:
Le 13/03/2012 20:14, Bruce Dubbs a ecrit:
- if [ $2 == lib ]; then
-file=$(PATH=/lib:/usr/lib type -p $1)
+ if [ $2 = lib ]; then
+file=$(find /lib /usr/lib -maxdepth 1 -name $1 | head -n 1)
else
-file=$(type -p $1)
+file=$(find /bin /usr/bin
Pierre Labastie wrote:
Le 13/03/2012 20:14, Bruce Dubbs a ecrit:
- if [ $2 == lib ]; then
-file=$(PATH=/lib:/usr/lib type -p $1)
+ if [ $2 = lib ]; then
+file=$(find /lib /usr/lib -maxdepth 1 -name $1 | head -n 1)
else
-file=$(type -p $1)
+file=$(find /bin /usr/bin
OK, try the updated scripts I just committed when you get a chance.
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
On 2/21/12 11:28 PM, Bruce Dubbs wrote:
$ sh list-libs.sh
ld-linux-x86-64.so.2
libblkid.so.1
libc.so.6
libdl.so.2
libhistory.so.6
libncursesw.so.5
libpthread.so.0
libreadline.so.6
librt.so.1
libuuid.so.1
libz.so.1
Yeah, that looks right at a glance, nice!
JH
--
On Feb 20, 2012, at 6:02 PM, Bruce Dubbs wrote:
For most distros, modules are the biggest reason to have an initramfs --
plus the fact that they want a one size fits all methodology. In a way,
this is the antithesis of LFS where we generally build a custom kernel
and rarely need an
On Tue, Feb 21, 2012 at 12:41 AM, Qrux qrux@gmail.com wrote:
On Feb 20, 2012, at 6:02 PM, Bruce Dubbs wrote:
For most distros, modules are the biggest reason to have an initramfs --
plus the fact that they want a one size fits all methodology. In a way,
this is the antithesis of LFS
Qrux wrote:
On Feb 20, 2012, at 6:02 PM, Bruce Dubbs wrote:
For most distros, modules are the biggest reason to have an
initramfs -- plus the fact that they want a one size fits all
methodology. In a way, this is the antithesis of LFS where we
generally build a custom kernel and rarely
Nathan Coulson wrote:
modules, I personally would want to exclude this so I can upgrade
kernel/initramfs separately on my own build/projects.
That is a very good point.
I feel that for
the BLFS book though, that most people would want to include kernel
modules, and if we are only
Jeremy Huntwork wrote:
As an example, look at this init:
https://github.com/jhuntwork/LightCube-OS/blob/master/packages/mkinitramfs/init.in
Well that's certainly easier than dracut. I would want to add UUID and
LABEL capabilities.
And the script that creates the image:
On 2/21/12 2:49 PM, Bruce Dubbs wrote:
As an example, look at this init:
https://github.com/jhuntwork/LightCube-OS/blob/master/packages/mkinitramfs/init.in
Well that's certainly easier than dracut. I would want to add UUID and
LABEL capabilities.
Actually, the UUID stuff just works the
On 2/21/12 3:03 PM, Jeremy Huntwork wrote:
On 2/21/12 2:49 PM, Bruce Dubbs wrote:
As an example, look at this init:
https://github.com/jhuntwork/LightCube-OS/blob/master/packages/mkinitramfs/init.in
Well that's certainly easier than dracut. I would want to add UUID and
LABEL capabilities.
Jeremy Huntwork wrote:
On 2/21/12 3:03 PM, Jeremy Huntwork wrote:
On 2/21/12 2:49 PM, Bruce Dubbs wrote:
As an example, look at this init:
https://github.com/jhuntwork/LightCube-OS/blob/master/packages/mkinitramfs/init.in
Well that's certainly easier than dracut. I would want to add UUID
On Tuesday 21 February 2012 02:49:20 pm Bruce Dubbs wrote:
Jeremy Huntwork wrote:
As an example, look at this init:
https://github.com/jhuntwork/LightCube-OS/blob/master/packages/mkinitramf
s/init.in
Well that's certainly easier than dracut. I would want to add UUID and
LABEL
Baho Utot wrote:
Where does this leave this
http://www.linuxfromscratch.org/hints/downloads/files/Root_FS_on_RAID+encryption+LVM.txt
It's still there. The initramfs page in the book will probably
reference it.
Note that LVM2 and mdadm are already in the book. I don't think dmraid
is
Jeremy Huntwork wrote:
As an example, look at this init:
https://github.com/jhuntwork/LightCube-OS/blob/master/packages/mkinitramfs/init.in
And the script that creates the image:
https://github.com/jhuntwork/LightCube-OS/blob/master/packages/mkinitramfs/mkinitramfs.orig
Very interesting.
On 2/21/12 8:51 PM, Bruce Dubbs wrote:
I was able to use
menuentry BLFS Dev (LFS-7.0-Feb14) initrd, Linux 3.0.4 {
linux /vmlinuz-3.0.4-lfs-20120214
root=UUID=54b934a9-302d-415e-ac11-4988408eb0a8 ro
initrd /initrd.img-no-kmods
}
and it worked the first time.
Nice!
One interesting thing
On 2/21/12 8:51 PM, Bruce Dubbs wrote:
Very interesting. I took your scripts and hacked them a bit. I set it up
Oh, one other thing that I was going to do at some point but also hadn't
gotten around to yet was to pull in the required dynamic libs, well,
dynamically. Perhaps parse output from
Jeremy Huntwork wrote:
On 2/21/12 8:51 PM, Bruce Dubbs wrote:
Very interesting. I took your scripts and hacked them a bit. I set it up
Oh, one other thing that I was going to do at some point but also hadn't
gotten around to yet was to pull in the required dynamic libs, well,
dynamically.
I've been studying the initramfs structure for inclusion in BLFS, mostly
by looking at the dracut scripts. This is what happens:
The initfamfs is a complete set of directories that you would find on a
normal root filesystem. It is bundled into a single cpio archive and
compressed with one of
29 matches
Mail list logo
