Re: [lfs-support] lsmod return nothing
On Sat, 2014-03-22 at 22:22 +0900, 包乾 wrote: thanks for your reply! I recompile the kernel, actually I copied the kernel source from my host system(slackware) and everything works fine now! So the problem narrowed down to my kernel configuration, I would continue dig into that. ThX! I confess, I always use the kernel options from Fedora as a starting point, using vanilla kernel source but using make oldconfig. From there I remove stuff I know I don't need. It results in more modules and options than I probably do need, but it is easier than trying to figure out everything I do need. And once I have a working kernel configuration I am happy with, I just use that with the next kernel update. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] CLFS
On Wed, 2014-02-19 at 05:51 -0500, Chris Staub wrote: On 02/19/14 05:46, loki wrote: Heya, just wanted to ask what happened to CLFS? On the address http://www.cross-lfs.org/ I'm getting a Domain for Sale. Regards, Daniel Nothing happened to it, it's where it's always been, at trac.cross-lfs.org. I get domain for sale there as well, and indication it has expired. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] ABOUT LFS
On Sun, 2013-09-08 at 03:44 +0100, Ken Moffat wrote: For a safer system, limiting privileges is a good idea. To shut down a *desktop* box, I'm happy using a hack to let a user run 'shutdown' - but I'm the only user of those machines, and I can only run the user shutdown script from a tty (not an xterm, nor when using ssh to connect to a system). Some other people use 'sudo' and allow (some) normal users to shutdown, others run desktop environments where ConsoleKit gives permissions to whoever is at the physical machine. Every alternative method has its own advantages an disadvantages. I've seen ways of tricking ConsoleKit before, I just use whatever my distro uses as they fix known vulnerabilities with the method they offer - and for my LFS system, this is probably not the best solution but I just have a cron job running as root once a minute that looks for /tmp/shutdown and /tmp/reboot - and then executes the appropriate command if either exist. That means anyone who has write access to /tmp can shutdown or reboot but I'm the only user. That way though I don't have to either use sudo (I dis-like sudo) or su to root. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] Kernel configuration
On Tue, 2013-06-11 at 20:05 -0800, John Black wrote: I'm confused about kernel configuration. What about I leave it by default then compile it, it is fine for creating live cd at later time? ___ I would look at some of the kernel configurations from mainline distributions. In fact, the kernel config I currently use for LFS started as a Fedora kernel config. I turned off some things I obviously did not need but if I didn't know, I left it. Result is it takes longer to compile than a very basic kernel config but I don't compile a kernel that often, maybe every other point release unless there's a security flaw that I'm vulnerable to. As far as live CD/DVD goes, most boards these days support booting from USB and you can make a boo-table thumb drive that is more useful since it has more space. Look into that if you can and see if it fits your needs. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] why does LFS need that number of patches
On 5/16/2013 12:03 AM, Stefan Rebekka Wetter wrote: Hi, in the lfs-book you need some patches. I wonder, why these patches are needed? Are the upstream-sources not able to be compiled without? Thanks! Best Regards Stefan The number of patches in LFS is very small compared to the number of patches in any Linux distribution I have ever used. Any software project has bugs. It is hard to catch some bugs before release because the software is not yet in wide use so certain issues have not been found during the test phase. Sometimes upstream makes assumptions in the build process about building on a complete Linux install rather than a minimal bootstrap build. Sometimes changes in a library a package links against requires patches in the package. At least once the build process is done and you can boot into the system, most software that uses an autoconf system can be easily built without applying patches, but when a patch resolves an issue then often it is better to apply the patch than not to. When issues are reported to upstream they usually don't make a new release right away, there are often more than one way to solve a problem and patches frequently are used until a new release is made when upstream has decided how they want to officially resolve the issue. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] why does LFS need that number of patches
On 5/16/2013 1:04 PM, Bruce Dubbs wrote: *snip* Finally, there are philosophically no differences between a sed and a patch. Both have the same purpose--to enhance the user experience. We prefer using a sed because the changes made is more visible. -- Bruce I prefer sed for minor changes that don't really affect how the program operates but maybe fix a build (or sometimes just make install) issue and patches for bug fixes that are a result of coding bugs. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] why does LFS need that number of patches
On 5/16/2013 2:08 PM, alex lupu wrote: BTW, a patch is mostly in the eye of the beholder; some call many of them, sed. Cute, I like it. Submitting sed scripts upstream though seems to be frowned upon, they like patches. I agree with the concept of minimal patches. I think over-patching creates problems. When I RPM bootstrapped my LFS, I wrote most of my spec files in Fedora 18 so I could do things like run rpmlint on the result and get it right before building in LFS. The bash spec file consistently builds in LFS but in Fedora 18 on same machine, about 20% of the time it fails, something weird about Fedora must result in a race condition that doesn't exist in my LFS and I'm guessing it is related to the large amount of patches Fedora has, many of which only make sense for enterprise and not a typical system. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] /usr/libexec
On Sat, 2013-04-20 at 21:59 +1200, Simon Geard wrote:
On Fri, 2013-04-19 at 17:54 +0100, Ken Moffat wrote:
LFS doesn't use it. BLFS depends on who edited the page, and when.
We used not to use it, but then some of us were persuaded that it
would be in the new standard. Me, I like it, others don't. Your
system, your rules.
My personal inclination is to just go with the default. Sure, I can add
an extra flag to ./configure to put those libexecdir files somewhere
else, but well... why bother?
Simon.
Well, if it were up to, platform specific binary blob libs would
go /usr/lib{32,64} and platform neutral - including what is often put in
libexec - would go into /usr/lib - thus no longer having a case
for /usr/libexec.
If 32 bit libraries are going into /usr/lib though then you have cases
where package foo may want a /usr/lib/foo directory for actual libraries
and a /usr/libexec/foo directory. Especially if multiple versions are
installed, to avoid filename conflicts you could have either
/usr/{include,lib{,32},libexec}/fooN or
/usr/{include,lib{32,64},lib}/fooN
I prefer the latter, Fedora does the former - but for stuff like
perl/python modules, since they use /usr/{lib,64} for platform specific
they can't easily use /usr/lib for platform neutral but platform neutral
modules also aren't really libexec stuff either, so they put them
into /usr/share which to me seems almost equally absurd.
But using /usr/lib for libexec needs and platform independent libraries
makes sense to me. But I just go with the flow with whatever the distro
maintainers do, it's not that big of a deal to me.
Sorry for rambling beyond the scope of support.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
[lfs-support] /usr/libexec
Hi, Am I correctly understanding that the filesystem philosophy of LFS/BLFS is to not use /usr/libexec ?? I don't need an explanation as to why, I just want to know if that's what has been adopted or not. Thanks -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] /usr/libexec
On Fri, 2013-04-19 at 06:00 +0200, Armin K. wrote: On 04/19/2013 05:10 AM, Alice Wonder wrote: Hi, Am I correctly understanding that the filesystem philosophy of LFS/BLFS is to not use /usr/libexec ?? I don't need an explanation as to why, I just want to know if that's what has been adopted or not. Thanks It's not yet part of the standard and it looks that only Fedora and maybe SUSE uses it yet by default. Arch, Debian/Ubuntu don't (Don't know about Gentoo). I don't like it and don't agree with it, so it is being avoided. There was an agreement that we shouldn't avoid it, but as it never was made part of the standard, I started avoiding it. Thanks. I don't have an opinion, other than that I'm not sure why a separate directory is needed. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] uname unknown
Hi, lfs 7.3 uname -i and uname -p both return unknown which is causing some issues on software I'm trying to build. On other distributions - that return x86_64 uname -m however does return x86_64 What went wrong in my build of coreutils? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] uname unknown
On Wed, 2013-04-10 at 17:15 -0500, William Harrington wrote: *snip* What went wrong in my build of coreutils? This has been reported a bug a while ago: http://lists.gnu.org/archive/html/bug-coreutils/2012-11/msg00172.html Sincerely, William Harrington Ah, thanks, OK - so reading that thread this looks like a case where the proper thing to do is fix the configure script of the package giving a problem, not patch coreutils - since it is an OS thing. e.g. on linux, use uname -m because other options are meaningless. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] eth0 doesnt exist
On Tue, 2013-04-09 at 18:18 -0430, Gabriel Formica wrote: Hello, I just booted up into my linux from scratch. It seems to be ok, but I'm having some troubles with the network interface. When my linux from scratch begins, it shows: Bringing up the eth0 interface Adding IPv4 address (the ip) to the eth0 interface cannot find device eth0 *** ***face eth0 doesn't exist I followed the 7.3 version of the linux from scratch's book. I loaded the module tg3 (this is the module of my ethenet card) as a module (not as a biltuin-in) when compiling the kernel. Udev is loading the kernel automatically My linux from scratch system is x86_64 My host system is debian x86_64 When using the dmesg | grep tg3 I get tg3.c:v3.128 libphy: tg3 mdio bus: probed tg3 :02:00.0 no phy devices tg3 :02:00.0: problem fetching invariants of chip, aborintg Thanks in advance for your help! I don't know if this will help or not, but when I built 7.3 using Fedora 18 as a host, cat /etc/udev/rules.d/70-persistent-net.rules did not show my Ethernet device, though it did show wlan0 I configured /etc/sysconfig/ifconfig.eth0 anyway - though I told it not to come at boot, I've not attached it to a network yet. I got same message as you did. Inside the fresh LFS 7.3 - I rebuild LFS 7.3 again. In the LFS built by LFS - 70-persistent-net.rules now showed the Ethernet device, but it called it emo1 and not eth0 So I set up the device calling it emo1 instead of eth0 and while I still have not made an Ethernet connection, booting the LFS built inside LFS does not give me any errors. Anyway, my suggestion is to modify /etc/sysconfig/ifconfig.eth0 change IFACE=eth0 to IFACE=emo1 and rename the file to /etc/sysconfig/ifconfig.emo1 Interestingly, Fedora 18 calls the device em1 So it may be a 3.8.x kernel thing changing the device name that the LFS book didn't reflect. But I haven't made a connection yet so I really don't know. -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
[lfs-support] grub, LFS7.3, Fedora 18
Going through LFS 7.3 and about ready to make it bootable but Fedora's grub is giving me issue. The plan was to share /boot between LFS and Fedora 18 as I have done in the past (been awhile since I ran LFS - LFS 4.something last time I think). Hell, I've shared /boot between Fedora, CentOS, Ubuntu, and LFS. That was grub 1 and it was easy because /etc/grub was a symlink to /boot/grub - but it seems grub2 is not so KISS (or maybe it's just Fedora's butchering of grub2 ??). First problem - Fedora does not use /boot/grub - it uses /boot/grub2 but LFS (with grub2) uses /boot/grub Second problem - Fedora /boot/grub2/grub.cfg says not to hand edit it, which gives me the impression that if I do hand edit it, a Fedora kernel update is likely to wipe it. It says to modify files in /etc/grub.d - but Fedora's /etc/grub.d is only available when Fedora is booted, so when booted into other distros (like LFS) it won't be available. The solution I believe is to create a /boot for LFS on it's hard drive (I have separate physical disk, but this makes me sad - would be nice for people with one HDD to be able to do this) and have a Fedora grub entry that tells its grub to load the LFS /boot on sdd - kind of like grub can load a Windows boot loader. How do I do this? -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] grub, LFS7.3, Fedora 18
On Mon, 2013-04-08 at 16:50 -0500, Bruce Dubbs wrote:
*snip*
Every distro wants to do their own thing. Most will automatically
change from what you have to their custom eye candy.
You really have a couple of choices. One choice is to install grub2 per
the LFS instructions. Then edit the /boot/grub/grub.cfg file to
manually add menuentries for any other desired entries. This bypasses
the eye candy and shortens up the grub.cfg.
My .cfg only has a few lines before the menuentries:
set default=0
set timeout=5
insmod ext2
set root=(hd0,1)
The menuentries for other distros really only need:
menuentry Some descriptive title {
linux kernel kernel-options
initrd initrd-image
}
Note that this is a lot faster too.
Specifying where the kernel and initrd are located depends on your
setup. If you or a distro have used a separate partition for /boot,
then it's just /kernel-name. If it's on a partition, then it may be
something like (hd0,7)/boot/kernel-name
The only drawback to this is if you get a new distro or install an
update to the kernel in a distro, it will probably try to reinstall grub
the way it wants to instead of the way you want to.
The other option is to use the distro that controls grub to find your
LFS kernel and hope it adds it correctly for you. The last time I ran
grub-mkconfig (which is what the distros do), I had about 48 entries.
Over 30 of the entries were nonsense. You still need to edit the file
after that, IMO. The .cfg file name may also change. As you note, they
name it /boot/grub/grub2.cfg, but it needs to be the one on the
partition that fedora recognizes as /boot. That's the file that needs
to be edited if you let them control.
The solution to distros overwriting your grub.cfg is to keep a backup.
-- Bruce
Thanks. I'm about to try a boot, will see how it goes.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Re: [lfs-support] grub, LFS7.3, Fedora 18
On Mon, 2013-04-08 at 14:58 -0700, Alice Wonder wrote:
On Mon, 2013-04-08 at 16:50 -0500, Bruce Dubbs wrote:
*snip*
Every distro wants to do their own thing. Most will automatically
change from what you have to their custom eye candy.
You really have a couple of choices. One choice is to install grub2 per
the LFS instructions. Then edit the /boot/grub/grub.cfg file to
manually add menuentries for any other desired entries. This bypasses
the eye candy and shortens up the grub.cfg.
My .cfg only has a few lines before the menuentries:
set default=0
set timeout=5
insmod ext2
set root=(hd0,1)
The menuentries for other distros really only need:
menuentry Some descriptive title {
linux kernel kernel-options
initrd initrd-image
}
Note that this is a lot faster too.
Specifying where the kernel and initrd are located depends on your
setup. If you or a distro have used a separate partition for /boot,
then it's just /kernel-name. If it's on a partition, then it may be
something like (hd0,7)/boot/kernel-name
The only drawback to this is if you get a new distro or install an
update to the kernel in a distro, it will probably try to reinstall grub
the way it wants to instead of the way you want to.
The other option is to use the distro that controls grub to find your
LFS kernel and hope it adds it correctly for you. The last time I ran
grub-mkconfig (which is what the distros do), I had about 48 entries.
Over 30 of the entries were nonsense. You still need to edit the file
after that, IMO. The .cfg file name may also change. As you note, they
name it /boot/grub/grub2.cfg, but it needs to be the one on the
partition that fedora recognizes as /boot. That's the file that needs
to be edited if you let them control.
The solution to distros overwriting your grub.cfg is to keep a backup.
-- Bruce
Thanks. I'm about to try a boot, will see how it goes.
Got the frame buffer with the penguins on top (haven't seen that since
booting on PowerPC LOL) but it did not fully boot, I'm going to try
using the fedora kernel config and if that doesn't work investigate
further.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
[lfs-support] 7.3 book 7.2.1 - network interfaces
Build Host: Fedora 18 64-bit Hardware: Home Built, Asus P8Z68-V Pro/Gen3 It has on-board ethernet and a wireless PCI card I installed. I've never tested the onboard ethernet but it is seen by Fedora, though noted Cable Unplugged. That is going to be the normal connection. When I cat the udev 70-persistent-net.rules - only the wlan0 interface is there, there is not an ethernet device there. Is that just because there is not a cable detected or is there a problem? Thanks for suggestions -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 7.3 book 7.2.1 - network interfaces
On Sun, 2013-04-07 at 01:51 -0700, Alice Wonder wrote: Build Host: Fedora 18 64-bit Hardware: Home Built, Asus P8Z68-V Pro/Gen3 It has on-board ethernet and a wireless PCI card I installed. I've never tested the onboard ethernet but it is seen by Fedora, though noted Cable Unplugged. That is going to be the normal connection. When I cat the udev 70-persistent-net.rules - only the wlan0 interface is there, there is not an ethernet device there. Is that just because there is not a cable detected or is there a problem? Thanks for suggestions Doh! Fedora lspci shows it as: Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 05) -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
Re: [lfs-support] 7.3 book 7.2.1 - network interfaces
On Sun, 2013-04-07 at 11:31 +0200, Niels Terp wrote: *snip* Hi Alice, Have you followed the section 7.3. Customizing the /etc/hosts File ? You will need to set up a 'hosts' file where you list the parameters for your card(s). Here is a copy of mine, hope that can give you an idea how to make this: # Begin /etc/hosts (network card version) 127.0.0.1 localhost localhost 192.168.0.100 lfs.example.org lfs # End /etc/hosts (network card version) Note that you wil have to assgn a static IP address at this point, since you have not installed DHCP (that will come in BLFS) Niels Hi, I have not done that yet, what worries me is that only the wireless interface shows up in the generated 70-persistent-net.rules file. I'd rather not try to set that up as the LFS interface, I'd rather use the Ethernet but there isn't an eth0 in the 70-persistent-net.rules file. Thanks, Alice -- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
