Re: sysctl script at S90?
Alexander E. Patrakov wrote: Please redo your analysis. OK, first admission - this wasn't analysis of any kind. It was simply a gut reaction to the sysctl bootscript failing. I needed the box up pretty quick, so just moved the sysctl script to workaround the problem. The existence of a /dev entry and udev has absolutely no relation to /proc contents. OK, thanks. I'll take a proper look at this tonight. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Useless note on Ch5 glibc page
Glibc page in Chapter 5 contains the following paragraph: During this stage the following warning might appear: configure: WARNING: *** These auxiliary programs are missing or *** incompatible versions: msgfmt *** some features will be disabled. *** Check the INSTALL file for required versions. The missing or incompatible msgfmt program is generally harmless, but it can sometimes cause issues when running the test suite. This msgfmt program is part of the Gettext package which the host distribution should provide. If msgfmt is present but deemed incompatible, upgrade the host system's Gettext package or continue without it and see if the test suite runs without problems regardless. The reader cannot see this. The reason is that he must have gettext installed on the host in order to build binutils earlier. Solutions: 1) Remove the note. 2) Pass --disable-nls to binutils in Chapter 5 in order to avoid dependency on gettext. I prefer (2), since we already disable translated messages at runtime by setting LC_ALL=POSIX. It's just illogical to compile binutils with (costly) support for translated error messages but never use this feature. Also, (2) is already implemented in cross-LFS, but the explanation it is not needed is not perfect. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 6.1 release ?
Ken Moffat wrote: I see testing is moving on - did the 6.1 release get pulled ? Nope, not pulled, just delayed whilst things went slightly manic at work and at home. I think things are settling down now, so managed to get a bit of work done catching up on the outstanding 6.1 items last night. Things are looking good for getting some more stuff out of the way tonight. We'll be breaking the unwritten 'rule' of not bumping version numbers on packages during our 'slushy' RCish period, due to security issues in the kernel (which will be bumped to 2.6.11.9) and a bug in the bootscripts which caused network interfaces to not be brought up in some situations. The recent gzip patch will also be added, as it fixes a security problem (or two). Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Use of Variables in Cross-LFS
On Fri, 13 May 2005, Jeremy Huntwork wrote: Ken Moffat wrote: In my opinion, put it all in variables - the sparc page has '-m32' exposed to the reader without an explanation (although it might be explained on another page). Put it all in variables, and explain them at the beginning, then just use them. The explanatory text for the cross-lfs is still coming. We still have a lot of work to do in that area. At the moment, we're just focusing on getting the commands straight, however, point taken. No worries. I'm attempting a slightly different multilib build (i686 LFS-6.1 to build x86_64 kernel, then boot that and hopefully build the rest much as the 6.1 book will) and I'm still tweaking the options in the first part (64-bit binutils and c compiler) so that I don't include [i] too many [/i] bogosities in my instructions. 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: Use of Variables in Cross-LFS
Ken that's one of the things we are going to do after we get the builds working is go through every page and add more text or less text to give the reader a better understanding. We would welcome your input on this. -- -- [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: Use of Variables in Cross-LFS
On Fri, 13 May 2005, Jim Gifford wrote: Ken that's one of the things we are going to do after we get the builds working is go through every page and add more text or less text to give the reader a better understanding. We would welcome your input on this. I'll be happy to contribute, but I've got to understand how the new stuff fits together first. 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: Typos and Phrasing -- Request
On Thu, May 12, 2005 at 03:24:46PM -0700, Jim Gifford wrote: Tried that via svk, bombed everytime. I talked to the on irc.freenode.net #svn, they said if the structure was the same it wouldn't be an issue, but we made a lot of changes to lfs to multi-arch and multi-arch to cross-lfs. As we discussed on IRC, it can still be done without any historical loss, but it will require a lot of manual fiddling. However, as this is a one time thing, I think we'd be shooting ourselves in the foot researching a way to automate instead of just doing it. This is predicated on the fact that the only automated solution recommended by the SVN devs has failed and further research will take quite some time. -- 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: Useless note on Ch5 glibc page
On Fri, May 13, 2005 at 02:46:09PM +0600, Alexander E. Patrakov wrote: 2) Pass --disable-nls to binutils in Chapter 5 in order to avoid dependency on gettext. Yes this has allowed me to build testing with testing with testing (3 layers deep) with no problems. I use --disable-nls on every package that accepts it and I do not build gettext. -- 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: Typos and Phrasing -- Request
El Sábado, 14 de Mayo de 2005 00:16, Archaic escribió: As we discussed on IRC, it can still be done without any historical loss, but it will require a lot of manual fiddling. However, as this is a one time thing, I think we'd be shooting ourselves in the foot researching a way to automate instead of just doing it. This is predicated on the fact that the only automated solution recommended by the SVN devs has failed and further research will take quite some time. Revising the webcvs I noticed that the historial is already loss in the cross-lfs branch due the big changes in the book structure. -- 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
Handling the change from the temp phase to the final target phase
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. -- 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: Typos and Phrasing -- Request
On Sat, May 14, 2005 at 01:13:31AM +0200, M.Canales.es wrote: Revising the webcvs I noticed that the historial is already loss in the cross-lfs branch due the big changes in the book structure. That can be folded back in. For instance, every file that is in the same location within the book's structure and also has the same name will inherit the history from trunk when it is copied over. The effect will basically just be a big diff on the file. For any file that has moved or changed names, the corresponding file in trunk can be svn moved to match *before* the files are copied. Thus the files moved will also inherit trunk's history. Of course, anything that exists in the branch and not in trunk will start fresh as a new file, but that would happen regardless. Ultimately, what this method will do is wipe the branch's history, and trunk will maintain history. The copying of the branch back into trunk will result in trunk recording this as a single point in time event and the files will not bring along the history that accrued during their time in the branch. Steps *could* be take to not lose any history, but this would require almost 100% manual merging instead of simply overwriting the files with the new versions (which just generates a big diff). So now we have a point of perspective... Is this branch replacing trunk, or is it being assimilated by the trunk. If the latter, the trunk's history is more important. I view it as the latter. BTW. I see trunk as having more reason to keep history. -- 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 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
