Gerard Beekmans wrote:
> 1) Simplifying too much does not illustrate what has become a very
> common setup on almost every system you encounter these days. The idea
> of LFS has always been to educate as to what is going on. If a just
> finished LFS system can't begin to explain how a regular d
On Jan 14, 2012, at 3:58 PM, William Tracy wrote:
> My 2 cents, FWIW: Cover initramfs in BLFS, and include an explicit reference
> to that section early in the LFS chapter on the kernel.
I think that makes sense. I'd personally go for full integration, but so long
as users are made aware of t
Matt Burgess wrote:
> This passes a boot test with no changes required to the bootscripts
> or fstab. Maybe I'm misunderstanding Bruce's and Bryan's comments in
> the ticket, but this to me suggests that Udev >= 176 doesn't require
> a devtmpfs mounted on /dev
That's very strange, given this comm
On Sat, Jan 14, 2012 at 9:49 AM, Gerard Beekmans <
ger...@linuxfromscratch.org> wrote:
> One of the downsides with putting those things in BLFS is that people
> then find out about them too late. If you want to setup a system with
> initramfs and LVM configurations, that needs to be done early on
Matt Burgess wrote:
> Hi all,
>
> Seeing as I assigned ticket #1998 (Udev-177) to myself before I realised
> that it wasn't as simple a package upgrade as usual, I thought I'd take
> a stab at getting LFS to work with it. Attached is the patch I'm about
> to do a full build with, but the instruct
Hi all,
Seeing as I assigned ticket #1998 (Udev-177) to myself before I realised
that it wasn't as simple a package upgrade as usual, I thought I'd take
a stab at getting LFS to work with it. Attached is the patch I'm about
to do a full build with, but the instructions there seem to work fine on
On Jan 14, 2012, at 11:18 AM, Ken Moffat wrote:
> We (both LFS and BLFS) have many different sorts of users. I'd
> assumed that people building a new LFS system (apart from those
> building for the first time) generally knew what they wanted to
> build, although they will probably try some newer
On Jan 14, 2012, at 11:18 AM, Ken Moffat wrote:
> Surely it depends who you take your recommendations from ?
I was taking that recommendation from the kernel documentation and code.
Initramfs *is* the default boot method in all kernels since 2.6.pretty_early,
as a matter of code. And the docum
On Sat, Jan 14, 2012 at 10:09:56AM -0800, Zachary Kotlarek wrote:
>
> Certainly it's something you can do after building LFS, though if you are
> trying to install on an LVM partition or the like you'll need it before the
> first reboot; I don't know how other people think about BLFS, but I gene
On Jan 14, 2012, at 9:49 AM, Gerard Beekmans wrote:
> A compromise solution would be to still do a write-up about the various
> options in the LFS book. Explain what it's all about, the pros and cons
> but if it's decided to be out of LFS' scope then refer to the
> appropriate sections elsewhe
On Jan 14, 2012, at 5:14 AM, Andrew Benton wrote:
> I think that initramfs/LVM sounds very interesting but I don't think it
> should go in LFS (at least, not straight away). Perhaps a section of
> BLFS could be made describing what is needed?
You could probably wedge it into BLFS. You may need
On 14/01/2012 07:14, Andrew Benton wrote:
> On Sat, 14 Jan 2012 01:22:45 -0800
> Zachary Kotlarek wrote:
>
>> But yes, if you want to do a modules-only build you do need to rebuild the
>> initramfs when you change kernels. Or at least the /lib/modules bit of it.
>> My point was just that, since
On Thu, 12 Jan 2012 15:32:49 -0600
Bruce Dubbs wrote:
> udev is dropping support of module-init-tools for a new package called
> kmod.
It seems that kmod is required for udev-177:
checking for KMOD... no
configure: error: Package requirements (libkmod >= 3) were not met:
No package 'libkmod'
On Sat, 14 Jan 2012 01:22:45 -0800
Zachary Kotlarek wrote:
> But yes, if you want to do a modules-only build you do need to rebuild the
> initramfs when you change kernels. Or at least the /lib/modules bit of it. My
> point was just that, since the current direct-boot method is "you must be
>
On Jan 14, 2012, at 12:27 AM, Bryan Kadzban wrote:
> You still need an initramfs to get the rootfs mounted;
> grub2 will not do that for you. (The kernel won't let it.) And the
> kernel doesn't handle rootfs-on-LVM on its own.
You're right of course. I didn't even think that far through it. W
On Jan 14, 2012, at 12:27 AM, Bryan Kadzban wrote:
> That text-format description is *much* easier for me to debug when I'm
> seeing issues with it, than even a shell script that builds a directory
> tree and runs cpio against it. (And certainly easier to debug than a
> binary that builds a dire
On Jan 14, 2012, at 12:27 AM, Bryan Kadzban wrote:
> It'll still need to be rebuilt with each kernel, though? Perhaps not if
> you don't include any modules in the image, *and* you build all the
> stuff into the kernel that's required for the rootfs. Hmm. That feels
> like a very specific kern
On Jan 14, 2012, at 12:27 AM, Bryan Kadzban wrote:
> grub doesn't care about the rootfs, it only looks for the kernel image
> and (if configured) an initramfs file. :-)
GRUB also cares about all its module files, which are now much to big to stash
in 512 bytes. You don't need them for all con
[Replying to a whole bunch of messages here...]
Nathan Coulson wrote:
> /usr on a seperate partition: In the past when I was more involved
> in the bootscripts, I setup my system to ensure this feature worked
> for the sole reason that it is part of the standard. I felt that if
> there was n
On 2012-01-11 02:14, Andrew Benton wrote:
>> FWIW: libnl-3.2.3 proved quite an interesting 'change', I've needed to
>> tweak several packages (hostapd to name one) to deal with the move of
>> header files :-(
>
> Could you tell me how you built hostapd with libnl-3.2.3? I've just
> taken the easy
20 matches
Mail list logo
