On Jan 24, 2012, at 7:49 PM, Bryan Kadzban wrote:
Why? Can't you mount the devtmpfs both with and without the
initramfs?
Not if it's already mounted, unless you want to undo the modifications
that udev has made (by putting a new mount on top), or make changes to
the bootscripts (which is
On Jan 25, 2012, at 10:23 AM, Bruce Dubbs wrote:
I'm sure that systemd solves a problem for 1% of users, but for 99%,
it's not needed. I recently installed Fedora 16 on a virtual system
with exactly one partition. The listing below is what I got for a
simple 'mount' command.
Your
On Jan 25, 2012, at 9:15 PM, Bryan Kadzban wrote:
And give up LVM? udev is the only thing that creates /dev/vg/lv
symlinks now; vgcreate does not touch /dev. (The LVM2 package installs
a few udev rules to create the links for you. The underlying devmapper
node remains at /dev/dm-X, but
On Jan 25, 2012, at 9:22 PM, Bryan Kadzban wrote:
That's just a *tiny* bit excessive I think.
Now maybe this can all be disabled, but it seems that for something as
core to the system as init, it'd be better to disable esoteric bits of
it by default, not enable them by default.
I think
On Jan 24, 2012, at 10:01 AM, Gerard Beekmans wrote:
If it wasn't entirely clear from other posts, Grub can also use those
same UUIDs for its 'linux', 'linuxrd' and 'root' options. I'm not sure
off the top of my head if it supports labels. I've always used the UUIDs
because every
On Jan 23, 2012, at 7:56 PM, Bryan Kadzban wrote:
UGH. FWIW I really don't like this feature.
It causes the booted-with-initramfs case to require different handling
from the booted-without-initramfs case, once the bootscripts are
running, and therefore requires changes to the bootscripts
On Jan 23, 2012, at 7:56 PM, Bryan Kadzban wrote:
Don't you still need udevd if you want to find the rootfs based on
config stored in /etc/fstab, and you want to support all the (somewhat
exotic) options for that, like /dev/disk/by-{id,uuid,label,path}?
You can't find the rootfs based on
On Jan 22, 2012, at 7:33 PM, Steve Crosby wrote:
3. Populate /dev using busybox cutdown version of udev (mdev)
Is there a benefit to mdev over just using tmpdevfs?
I say that as a current user of mdev; I haven't yet tried a tmpdevfs initramfs
device system. But if I'm understanding it
On Jan 22, 2012, at 9:05 PM, Bruce Dubbs wrote:
The times I have had problems have been when grub can't load the kernel
and if I can load the kernel I can always edit the command line in grub
to use init=/bin/bash.
Only if the kernel can mount the root file system as-is. Given an
On Jan 18, 2012, at 9:25 PM, Bryan Kadzban wrote:
You just need to ensure vgchange can find the PV(s) when you run it at boot
time; it doesn't use the info in the partition table to do that. :-)
In fact it doesn't need partitions at all -- you can just use the raw device.
RAID: fdisk
On Jan 16, 2012, at 11:01 AM, Jeremy Huntwork wrote:
Interesting. I wonder if this is a side effect my using an initramfs. I
assume you have a monolithic kernel and you are using root= on the grub boot
line?
It is. When the system boots always mounts the rootfs device. If you use
On Jan 16, 2012, at 1:15 PM, Steve Crosby wrote:
Not *required* but systemd will issue a warning on boot if /etc/mtab
is not a symlink to /proc/mounts
I'm pretty sure this is actually required if you use systemd's internal mount
facilities -- it does not manage mtab and the file will be
On Jan 14, 2012, at 7:53 PM, Bruce Dubbs wrote:
On the other hand, setting up a initramfs may require a lot more. There
have been mentions of RAID, encrypted filesystems, LVM, and networked
FS. We could leave something out, but some have said they want
something that will work anywhere.
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
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 kernel
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
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.
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 to
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 elsewhere.
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
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 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
On Jan 12, 2012, at 10:50 PM, Nathan Coulson wrote:
initrd/initramfs always felt more useful for systems that need to
setup an environment before mounting root. Fun to learn, but not
something I would want for my own system. I know we were saying that
udev is expecting the environment
On Jan 13, 2012, at 8:27 AM, Matt Burgess wrote:
I like the idea behind systemd, inasmuch as they are trying to speed
booting up by using dependencies to allow scripts to run in parallel
rather than Sysvinit's serial boot ordering.
Parallelization and the related speed is one of the
On Jan 13, 2012, at 11:09 AM, Nathan Coulson wrote:
If we do support it, I would also like an option for initramless setups as
well.
To what end? I don't mean to be argumentative, but I really don't see why
people see a non-initramfs boot as an important or useful goal. What
On Jan 13, 2012, at 11:27 AM, Kevin Lyda wrote:
I assume that if you're using LFS to build an embedded system (I did
that a long time ago), you want to reduce boot times.
To me an embedded system seems like the perfect use of an initramfs -- boot
directly from a ram-loaded image and never
On Jan 13, 2012, at 11:45 AM, Nathan Coulson wrote:
To what end? I don't mean to be argumentative, but I really don't see why
people see a non-initramfs boot as an important or useful goal. What
features/benefits does it provide, other than you don't have to run cpio one
time when
On Jan 13, 2012, at 12:32 PM, Nathan Coulson wrote:
I still like the idea, that it adds to lfs, as opposed to being
required though. (And by that, I mean leave assumptions out of the
bootscripts that this was booted on a initramfs/initrd)
I think that's a good design in general, even if
On Jan 13, 2012, at 10:43 PM, Jeremy Huntwork wrote:
For most LFS uses, you're building the entire system for one machine and in
that case, an initramfs or early boot options like it aren't really that
crucial, because you're likely to build just the drivers you need into the
kernel
On Sep 5, 2011, at 2:13 AM, DJ Lucas wrote:
I'm not really sure what to do about actual IPv6 entries as your prefix
will likely change when your router is rebooted unless ISPs start
handing out static /64s (the last 64 bits are stable as they are
assembled from the MAC address with FFFE
On Jul 7, 2011, at 4:28 PM, Nathan Coulson wrote:
speaking of, I never dug into ipv6 yet, wonder what it's going to require.
Just FYI on IPv6:
For static assignments `ip` usage is identical to IPv4, just with a different
address format:
ip addr add dev eth0 1:1:1:1:2:2:2:2/64
On Jul 7, 2011, at 10:05 PM, Bryan Kadzban wrote:
Zachary Kotlarek wrote:
I haven't ever found a use for a DHCPv6 client,
Dynamic DNS: having the DHCP server update the DNS server
I can see that. I moved to mdns for such things well before I added IPv6 to my
network, so I've never cared
On May 16, 2011, at 12:49 AM, Bryan Kadzban wrote:
I also *think* the only way the cached config might not match the
running config is if root mucked with the running config manually.
Or when /run is not writable at the time the network scripts execute. Or if the
cached config were lost for
On May 15, 2011, at 2:25 AM, DJ Lucas wrote:
might actually be easier to provide a default IFCONFIG values
in each service script, and walk /lib/network-services.
This make sense to me -- then it's easy to extend the same approach for
arbitrary service types -- say pppoe -- which might
On May 15, 2011, at 12:31 PM, Bryan Kadzban wrote:
I'm trying to figure out why it'd be necessary to do this. We already
have the previous configuration of every interface stuffed away in /run,
and we use that when deciding which service scripts to call when
bringing down networking.
On May 14, 2011, at 11:36 PM, DJ Lucas wrote:
I'll need to setup both DHCP clients to test functionality for this,
which is why I didn't just do it tonight. The problem I want to avoid is
if we do a flush, but the client daemon is still running, come
expiration, the client daemon might
On May 8, 2011, at 7:46 PM, Bryan Kadzban wrote:
I do think putting the service scripts under a subdirectory /lib is
good, but maybe /lib/network-services or something (to be more explicit)
would be better than plain services.
As long as the scripts are 100% parameterized so that any
On Feb 19, 2010, at 7:52 AM, Matthew Burgess wrote:
Being a speaker of British English rather than US English I would
actually say maths libraries rather than math libraries. I've never
quite understood why Americans drop the 's'. The word being contracted is
'mathematics' (plural) and by
On Oct 29, 2009, at 11:37 AM, Bryan Kadzban wrote:
Again, this is all related to mounting the rootfs. GRUB2 does
simplify
a lot of setups that still require an initramfs, so that they don't
need
a separate (non-LVM, sometimes even non-RAID) /boot partition.
I saw that and thought it
On Oct 27, 2009, at 11:08 AM, Bryan Kadzban wrote:
Actually, you don't need it for that, either. Mostly because the
format
of the cpio archive that the kernel expands is rather simple, and
because the kernel includes code to build this already.
The kernel make system includes the ability
On Oct 27, 2009, at 12:16 AM, Bryan Kadzban wrote:
cpio, no. Nothing uses it except rpm (and see above about that one).
I've added cpio to my standard install, for use in the construction
and editing of initramfs images. Other than that I agree, it's mostly
for RPM users.
On Dec 6, 2008, at 12:03 AM, Jim Gifford wrote:
David Miller constantly gets on his soapbox about this
on the Sparc Realm of linux.
I don't disagree per se -- I've given up on pure64 for desktop builds
for the moment -- but to be fair x86 has a lot more to gain running
standard apps in
On Dec 5, 2008, at 6:56 PM, Ken Moffat wrote:
Last time this was discussed, the general view seemed to be that
pure64 was a step far enough. Care to remind me what the advantages
of multilib builds are ? I'm looking at the whole system here,
most of which is in BLFS (or, for existing
On Nov 13, 2008, at 12:44 AM, TheOldFellow wrote:
Following this logic, we should document:
#define VERSION 2.8-20080929-LFS-svn20081101-built-by-John-Doe
since we can't control how it was really built. It's for this reason,
lack of control of the build options, that we MUST not call LFS a
On Oct 7, 2008, at 5:41 PM, Randy McMurchy wrote:
To this day, using my most modern systems which include Udev/D-Bus/Hal
and all other recent additions, after creating a new partition, I have
to reboot to see it in order to create a filesystem. Just FYI.
When I write in fdisk I always get:
On Jun 22, 2008, at 10:05 AM, Alexander E. Patrakov wrote:
The problem is that iproute2 wraps its traffic counters at 4GB
(i.e., uses
32-bit counters), while the old ifconfig command from net-tools
doesn't.
Unwrapped (64-bit) counters are, obviously, available from /proc/net/
dev. So,
is
On May 30, 2008, at 6:02 AM, Randy McMurchy wrote:
Zachary Kotlarek wrote these words on 05/29/08 20:24 CST:
http://zinux.cynicbytrade.com/svn/devel/dhcp/iproute2.diff
I'm not sure this patch qualifies as an LFS patch. Patches in LFS
are used to fix something that is broken
On May 26, 2008, at 11:42 AM, Dan Nicholson wrote:
On Mon, May 26, 2008 at 8:39 AM, DJ Lucas [EMAIL PROTECTED]
wrote:
DHCP-4.0.0 is out too and the iproute2 patch will have to be
updated (or reintroduce net-tools).
Someone should really try to upstream the iproute2 patch. Every distro
On May 29, 2008, at 8:24 PM, Zachary Kotlarek wrote:
Now with a trailing newline, so the link is reasonable:
http://zinux.cynicbytrade.com/svn/devel/dhcp/iproute2.diff
Zach
smime.p7s
Description: S/MIME cryptographic signature
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
On May 22, 2008, at 12:57 AM, Bruce Dubbs wrote:
In the situation with a remote system, I don't think dhcp is ever an
option.
You need to know what the IP address is to log in and you wouldn't
know that for
sure before a reboot. Catch 22.
You people and your randomly-assigned IP
On May 9, 2008, at 5:05 PM, Dan Nicholson wrote:
I haven't piped in on this at all, but I'd just like to say that I
really, really want to be pro-grub2. I periodically peruse the
grub-devel archives hoping to see that a 2.0 release is imminent. I
find it ridiculous that there's no currently
On Mar 19, 2008, at 1:52 PM, J. Greenlees wrote:
With the LSB:
Why would a BASE standrd not stop at the absolute minimum needed for a
functioning system? The addition of package management [ for example ]
to the LSB has made in no longer a BASE standard. If extras are
going to
be included,
On Jun 8, 2007, at 8:59 AM, Dan Nicholson wrote:
On 6/8/07, Andrew Beverley [EMAIL PROTECTED] wrote:
I agree with Andy here. Regardless of the reason for alias/label, if
it's used in iproute2, we should expose the functionality. This page I
found on linux-ip.net seems to promote using labels
On Jun 6, 2007, at 6:34 PM, Bryan Kadzban wrote:
I suspect the alias option exists in ip for compatibility with
ifconfig,
and no other reason. But I don't know that for sure.
I believe that's correct. In the past the kernel supported aliases
with independent statistics and the like, but
On Aug 20, 2006, at 1:10 PM, Dennis J Perkins wrote:
So I think the project needs a challenge. Trouble is I can't
think what
it is!
Yep, and that's why I can both understand Randy's and the community's
concerns about the lack of activity, but then wonder what activity
it is
they'd
On Nov 1, 2005, at 6:06 AM, Bryan Kadzban wrote:
But that's not the only way of doing an initramfs. You can also
create
a control file that refers to the files on your system, in their
current
directories, and when you make the kernel, it'll pull the files from
wherever they currently are
On Oct 31, 2005, at 5:59 PM, Bryan Kadzban wrote:
What I'm wondering is, for anyone that doesn't think an initramfs
is good, why do you think that?
For all the reasons you listed below -- with an initrd I'd need to
maintain a whole set of binaries and libraries in a file systems that
On Sep 5, 2005, at 7:33 AM, Archaic wrote:
In the good ol' days, one could merely have an ifconfig eth0:{1,2,3}
etc. to alias as many addresses as one desired. Then we switched to
iproute2 and that broke. According to man ip we need a way to add a
LABEL=something to the ifconfig files so we
On Aug 22, 2005, at 12:33 PM, Jason Gurtz wrote:
Certainly raw sockets would be a huge risk, but I don't see how
echo_reply
at a 1 per second rate or something is a problem.
Except you'd have to add a kernel interface just to send ICMP echo
requests, along with whatever options you want
59 matches
Mail list logo
