Re: Handling the change from the temp phase to the final target phase
I think that purity and other axioms that are put forward at the beginning of the build process are only as valuable as the benefits they provide later on. If purity means stability, reliability or more fried bananas at the end of the day, that's more important than the philosophical value of a pure LFS system. I wouldn't be offended if a LFS package maintainer said get the binaries from the distributor if it makes my system more stable. In other words, if you promise a good stable system, people will be willing to jump through whatever hoops you tell them to. On that note, the most valuable tool to build a LFS system is a good LFS live cd. I do have some suggestions to put forward but I'm unsure if this is the right place to put them. Best, Hugo -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Hugo Bernier wrote: On that note, the most valuable tool to build a LFS system is a good LFS live cd. I do have some suggestions to put forward but I'm unsure if this is the right place to put them. There is in fact a LFS livecd project, and it has its own mailing list: http://linuxfromscratch.org/mailman/listinfo/livecd -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Archaic wrote: On Thu, May 26, 2005 at 01:44:10PM -0700, Jim Gifford wrote: What about when you build on x86 for a different platform then chroot is not an option at all. That's the reason we added that to the book. For that I would suggest a livecd. How exotic must we get? Would be great, but the RaQ series and few other designs don't have the ability to boot from a cdrom.That's why I'm persuing a method that is a little easier for people to work with on all systems. NFS root booting. http://svn.jg555.com/viewcvs.cgi/?root=hints look at netboot.txt file So far I got it work on the following configurations x86 - grub raq2 - standard firmware raq2 - colo - chainloading raq3 - colbalt-rom firmware from sourceforge That's all I have here to test, anyone else is willing to help. I can get testing done on Sparc and PPC. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Jim Gifford wrote these words on 05/27/05 01:48 CST: Would be great, but the RaQ series and few other designs don't have the ability to boot from a cdrom.That's why I'm persuing a method that is a little easier for people to work with on all systems. NFS root booting. This is the future of LFS? Is the point of LFS in the future to cater to the folks with the 5% of hardware? Seems that for the 95% (just my estimates, but it has to be close to reality) of the folks that will be building on x86 architecture, that the book is becoming increasingly difficult. I think a call to the community as to what should really be the LFS goals is in order. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 02:07:01 up 55 days, 1:40, 2 users, load average: 0.00, 0.00, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Archaic wrote: For that I would suggest a livecd. How exotic must we get? Depends on what you are building for. All well and good if your target actually has a cdrom, and there actually is a livecd for your target platform... Most of my sparc32's don't have a cdrom, and neither does my arm board or e740... Regards [R] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
On Fri, May 27, 2005 at 05:28:29PM +1000, [EMAIL PROTECTED] wrote: Depends on what you are building for. All well and good if your target actually has a cdrom, and there actually is a livecd for your target platform... Most of my sparc32's don't have a cdrom, and neither does my arm board or e740... This is a lot of hurdle jumping though for the few people who don't have a linux system running on their computers already or who can't boot a CD with a linux system on it. That is why I think the more exotic setups should be handled in hints and *not* in the book. Too many layers of abstraction will turn people off. What's the purpose of supporting more methods if it turns off the core audience of the book? I think we need to really consider what hoops we are willing to jump through to gain certain benefits. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
R.Quenett wrote these words on 05/27/05 09:15 CST: Pardon me for butting in here but, to me in my ignorance, the one benefit that would justify (again, to me - I'm not trying to speak for anyone else) almost anything would be the 'purity of the build' (which I understand to mean the new build containing as close to zero as possible code resulting from anything but the new source) even in very small increments. I thought that was why the book had gone in its present direction. Was I wrong? I asked a very similar question a while back. After pressing the issue, the answer was that for x86 builds, you end up with the same thing regardless which build method you use. Note, however, this only applies to non-cross builds. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 09:35:00 up 55 days, 9:08, 2 users, load average: 0.28, 0.08, 0.02 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
TheOldFellow wrote:
I must start by saying that I have not been interested enough in this
thread to have read every contribution in detail.
Having built a couple of POX86S (plain old X86 system) with cross-lfs
instructions, I've decided to take a copy of the latest svn
non-cross-lfs book and maintain that for myself. The increased
complexity of the cross-lfs method has zero benefit in x86 AFAICS.
Increased complexity? For x86 - x86, I'm not sure I see it that way.
Let's break it down a bit. In the 5.x-6.x books, chapter 5, for your
toolchain, you built gcc 4 times, right? (static build we run 'make
bootstrap' with is more or less equal to 3 builds of gcc) Now, we build
it 4 times total again before we start on the final system (two of the
times slightly quicker builds because we're using the 'make all-gcc'
command). Binutils is built the same amount of times, and the two extra
glibc steps (the headers and the startfiles) are really minimalistic in
their impact. All in all, from cross-tools to the end of the
temp-system, you have pretty nearly the same amount of work you would do
in chapter 5 now.
If you mean complexity because it's a new method of building, well the
reasons for all of the steps will be fully explained before any book is
finally released. I can't see how two extra variables ${LFS_HOST}, and
${LFS_TARGET} used in two new flags, --host or --target provide that
much more of a complexity layer.
And, again, the reason for going this route even for just x86 - x86
would be to provide absolute independance from the host. Isn't that what
LFS has been aiming for since the beginning of PLFS? This is in a sense
the realization of that goal. Total abstraction.
I'm not saying that cross-lfs isn't a great bit of work, it's just that
I don't see that it has any application to 95% of folk building LFS for
the first time, and the 5% who need a cross method could reasonably read
a hint.
I think by this argument, we could just revert the current book to drop
the entire PLFS method (all of chapter 5) and just build LFS the way it
used to be. What's the point of trying to separate the final system
from the host, if you're not concerned about getting it entirely clean?
BTW, I wonder if the 5% comes from the fact that up to now, LFS only
supported x86. There are actually quite a large number of people using
Linux on other archs, and if we support those, the number of LFSers
total can only grow. Not to mention that the AMD64 is becoming *very*
popular these days, esp., from what I can see, among LFSers. There is
definitely a bigger need than just 5%, or at least, there soon will be.
Anyway, I've done the build several times now, and quite honestly
(especially once the reasons for each step are fully layed out) I don't
see that the cross-lfs book would be much more complex than the separate
tools idea that we are using now.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
R.Quenett wrote: Pardon me for butting in here but, to me in my ignorance, the one benefit that would justify (again, to me - I'm not trying to speak for anyone else) almost anything would be the 'purity of the build' (which I understand to mean the new build containing as close to zero as possible code resulting from anything but the new source) even in very small increments. I thought that was why the book had gone in its present direction. Was I wrong? Nope, you hit the nail on the head. See my other post just now... -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Randy McMurchy wrote: I asked a very similar question a while back. After pressing the issue, the answer was that for x86 builds, you end up with the same thing regardless which build method you use. Note, however, this only applies to non-cross builds. I'm sorry, I must have missed this one. Mind pointing me to a link? (I assume it was on one of our lists...) Anyway, from what I can see, the results *could* end up the same, but I don't see how you could count on it always being so. With the cross build method, there is almost no way the host could affect the target. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
TheOldFellow wrote: The increased complexity of the cross-lfs method has zero benefit in x86 AFAICS. I'm not saying that cross-lfs isn't a great bit of work, it's just that I don't see that it has any application to 95% of folk building LFS for the first time, and the 5% who need a cross method could reasonably read a hint. I really don't feel comfortable forcing the toolchain to build a cross toolset when it isn't necessary. I was very keen to see if there was an advantage to using the cross method, but after experimenting with it, I have come to this differing view. Some people may feel betrayed by this, but Randy was brave enough to go against the trend and I feel I have to support him. I would also point out that the cross build method is necessary only once per architecture. One you have a system built on a specific arctitecture, a user can revert to the current method for a subsequent build. Once a user can boot into Linux using the native arctitecture, the cross build method becomes moot. A agree with Richard that the work being done is very nice. I just feel it is a specialized technique that should not be the focus of the main stream book. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
On Fri, May 27, 2005 at 09:52:32AM -0500, Bruce Dubbs wrote: I would also point out that the cross build method is necessary only once per architecture. One you have a system built on a specific arctitecture, a user can revert to the current method for a subsequent build. Once a user can boot into Linux using the native arctitecture, the cross build method becomes moot. This is incorrect. It just so happens that the vehicle by which separation from the host comes is a cross-arch mechanism. The forefront goal should be host separation and not actually cross-arch compiling (which is an added benefit). Therefore, after you have built the system, saying it is moot to follow the same process is exactly the same as saying that you are no longer concerned about the host influencing the final build. It doesn't matter that LFS is building LFS. The host should never affect the target. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Jeremy Huntwork wrote:
Increased complexity? For x86 - x86, I'm not sure I see it that way.
Let's break it down a bit. In the 5.x-6.x books, chapter 5, for your
toolchain, you built gcc 4 times, right? (static build we run 'make
bootstrap' with is more or less equal to 3 builds of gcc) Now, we build
it 4 times total again before we start on the final system (two of the
times slightly quicker builds because we're using the 'make all-gcc'
command). Binutils is built the same amount of times, and the two extra
glibc steps (the headers and the startfiles) are really minimalistic in
their impact. All in all, from cross-tools to the end of the
temp-system, you have pretty nearly the same amount of work you would do
in chapter 5 now.
My main concern is the increased use of patches and seds to change
things from the intentions of the package authorities. Some of them are
real 'hacks' - I feel the same way about the specfile edits from PLFS
BTW. This is what I mean by complexity. And the strict separation is
not really needed if the build platform is your LiveCD. Indeed, if we
are going to be pedantic about seperation, then we should build MORE
tools BEFORE we build the cross-tools set, otherwise we have never run a
gcc with --bootstrap for the host (you can't bootstrap a cross-build).
If you mean complexity because it's a new method of building, well the
reasons for all of the steps will be fully explained before any book is
finally released. I can't see how two extra variables ${LFS_HOST}, and
${LFS_TARGET} used in two new flags, --host or --target provide that
much more of a complexity layer.
With respect, I think I understand the method now, not that most newbies
will even bother to read your explanations before flooding the wrong list.
And, again, the reason for going this route even for just x86 - x86
would be to provide absolute independance from the host. Isn't that what
LFS has been aiming for since the beginning of PLFS? This is in a sense
the realization of that goal. Total abstraction.
We all might find it refreshing to have another look at LFS 2.4 - it
built a mean Linux - of course it had hidden faults, but it worked very
well.
I'm not saying that cross-lfs isn't a great bit of work, it's just that
I don't see that it has any application to 95% of folk building LFS for
the first time, and the 5% who need a cross method could reasonably read
a hint.
I think by this argument, we could just revert the current book to drop
the entire PLFS method (all of chapter 5) and just build LFS the way it
used to be. What's the point of trying to separate the final system
from the host, if you're not concerned about getting it entirely clean?
Yes, and that would be fine if we always built (on x86) from a LiveCD of
the latest toolchain. It's certainly quicker and less error prone.
BTW, I wonder if the 5% comes from the fact that up to now, LFS only
supported x86. There are actually quite a large number of people using
Linux on other archs, and if we support those, the number of LFSers
total can only grow. Not to mention that the AMD64 is becoming *very*
popular these days, esp., from what I can see, among LFSers. There is
definitely a bigger need than just 5%, or at least, there soon will be.
This is a good point. We'll see if the stats reflect this - we should
prepare the website to take 'warranty-cards' perhaps?
Anyway, I've done the build several times now, and quite honestly
(especially once the reasons for each step are fully layed out) I don't
see that the cross-lfs book would be much more complex than the separate
tools idea that we are using now.
Me too - several builds, one from Gentoo (up-to-date ~x86) and one from
Ubuntu HH. Both work OK, and I've built most of BLFS on one of them
with only minor issues (mind you, my BLFS built without big problems on
DIY-linux-gcc4 too). I just had the impression that I was typing more
maybe ( Real LFSers don't use scripts )
We often (once a year or so) have a debate in LFS circles to decide if
those who want to try experimental stuff should be in the forefront, or
whether we should be trying to get a perfect book for newbies to build
with. The answer is a compromise, always was, always will be. I'm
usually with the bleeding-edgers - I'm just not sure that the balance is
right on this one yet.
R.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
TheOldFellow wrote: We often (once a year or so) have a debate in LFS circles to decide if those who want to try experimental stuff should be in the forefront, or whether we should be trying to get a perfect book for newbies to build with. The answer is a compromise, always was, always will be. I'm usually with the bleeding-edgers - I'm just not sure that the balance is right on this one yet. Indeed. I can actually sympathize with both sides of the argument at this point. (You presented one side very well, so I thought I'd try to show the other side of the coin. ;) ). It would be interesting/nice to hear Gerard's take on this issue at this time. Esp. considering that he still holds copyright on all this stuff. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Jeremy Huntwork wrote: It would be interesting/nice to hear Gerard's take on this issue at this time. Esp. considering that he still holds copyright on all this stuff. Gerard who? I think there used to be someone called Gerard around here once, long ago... R. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Archaic wrote: On Fri, May 27, 2005 at 09:52:32AM -0500, Bruce Dubbs wrote: I would also point out that the cross build method is necessary only once per architecture. One you have a system built on a specific arctitecture, a user can revert to the current method for a subsequent build. Once a user can boot into Linux using the native arctitecture, the cross build method becomes moot. This is incorrect. It just so happens that the vehicle by which separation from the host comes is a cross-arch mechanism. The forefront goal should be host separation and not actually cross-arch compiling (which is an added benefit). Therefore, after you have built the system, saying it is moot to follow the same process is exactly the same as saying that you are no longer concerned about the host influencing the final build. It doesn't matter that LFS is building LFS. The host should never affect the target. Has it been shown that the current method has leaks from the build system into the new LFS system? If so, I'm not aware of them. Can you point to anything specific? If we are going this route because something might be influencing the new LFS system, I think its overkill. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
El Viernes, 27 de Mayo de 2005 16:52, Archaic escribió: Attempts to support building where host!=target is hints territory as there are just too many variables for a linear based book to contend with. That's also my point. In resumen: Cross-build techniques are good. To reboot using the temp tools is good, noticing that when host(machine+arch)=target(machine+arch) we can to use the old chroot way, if dessired. To try to solve the question How can I boot my target machine when host-machine!=target-machine? into the book is bad. We can't test all possible combinations and scenarios, and there isn't an unique solution that can work for all. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
M.Canales.es wrote: In resumen: Cross-build techniques are good. To reboot using the temp tools is good, noticing that when host(machine+arch)=target(machine+arch) we can to use the old chroot way, if dessired. To try to solve the question How can I boot my target machine when host-machine!=target-machine? into the book is bad. We can't test all possible combinations and scenarios, and there isn't an unique solution that can work for all. That's a very good point. There is not going to be one solution for the reboot when different architectures are involved. We can't assume that everyone is build on the same architecture. I have successfully built a RaQ2 temp-tools section on a x86, and have nfsroot booted and it works. Then I was able to copy everything over and it worked. I have also successfully built the same system as above, but using chroot, after creating the directories, etc, and copied tools over and used an modified chroot. Now how is that relevant toour discussion, a lot. Do you think we should put this information into the book, the answer is no. But instead what I did in the book was reference an hint with the supported architectures listed. I just made the commit so, here is a rendered version of what I'm talking about. That way the LFS builder can choose his method chroot, reboot via whatever. We just provide the basic toolchain and guides to get the created system to the architecture, we are not going to hand hold on this, because it's different for every architecture. http://documents.jg555.com/cross-lfs/x86/reboot/whatnext.html, yes I will be adding additional wording. Now I want to address the why other architectures issue, that has been brought up. In my case with the RaQ2, since I was familiar with LFS, and I had a numerous supplies of RaQ2s, which had a major security hole in it's original OS. Since the vendor doesn't support them any more, I decided to make LFS work on them. Now the nice thing about the work I did is we go noticed by the Linux-mips group, and have had a lot of people starting to look at and use our methodology. That's why I have been working on this so much, and to get exposure to other architectures to see if what we have works. For those who haven't looked at the raw xml that cross-lfs uses, there are only minor changes between the architectures, the obvious being for patches(ie glibc patches) and additional hardware specific issues (ie gcc). But the build processes are exactly the same. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
El Viernes, 27 de Mayo de 2005 21:08, Jim Gifford escribió: http://documents.jg555.com/cross-lfs/x86/reboot/whatnext.html, Object not found But reading the XML file, that look sensible to me. Thanks. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Bruce Dubbs wrote: Has it been shown that the current method has leaks from the build system into the new LFS system? If so, I'm not aware of them. Can you point to anything specific? If you use a host with new binutils (2.15.x), but are building old binutils (2.14 was what was current when this issue came up), then after you install the old binutils, linking won't work anymore. gcc's specs file uses --as-needed, because 2.15.x supported it, but the ld from 2.14 will fail because it doesn't support it. This was happening about a year ago, and we eventually fixed it by upping the book's binutils to 2.15.whatever. But similar issues can come up again fairly easily (and will, every time binutils adds a new command line option), and upgrading core system packages (binutils, gcc, glibc) is not necessarily an easy fix if they do. It isn't trivial, in any case. The right fix, at least according to me, is to get complete separation from the host. I.e., cross-build everything, maybe including a kernel, then chroot or reboot (that's where the discussion is centering here, and I don't really care which option we go with -- I'll probably end up building a kernel, booting to it while still using my old system's FSes, then chrooting, because I'll be building on machines that I'm at), then continue. signature.asc Description: OpenPGP digital signature -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Bryan Kadzban wrote: If you use a host with new binutils (2.15.x), but are building old binutils (2.14 was what was current when this issue came up), then after you install the old binutils, linking won't work anymore. gcc's specs file uses --as-needed, because 2.15.x supported it, but the ld from 2.14 will fail because it doesn't support it. This was happening about a year ago, and we eventually fixed it by upping the book's binutils to 2.15.whatever. But similar issues can come up again fairly easily (and will, every time binutils adds a new command line option), and upgrading core system packages (binutils, gcc, glibc) is not necessarily an easy fix if they do. It isn't trivial, in any case. Thanks for the case-in-point, Byran. The idea that similar issues can come up, (and as you showed, we have previous examples of them) and that the host system can affect the current build method was what I was trying to express earlier. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Jeremy Huntwork wrote: Thanks for the case-in-point, Byran. Was the SE-Linux afflicted FC3 distro also because of host infection, or was that down to incorrect instructions? Basically what was happening was that (I think) glibc was being built in chapter 5 against the host's se-linux stuff. When we were chrooted in chapter 6, glibc wanted to enable se-linux support again, but obviously couldn't. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Matthew Burgess wrote: Was the SE-Linux afflicted FC3 distro also because of host infection, or was that down to incorrect instructions? Basically what was happening was that (I think) glibc was being built in chapter 5 against the host's se-linux stuff. When we were chrooted in chapter 6, glibc wanted to enable se-linux support again, but obviously couldn't. I think again, it's just the nature of our current build method. Not sure that there was either side to blame on that one. The point is that things like that get covered over with the cross-build method. And while we currently require that the host be a Linux system, afaict, the only requirements for a host with the cross-build instructions would be to have a gnu toolset available. (ie., if you started building ppc64 LFS on an OSX machine.) Granted, the ability to build for anything from anything is not the main reason for the change, but it does highlight the desired benefit of severly limiting the impact of the host system on the final build. If we weren't worried about what our end result was we also wouldn't take the time to run the testsuites on our toolchain... -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Jeremy Huntwork wrote: Increased complexity? For x86 - x86, I'm not sure I see it that way. You have to be kidding, right? Everyone around here has obviously forgotten what it's like to be a newbie. I'll repeat what I've stated in the past: - the greatest thing about LFS is that newbies can come here and find a simple build recipe that actually works and is easy to understand! If you guys cannot see this then you've seriously lost the plot. And, again, the reason for going this route even for just x86 - x86 would be to provide absolute independance from the host. Isn't that what LFS has been aiming for since the beginning of PLFS? This is in a sense the realization of that goal. Total abstraction. As a co-author of PLFS, I have a fair idea of what I'm taking about and the answer is NO!. This complete independence from the host line that everyone around here keeps peddling is seriously overrated. Sure, it is a factor but what matters most is the finished product ie: in LFS speak, the current Chapter 6. The purity of the finished product can be measured using ICA style techniques. And _THAT_ was the aim of PLFS. Folks used to believe you had to build LFS twice to attain a perfect system. A proper build method avoids the need for building twice. Like I said, this stuff can be measured! Of course there are loads of other factors, for eg: - how you get there - complexity - range of capable build hosts - chances of things going wrong for newbies - robustness - etc etc etc The current cross build addresses the how you get there part. But IMHO it falls short because of the other factors. Look, I'm not here to rain on anyone's parade. I've done some analysis on this cross stuff and in general the cross-lfs work is very good. Sure, I don't agree with everything in it, but the biarch stuff really is on the cutting edge. My point is that I just don't believe cross-lfs methods are suitable for the masses as the default build. You already have BLFS, ALFS and HLFS. Why not CLFS? Cross stuff is needed for newer arches. But for everyone? I can't help but think this whole drive to inflict cross build on everyone is partly my fault. I know for a fact that some LFS folks are still bitter about my departure from LFS and see my DIY project as competition. This, I suspect, is what's driving this whole thing. Sad really. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Archaic wrote: In an attempt to get this info both archived, and presented to the larger community, I am writing up a synopsis of ideas that have been floating around on IRC as to how to handle the chroot/reboot phase of the cross-lfs book. I will list them and give a brief pro/con for each as I understand it. 1) Tar up the temptools and *somehow* move them to the target. |- This one has many drawbacks as it requires that the host already has an OS and that host has the ability to create partitions, etc. in preparation for the tarball. If the system is remote, then it will require uploading a sizable tarball to the host, assuming the host knows what to do with it. Even in the day of high-speed personal internet, upload speed sucks. :) This one, IMHO is the worst possible option to support in the book. The others of course, too, have drawbacks, but this one is by far the worst. I would rather see the book *only* have a chroot path than have a tar/copy files for your new system. In fact, the more I think about it, I think this is the way we should go. Where the book currently splits, there should be an explanation of the different courses a reader could take with links that point to hints on various methods of getting the new tools onto the target machine and in an environment where they can then finish the book. Each hint should leave the user ready to pick up just where the user enters into chroot, and allow them to successfully finish the build. After spending some time on the reboot section, I think it's a mistake to include any of that extra stuff in the book. Esp. when it still seems that more will be taking the chroot path anyway. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
El Jueves, 26 de Mayo de 2005 22:11, Archaic escribió: On Thu, May 26, 2005 at 04:05:41PM -0400, Jeremy Huntwork wrote: After spending some time on the reboot section, I think it's a mistake to include any of that extra stuff in the book. Esp. when it still seems that more will be taking the chroot path anyway. Exactly what I was saying... I see two different issues here. One is to build the temp tools in one machine using they to boot the target machine and build then the final system. IMHO, there is few (or none) cases where that will be actually required. The other is to reboot the current machine using the temp tools to build the final system, instead to chroot. That look like a good way to build, for example, a 64 bits O.S from a 32 bits host O.S. Then, for me to have a reboot way is fine, but try to support build in one machine to boot other machine into the book is a bad idea. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Jon Ringle wrote: On Thursday 26 May 2005 16:44, Jim Gifford wrote: What about when you build on x86 for a different platform then chroot is not an option at all. That's the reason we added that to the book. I am working with the cross-lfs scripts to target an arm processor from an x86 host. I certainly can't run the final executables in chroot... Then the book should point you at a 'how to move target files from host to target where target!=host' style hint. Although the cross-lfs book is an enabler for cross-lfsing, I'm not convinced that the majority of our readers will in actual fact be cross-building their system. I think the book will be far more readable/maintainable if it just outlines the chroot method and points folks to various hints that outline other methods of getting to a stage where they can build the final part of their system on the target machine. That said, there is a case for perhaps moving from the current 'chroot' approach to a 'reboot' approach as that will enable 32-bit-64-bit cross-builds (assuming IA64/AMD64/EMT64 whatever they call it these days). That may make the default book immediately useful to a larger set of people, whilst not excluding those of us still doing host=target style builds. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Matthew Burgess wrote: Then the book should point you at a 'how to move target files from host to target where target!=host' style hint. Although the cross-lfs book is an enabler for cross-lfsing, I'm not convinced that the majority of our readers will in actual fact be cross-building their system. I think the book will be far more readable/maintainable if it just outlines the chroot method and points folks to various hints that outline other methods of getting to a stage where they can build the final part of their system on the target machine. That said, there is a case for perhaps moving from the current 'chroot' approach to a 'reboot' approach as that will enable 32-bit-64-bit cross-builds (assuming IA64/AMD64/EMT64 whatever they call it these days). That may make the default book immediately useful to a larger set of people, whilst not excluding those of us still doing host=target style builds. Matt, that was one of the purposes of the cross-lfs was the multi-architecture build, the reboot section is needed. I have it working and have been making the changes. It's just at the reboot point where there seems to be an issue. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Jim Gifford wrote: Matt, that was one of the purposes of the cross-lfs was the multi-architecture build, the reboot section is needed. I have it working and have been making the changes. It's just at the reboot point where there seems to be an issue. I think that's what he was saying - Keep it all on the same machine, but change the chroot to a reboot section so that you can reboot into a kernel that supports 64-bit. Where there is need to do that all on another machine (an entirely different arch family) you get pointed toward a hint. Am I reading you right, Matt? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Jeremy Huntwork wrote: Keep it all on the same machine, but change the chroot to a reboot section so that you can reboot into a kernel that supports 64-bit. Where there is need to do that all on another machine (an entirely different arch family) you get pointed toward a hint. Am I reading you right, Matt? Yep, sounds like what I meant to get across. Cheers, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Matthew Burgess wrote these words on 05/26/05 16:46 CST: Jeremy Huntwork wrote: Keep it all on the same machine, but change the chroot to a reboot section so that you can reboot into a kernel that supports 64-bit. Where there is need to do that all on another machine (an entirely different arch family) you get pointed toward a hint. Am I reading you right, Matt? Yep, sounds like what I meant to get across. And for the very real case where folks don't have physical access to the machine and a reboot is required, it would be nice to have a big warning to ensure that the machine will come up as desired (double and triple check the boot configuration). Any mistake in the boot configuration means one will have a dead machine. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 16:49:00 up 54 days, 16:22, 2 users, load average: 0.03, 0.03, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
On Thu, May 26, 2005 at 01:44:10PM -0700, Jim Gifford wrote: What about when you build on x86 for a different platform then chroot is not an option at all. That's the reason we added that to the book. For that I would suggest a livecd. How exotic must we get? -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
El Sábado, 14 de Mayo de 2005 07:36, Jim Gifford escribió: My idea is the netboot thing. Since all the bootloaders in question will work with NFS or TFTP booting. Could you explain that in detail? I'm not sure but IMHO, to can boot from net the BIOS must be configured first to allow it, and that implies to have physical acces to the machine. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
On Sat, 14 May 2005, M.Canales.es wrote: El Sábado, 14 de Mayo de 2005 01:42, Archaic escribió: Lastly, IMHO the combo HOST != TARGET only is usefull in two cases: To build a full system (with X, servers, etc...) in a fast machine that will be later instaled in a slow machine. Or to build a minimal system to can boot a machine that have no system instaled yet. But in that case you must have physical acces, then you can use also a BooCD to boot the machine and to install LFS using HOST=TARGET. I think I've got a third - machines that can run a 32-bit or a 64-bit system (i.e. x86_64 or ppc64) that are currently running 32-bit (i686 or ppc). It's easy enough to install current 32-bit LFS on them, upgrading to multilib should be educational (I'm trying at the moment, learning a lot about the toolchain so far, but a very long way from completing). Specifically, I'm hoping to build a 64-bit kernel (done that part), then use that with the 32-bit userspace to build the multilib. Or do you propose that those of us moving to 'fatter' machines should rely on new boot CDs ? Of course, even if you agree that this is a valid way of building, it may be better as a hint. To some extent, that probably depends on how much the process differs from a multilib linux host building a new multilib LFS for itself. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
El Sábado, 14 de Mayo de 2005 15:43, Ken Moffat escribió: I think I've got a third - machines that can run a 32-bit or a 64-bit system (i.e. x86_64 or ppc64) that are currently running 32-bit (i686 or ppc). It's easy enough to install current 32-bit LFS on them, upgrading to multilib should be educational (I'm trying at the moment, learning a lot about the toolchain so far, but a very long way from completing). But in that case you already have a linux system running on that machine, then you could do the full mulltilib build on the target. Don't miss the point of this thread: Is there realy some case where you must to build the packages up to reboot in one machine (the HOST) and then to copy that temp system to other machine (the TARGET) to build the final system? -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
On Sat, 14 May 2005, M.Canales.es wrote: Don't miss the point of this thread: Is there realy some case where you must to build the packages up to reboot in one machine (the HOST) and then to copy that temp system to other machine (the TARGET) to build the final system? Ah, I misunderstood the usage of 'HOST' and 'TARGET' here. I am indeed running it all on the 'TARGET'. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
M.Canales.es wrote: El Sábado, 14 de Mayo de 2005 07:36, Jim Gifford escribió: My idea is the netboot thing. Since all the bootloaders in question will work with NFS or TFTP booting. Could you explain that in detail? I'm not sure but IMHO, to can boot from net the BIOS must be configured first to allow it, and that implies to have physical acces to the machine. It depends on your setup, we would have to create a netboot floppy. Take a look at http://gentoo-wiki.com/HOWTO_Gentoo_Diskless_Install -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
El Sábado, 14 de Mayo de 2005 16:23, Jim Gifford escribió: It depends on your setup, we would have to create a netboot floppy. Take a look at http://gentoo-wiki.com/HOWTO_Gentoo_Diskless_Install From that page: Booting the client Now, just boot the client. Configure the bios and the network card to use PXE in first to boot (before CD-ROM or floppy). Then, you need physical acces to the client to can configure the BIOS and the network card. Plus, that look hint material, not book material. Several extra dependecies and host requeriments are needed to can create that setup. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
El Sábado, 14 de Mayo de 2005 01:42, Archaic escribió: Ideas? Comments? Suggestion? We need your input. Multiple perspectives ultimately make for a better book. The above is merely my perspective and likely does not cover all aspects needed to make a good decision. There is some aspects that I don't fully understand yet. If the target host (remote or local) is a machine running linux, wy not to do the full construction from the begin directly at the target machine? In that case HOST=TARGET due that both are the target machine. A question, when the target host is a remote machine not running linux, how do you manage it to install any other linux distro? Lastly, IMHO the combo HOST != TARGET only is usefull in two cases: To build a full system (with X, servers, etc...) in a fast machine that will be later instaled in a slow machine. Or to build a minimal system to can boot a machine that have no system instaled yet. But in that case you must have physical acces, then you can use also a BooCD to boot the machine and to install LFS using HOST=TARGET. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Handling the change from the temp phase to the final target phase
Archaic wrote: In an attempt to get this info both archived, and presented to the larger community, I am writing up a synopsis of ideas that have been floating around on IRC as to how to handle the chroot/reboot phase of the cross-lfs book. I will list them and give a brief pro/con for each as I understand it. 1) Tar up the temptools and *somehow* move them to the target. |- This one has many drawbacks as it requires that the host already has an OS and that host has the ability to create partitions, etc. in preparation for the tarball. If the system is remote, then it will require uploading a sizable tarball to the host, assuming the host knows what to do with it. Even in the day of high-speed personal internet, upload speed sucks. :) 2) Put the target's HD in the host's machine and then swap it back out when ready to reboot. |- This assumes that one has physical access and that the HD's are easily swappable. If they are, this method works, but there are too many situations that will not work (i.e. any remote build, a laptop vs. desktop HD, and even the niche boxes like the mac mini). 3) Have the book create a bootable CD of the temptools upon completion then use that to boot into the target. |- This assumes that the host can burn a CD and that the target can boot a CD. The later is likely moot as there are very few systems that can't boot a CD in proportion to those which can (not unlike the old argument over having a /boot partition in the first 1024 cylinders). This also assumes physical access. 4) Make a boot floppy to load the CD. |- The day is fast approaching where floppies are no longer included as part of a new system. Especially in laptops. This also assumes physical access. And now for a novel concept Have the book officially support HOST=TARGET with a chroot (no rebooting) and then point to hints if someone feels the need to use a different host. Pros/cons of this idea: One has to be able to burn a CD *only* if the target system isn't running linux. One has to have physical access *only* if the target system isn't running linux. The CD can be a minimal CD, unlike the liveCD and with compression could easily be brought under 50 MB for the iso download. Again, only needed *if* the target isn't running linux. As you can see, the biggest hurdle is overcome by the host having a linux system already which has been the assumption for LFS since day one. Even so, many people have successfully been using knoppix for years and the lfslivecd since its inception. Here we can cater to a minimalistic host on CD for any supported arch and the book can stay as linear as possible. Ideas? Comments? Suggestion? We need your input. Multiple perspectives ultimately make for a better book. The above is merely my perspective and likely does not cover all aspects needed to make a good decision. My idea is the netboot thing. Since all the bootloaders in question will work with NFS or TFTP booting. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
