Re: Bootscripts and error handling
On Friday 08 July 2011 17:55:09 Bruce Dubbs wrote:
> I've been working on bootscripts. Basically, I'm rewriting them to get
> a better understanding. I may end up throwing them out completely but I
> want to discuss the issue of error handling.
>
> There are three bootscript files that use the
>
>read ENTER
>
> construct: checkfs, udev, and functions.
Hi Bruce,
I'll throw in my $0.02, as this read ENTER has been always a thorn in my side
and I've been patching the lfs-bootscripts for a very long time to get around
it.
What I do: I have a dedicated partition of 100MB for storing boot failure
logs. I pass an extra argument to grub:
rescue-logs=/dev/sda6
however, with a bit of tweaking I can use rescue-logs=LABEL=rescue-logs just
as well.
Then in /etc/rc.d/init.d/functions I have this:
# This is the partition where logs are saved in case of boot failure
# this partition is never used for anything else, and is never mounted rw
RESCUE_LOGS_PARTITION=none
for i in $(cat /proc/cmdline); do
case ${i} in
rescue-logs=*)
RESCUE_LOGS_PARTITION=${i#rescue-logs=}
;;
esac
done
print_error_msg()
{
echo_failure
# $i is inherited by the rc script
boot_mesg -n "FAILURE:\n\nYou should not be reading this error
message.\n\n" ${FAILURE}
boot_mesg -n " It means that an unforeseen error took"
boot_mesg -n " place in ${i}, which exited with a return value of"
boot_mesg " ${error_value}.\n"
boot_mesg_flush
boot_mesg -n "If you're able to track this"
boot_mesg -n " error down to a bug in one of the files provided by"
boot_mesg -n " the LFS book, please be so kind to inform us at"
boot_mesg " lfs-dev@linuxfromscratch.org.\n"
boot_mesg_flush
boot_mesg -n "\n\nWaiting ${TIMEOUT} seconds..." ${INFO}
boot_mesg "" ${NORMAL}
# Now try to save the error into the rescue log
rescue_logs "Error in ${i}!!! Error value= ${error_value}"
sleep ${TIMEOUT}
}
rescue_logs() {
MESSAGE="$@"
DATE=`date +%Y-%m-%d-%H-%M-%S`
LOG="/media/rescue-logs/failed-${DATE}.log"
if [ x"${RESCUE_LOGS_PARTITION}" != x"none" ]; then
if mount ${RESCUE_LOGS_PARTITION} /media/rescue-logs 2>&1 >
/dev/null; then
echo "=== BOOT FAILURE on ${DATE} ===" > ${LOG}
echo "${MESSAGE}" >> ${LOG}
echo "=== END OF BOOT FAILURE on ${DATE} ===" >>
${LOG}
echo -e "\n\n\n" >> ${LOG}
umount /media/rescue-logs
fi
fi
}
And then for example in /etc/rc.d/init.d/udev I have this:
boot_mesg "Populating /dev with device nodes..."
if ! grep -q '[[:space:]]sysfs' /proc/mounts; then
echo_failure
boot_mesg -n "FAILURE:\n\nUnable to create" ${FAILURE}
boot_mesg -n " devices without a SysFS filesystem"
boot_mesg -n "\n\nAfter you press Enter, this system"
boot_mesg -n " will be rebooted for repair." ${INFO}
boot_mesg "" ${NORMAL}
# Now try to save the error into the rescue log
rescue_logs "No SysFS filesystem"
sleep ${TIMEOUT}
reboot -f
fi
Now, I use a grub trick that I believe Bruce posted to this mailing list a few
years ago to set a grub env variable "recordfail" to 1 upon every boot which
is then cleared in case of a normal boot. In case of a failed boot, grub
picks a second entry which is a rescue mode initrd with busybox which tries to
get a DHCP lease or in case of no DHCP server, it tries to find a free IP on
the same network. I had it then email me this temporary IP, but I removed
this as I had to include my email password in the initrd. Maybe there's a way
to encrypt the password, but I didn't look hard enough. This works even for
an internet-facing machine and I've successfully tested logging into my
machine from a different location, as long as my internet connection is
working.
Finally, I just ssh to this mini os, check the rescue logs, fix the problem,
reset the default grub entry and reboot. So far it has worked for me.
As a matter of fact, I created this initrd in response to this email thread:
http://linuxfromscratch.org/pipermail/lfs-dev/2004-January/041720.html
My idea was to have a "self-healing" system as much as, and if at all,
possible. An initrd which will try to fix corrupted filesystems, or at least
provide a way for you to log into the system after a failed boot and allow you
to troubleshoot and fix problems yourself. For headless/keayboardless
machines this is a good thing.
My next crazy idea is relocatable kernel which with some black voodoo m
LFS-7.0 coreutils-8.14 libexec
I must be doing something wrong, so please someone confirm or refute this: coreutils-8.14 as per the 7.0 book installs /usr/libexec/coreutils/libstdbuf.so. I had to pass --libexecdir=/usr/lib in chaper 6 in order to fix the location as /usr/lib/coreutils/libstdbuf.so. Anyone? IvanK. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-7.0 coreutils-8.14 libexec
On Saturday 12 November 2011 15:28:35 Bruce Dubbs wrote: > Ivan Kabaivanov wrote: > > I must be doing something wrong, so please someone confirm or refute > > this: > > > > coreutils-8.14 as per the 7.0 book installs > > /usr/libexec/coreutils/libstdbuf.so. I had to pass > > --libexecdir=/usr/lib in chaper 6 in order to fix the location as > > /usr/lib/coreutils/libstdbuf.so. > It is in /usr/libexec/coreutils/libstdbuf.so on my reference system. So > far, I haven't run into any problems. > > Doing a grep for libstdbuf in /usr/bin shows the only application using > it is /usr/bin/stdbuf and that knows where it is. > > I wasn't aware of this. It does seem out of place, but it also doesn't > seem to do any harm. > > Here is a relevant thread: > > http://comments.gmane.org/gmane.comp.gnu.coreutils.general/1770 > > If it doesn't go in /usr/libexec/coreutils/, the issue is where does it > go? The devs seem to think that it should not be a library directory. > > The FHS says that /usr/lib is OK, but I think that is really for > /usr/lib64, /usr/lib32, etc. libexec is not mentioned in the FHS. > >-- Bruce yeah, it's a strange bird: /usr/lib/coreutils/libstdbuf.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped Looks like a library. The weird thing is that the instructions in chapter 6 (http://www.linuxfromscratch.org/lfs/view/stable/chapter06/coreutils.html) say this in section 6.23.2. Contents of Coreutils: Installed library: libstdbuf.so Installed directory: /usr/lib/coreutils So whoever wrote this seemed to think it belonged in /usr/lib. I'll stick with /usr/lib/coreutils too. IvanK. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] trouble with udev > 173
Hi,
I must be doing something wrong cause LFS-7.1 has been out for a while and
noone has complained yet about udev-181/182.
Here's my problem: I have a custom initramfs that works perfectly well with
udev-173. When the *only* thing I supplant in the initramfs image is
udev-173 with udev-181/182 (everything else remains the same), the kernel
populates /sys with all the correct data (meaning all devices are there) and
udev sees them, but does not create the device nodes under /dev. The only
things it creates are:
btrfs-control
char
fd
fuse
kmsg
log
mapper
net
ppp
snd
stderr
stdin
stdout
I have to create manually /dev/tty1 to be able to get even a console.
Here's what I do in my initramfs's init script:
mkdir -p /run
mount -n -t tmpfs tmpfs /run
mkdir -p /run/{var,lock,shm,udev}
chmod 1777 /run/shm
mount -o nosuid,noexec,nodev -t proc proc /proc
mount -o nosuid,noexec,nodev -t sysfs sysfs /sys
mount -o mode=0755,nosuid -t tmpfs tmpfs /dev -o mode=755
ln -s /run/shm /dev/shm
echo > /proc/sys/kernel/hotplug
/sbin/udevd --daemon (moved /lib/udev/udevd to /sbin for convenience, but even
with /lib/udev/udevd --daemon it still doesn't work)
/sbin/udevadm trigger --action=add --type=subsystems
/sbin/udevadm trigger --action=add --type=devices
/sbin/udevadm settle --timeout=15
I haven't tried udev-18x with a harddisk only boot, as I require initramfs
(disk encryption). For now I've stuck with udev-173, but I want to stay
current with LFS development and move to 18x.
Any suggestions what I could be doing wrong? I have debugging output from
udevd if anyone cares to view it.
Thanks,
IvanK.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] trouble with udev > 173
On Thursday 29 March 2012 00:24:46 Ivan Kabaivanov wrote: > mount -o mode=0755,nosuid -t tmpfs tmpfs /dev -o mode=755 A few minutes after I sent the email I saw what I was doing wrong: mount -o mode=0755,nosuid -t tmpfs tmpfs /dev -o mode=755 should be mount -o mode=0755,nosuid -t devtmpfs devtmpfs /dev -o mode=755 This means that you need CONFIG_DEVTMPFS=y in the kernel config. If this is not mentioned in the book, it should be. Now it works as expected, albeit it takes considerably longer than udev-173, but I'll tinker more and see if I can optimize it. Thanks and sorry for the noise. IvanK. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] 6.62. Udev-186 (Extracted from systemd-186)
On Monday 16 July 2012 20:07:25 Armin K. wrote:
> On 07/16/2012 07:43 PM, Bruce Dubbs wrote:
> > I have updated LFS for the new udev extracted from systemd. The
> > instructions and package locations should be OK and I've regenerated the
> > book's html and other tarballs on quantum.
> >
> > Text still needs to be reviewed in several places (e.g. Chapter 7) and
> > additional testing is needed.
> >
> > This has been an invasive change because it affects the book's
> > generation procedures (aux files, Makefile, etc) as well as the udev
> > instructions.
> >
> > As always, testing and feedback are appreciated.
> >
> > -- Bruce
>
> This might not be a big deal, but it's worth mentioning
>
> Installed programs: accelerometer, ata_id, cdrom_id, collect, mtd_probe,
> scsi_id, v4l_id, udevadm, udevd,
>
> I guess it would be nicer for it to be like (remove , from the end and
> put "and" between udevadm and udevd).
>
> Installed programs: accelerometer, ata_id, cdrom_id, collect, mtd_probe,
> scsi_id, v4l_id, udevadm and udevd
actually if we're gonna be sticklers for grammar and puctuation rules, it's
gotta be:
Installed programs: accelerometer, ata_id, cdrom_id, collect, mtd_probe,
scsi_id, v4l_id, udevadm, and udevd
(notice the comma between 'udevadm' and 'and')
IvanK.
>
> Installed libraries: libudev.{a,so}
>
> IIRC your Makefile installs only shared library.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] Grammar
On Tuesday 17 July 2012 03:20:39 Ken Moffat wrote: [snip] > > [splutters!] but it wastes a byte! > > ĸen [ NOT known for conciseness in my emails, so treat that last > remark 'cum grano salis' (with a pinch of salt, if my latin is > holding up) ] That sounds like the title of a sophisticated porn movie :-) IvanK. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] persistent net rules
On Thursday 26 July 2012 16:32:26 Bruce Dubbs wrote: > I'm trying to write a script to be run in Section 7.2 to initialize > 70-persistent-net.rules. I'm using, as a base, the udev-182 rule > 75-persistent-net-generator.rules. > > I have a problem in that this rule uses a variable SUBSYSTEMS. It is > looking for xen, pci, usb, pcmcia, ieee1394, or ccwgroup (S/390). Most > of these are only used to set a comment in the net rule, but we need to > be able to skip setting the rules completely for xen. > > The SUBSYSTEM variable (without the trailing S) is different. I seem to > be able to get that with: > > $ basename `readlink -f /sys/class/net/eth0/device/subsystem` > pci > > So how can I detect xen? > > Any ideas? > >-- Bruce is this useful? http://projects.puppetlabs.com/projects/1/wiki/Virtual_Machine_Patterns Supposedly, dmesg | grep Xen should report if you're running a xen-enabled kernel. Another google hit: http://stackoverflow.com/questions/4338768/how-do-i-detect-xen-in-a-python- script The interesting bit is the answer: The /proc/xen/capabilities file is what I'm looking for. If it's not there, it's not Xen. If it's there but empty, it's a domU. If it's there and contains 'control_d', then it's dom0. Thanks! – Martin Del Vecchio IvanK. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: SVN-20070706: Step 5.7 Adjusting the Toolchain
Jon Fullmer wrote: > Gentlemen, > > Forgive a novice to this list. I couldn't find any mention of this, > so if it's already been talked about, I'm sorry. > > Step 5.7 of the recent development book shows this step currently to > generate the specs file: > > gcc -dumpspecs | sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools&@g' \ >> `dirname $(gcc -print-libgcc-file-name)`/specs > > When putting this system for a non-x86 (PowerPC, to be specific), I > noticed that this setup is actually wrong. I discovered this when > the compile test of the dummy.c code showed the interpreter as still > being /lib/ld... (as opposed to /tools/lib/ld...). In looking at the > generated stream, I noticed that the "/lib/ld..." mentionings do not > occur at the beginning of the line, as the sed statement requires. I > would think that you would need to remove the ^, like this: > > gcc -dumpspecs | sed 's@/lib/ld-linux.so.2@/tools&@g' \ >> `dirname $(gcc -print-libgcc-file-name)`/specs > > That's what I did, anyway, and it worked great. > > This is my first shot at participating in the Development version, so > if I'm full of it, or I've totally missed something obvious, feel > free to point it out to me. I love LFS, and would love to see it > continue in its greatness. Thanks. > > - Jon Jon, actually there's a notice just before the command you've quoted. This is what I'm referring to: If working on a platform where the name of the dynamic linker is something other than ld-linux.so.2, replace “ld-linux.so.2” with the name of the platform's dynamic linker in the following commands. Refer to Section 5.2, “Toolchain Technical Notes,” if necessary. I've been compiling and running LFS on ppc and sparc for six years already and this notice has been there for at least three or four years. However, further to this discussion, there is actually a problem with the sed command on platforms other than x86. Here's how it is right now: sed '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools&@g' and here's how I would change it so it works everywhere: sed 's@/lib/ld-linux.so.2@/tools&@g' The linker on non-x86 platforms is not defined at the start of a new line, all by itself. Now, can I make another suggestion, can we define a variable LD_LINKER or something like that that we can write into .bashrc and which will default to ld-linux.so.2, but with a note saying that it's something else on different platforms? You can put a disclaimer that building and running LFS on non-x86 platforms is not supported, if you want. So the sed command will look like: sed 's@/lib/$LD_LINKER@/tools&@g' IvanK. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
On Tuesday 24 July 2007 12:10, Matthew Burgess wrote: > On Tue, 24 Jul 2007 11:59:39 -0400, Jeremy Huntwork <[EMAIL PROTECTED]> wrote: > > Matthew Burgess wrote: > >> On Tue, 24 Jul 2007 11:40:24 -0400, Jeremy Huntwork > > > > <[EMAIL PROTECTED]> wrote: > >>> The question is, do we want x86_64 to be a separate book, or simply > > > > roll > > > >>> these small changes into a conglomerate book with x86? > >> > >> I'd certainly prefer them to be in the same book, > > > > My biggest problem with this approach is that it gets to be a nightmare > > to edit. But, it is do-able. > > Hmm, that "nightmare" seems a bit extreme. Certainly, for native x86-64, > which is the only additional target we're contemplating at the moment, > having 2 paragraphs (or small sections at the most) in the book surrounded > in the relevant profiling syntax, doesn't seem too onerous to me. Once in > there, I doubt they'd need amending much - probably only if newer GCC > versions change relevant portions of the specs file. > > Of course, if more targets are desired in the future, our approach may well > need to change, but for now I think x86 & x86-64 native builds capture the > largest section of the LFS audience and anyone else can continue on to > CLFS. > > Regards, > > Matt. Speaking from experience building LFS on x86, ppc (32bit) and sparc (both 32 and 64 bit), except for the dynamic linker and the boot loader, there is little to no difference in the instructions when building on different architectures. So with minimal effort the book can be modified to apply universally. The only big issue is 32bit vs 64bit. As someone already mentioned previously in this thread, there are almost nil benefits in building a 64bit userland. Very few applications can make use of being compiled 64bit. So on ultrasparc (64bit sparc) I've always done what the ultrasparc gurus have suggested for many years, 32bit userland + 64bit cross compiler and 64bit kernel. So if you decide to support x86_64 you'll end up needing a cross compiler just for the kernel. Oh, and you don't actually need multilib glibc either if you go with pure 32bit/pure 64bit userland. Even though 64bit CPUs sold outnumber 32bit CPUs sold at the moment, the installed base of 32bit CPUs is far larger than 64bit CPUs. So I suggest LFS remain for the foreseeable future purely 32bit userland. Ideally, parts of CLFS would be merged into LFS. I never understood the need for CLFS. Presumably it was for people like me who were building LFS on non-x86 architectures. But CLFS is just complicating what is a rather simple procedure. The only useful things in it are the extra packages needed for different architectures. And the instructions to build a cross compiler. Everything else is just LFS. I understand the reluctance of the LFS devs to explicitly "support" non-x86 build as someone has to spend the time and effort to test the instructions on those other architectures. But I still maintain that since you're discussing the inclusion of x86_64, you might as well consider modifying the instructions minimally so that, even if the book doesn't mention non-x86, the instructions will still work. I'm talking about the dynamic linker and the sed command fixing the gcc specs. IvanK. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: sparc64 built from jh branch
On Thursday 11 October 2007 20:39, Jeremy Huntwork wrote:
> Hello,
>
> Well today I finished a sparc64 build based on the jh branch. Has anyone
> else done a native build on sparc hardware adapted from recent LFS?
>
Jeremy,
thanks so much for bringing this up. I've been compiling successfully LFS
since at least 5.0 on ppc and sparc64 and have always wanted to see these two
be semi-supported by LFS proper.
Just a few comments. I prefer to build a 32bit userland and 64bit kernel.
This has been the advice of the ultrasparc gurus for a long time and as
recently as a few months ago there was a discussion either on debian-sparc or
gentoo-sparc that reiterated this original point. I didn't have to modify
the LFS instructions *at all* except to add two or three extra packages
needed by sparcs. However, I had to compile a cross compiler for the 64bit
kernel, which would be a major difference from stock LFS book.
As I wrote in a previous thread on this list, with all due respect and
appreciation to the CLFS devs, I simply can't see a need for this project
other than as a collection of useful tips that can be applied to LFS. You
can build stage5 on a x86 for sparc64 target, but you can't chroot into that.
So then what's the point? Directing people who express interest in other
architectures to CLFS is fine, but it doesn't help them build a full LFS
unless they're building on x86_64 for x86 or some other combination of
architectures within the same arch family (ppc->ppc64, sparc->sparc64).
And while I agree that some devs' reluctance to include ppc, sparc, etc to the
stock book is due to the lack of support, and the lack of developers actively
hacking on these architectures, I wonder if this is an egg-and-chicken
question. There are not enough ppc/sparc/etc devs because LFS does not
officially support ppc/sparc/etc?
I think what Dan suggested and what Jeremy in essence is doing is to start an
experimental support in a separate branch (I thought jh_branch had this goal;
well that and multilib if I'm not mistaken, which is same thing actually) and
see how it matures.
And one more thing -- ipcop, based on LFS, will support ppc and sparc in its
next version. We already have working ppc and sparc support in svn (well
sparc is slightly unbootable, but that's a kernel problem that I'll be
addressing soon, I hope). SVN is based on LFS-dev from april, but it's on my
TODO list to bring it up to LFS-6.3 in the next few weeks when I find some
more time. So, adding support for ppc and sparc64 to LFS is not so difficult
and without a precedent.
ppc boot support for OldWorld macs is quite problematic though and it involves
some voodoo magic. If you do decide to offer some kind of support for ppc I
would advise initially only supporting NewWorld ppc machines (anything since
the original iMac). And on the topic of bootloaders, GRUB2 has experimental
support for ppc and there are plans to support sparc as well. So at some
point in the hopefully near future even that difference will disappear.
And here are the two extra sparc64 packages:
sparc-utils (ftp://ftp.debian.org/debian/pool/main/s/sparc-utils): provides
elf2out, sparc32, prtconf and eeprom
silo: the sparc bootloader
Oh, and one last thing, in order to build a 32bit userland on an ultrasparc
every command in the book that has a bash needs to be sparc32 bash -- this
fools the shell into thinking we're running on a 32bit sparc. Which means
sparc-utils must be the very first statically built package in stage5. This
saves you the trouble of cross compiling.
IvanK.
> I'm hesitating adding in the necessary changes to the branch. When it
> comes down to it, the changes aren't that bad, but I just wanted to
> sound it off someone else first.
>
> * GCC need some compiler flags set for sparc64 - some packages will
> fail otherwise. -mcpu=ultrasparc -mtune=ultrasparc works for my
> processor. So, for chapter 5 and 6, set an environment variable of
> CC="gcc f-mcpu=ultrasparc -mtune=ultrasparc". Most packages pick that up
> from the environment with the configure stage. Some few need it passed
> to make, like 'make CC="$CC"' Programs that require adding a 'CC=' to
> the make command are (IIRC, my notes are at work):
>procps
>bzip2
>sysklogd
>sysvinit
>util-linux
>udev
>
> * util-linux needs a patch in chapter 5 & 6, CLFS calls it a syscall
> patch. Trying to work it into a sed, but the changes CLFS made are a
> little extensive.
>CLFS also created a patch to add a missing header for swapon.c,
> needed in chapter 6: util-linux-2.12r-missing_header-1.patch. But this
> patch could be traded for a sed:
>sed -i '/stat.h/a\#include ' mount/swapon.c
>
> * kbd requires two seds for sparc architectures:
>sed -i '/kbdrate/s/period/rate/' src/kbdrate.c
>sed -i '/kbio.h/d' src/{kbdrate,setleds}.c
>
>
> Anyway, that's it. All things considered, it's not that bad. Also,
> that's it for the ha
/tools gcc specs wrong after readjusting the toolchain in Chapter 6 (kinda long)
Hi all,
I believe there's a untriggered bug in chapter 6, Re-adjusting the toolchain.
We've just entered the chroot, installed the kernel headers and built glibc.
At this point we still only have /tools/bin/gcc. We've just built glibc so we
have it under /lib.
Now we re-adjust the gcc (the /tools gcc, note) specs to use the newly built
linker.
This is the code:
gcc -dumpspecs | sed \
-e 's@/tools/lib/ld-linux.so.2@/lib/[EMAIL PROTECTED]' \
-e '/\*startfile_prefix_spec:/{n;[EMAIL PROTECTED]@/usr/lib/ @}' \
-e '/\*cpp:/{n;[EMAIL PROTECTED]@ -isystem /usr/[EMAIL PROTECTED]' > \
`dirname $(gcc --print-libgcc-file-name)`/specs
this expands to /tools/lib/gcc/i686-pc-linux-gnu/4.1.2/specs (LFS-6.3)
So far, so (kinda) good, and still the problem is not triggered.
Then we go on building the rest of Chapter 6. If this is all you ever use
/tools for, and I'd say about 98% of the people building LFS do just that,
you're ok.
Now, I remember reading in the book that /tools could be kept in case you want
to build more instances of LFS. I quickly scanned the LFS-6.3 but couldn't
find the text. Maybe it was in an older book and has been removed since. But
this is what we do for ipcop, we pack up /tools for speeding up future rebuilds.
Suppose you do want to use /tools to build another LFS and you tar it up (just
/mnt/lfs/tools, not the rest in /mnt/lfs) and you unpack it on a new host and
you chroot into it:
chroot "$LFS" /tools/bin/env -i \
HOME=/root TERM="$TERM" PS1='\u:\w\$ ' \
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \
/tools/bin/bash --login +h
And now you want to build something. Aha:
I have no name!:/# ls /
tools
I have no name!:/#
I have no name!:/# echo 'main(){}' > test.c
I have no name!:/# gcc -v test.c
Reading specs from /tools/lib/gcc/i686-pc-linux-gnu/4.1.2/specs
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.2/configure --prefix=/tools
--with-local-prefix=/tools --enable-clocale=gnu --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-languages=c,c++
--disable-libstdcxx-pch
Thread model: posix
gcc version 4.1.2
/tools/libexec/gcc/i686-pc-linux-gnu/4.1.2/cc1 -quiet -v -isystem /usr/include
test.c -quiet -dumpbase test.c -mtune=pentiumpro -auxbase test -version -o
./ccjh2EpS.s
ignoring nonexistent directory "/usr/include"
ignoring nonexistent directory
"/tools/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/tools/include
/tools/lib/gcc/i686-pc-linux-gnu/4.1.2/include
End of search list.
GNU C version 4.1.2 (i686-pc-linux-gnu)
compiled by GNU C version 4.1.2.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: bde1f24b4119042caf7e7373b8ff1063
/tools/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/bin/as -V
-Qy -o ./ccSRA7oz.o ./ccjh2EpS.s
GNU assembler version 2.17 (i686-pc-linux-gnu) using BFD version 2.17
/tools/libexec/gcc/i686-pc-linux-gnu/4.1.2/collect2 --eh-frame-hdr -m elf_i386
-dynamic-linker /lib/ld-linux.so.2 crt1.o crti.o
/tools/lib/gcc/i686-pc-linux-gnu/4.1.2/crtbegin.o
-L/tools/lib/gcc/i686-pc-linux-gnu/4.1.2
-L/tools/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/lib
./ccSRA7oz.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed
-lgcc_s --no-as-needed /tools/lib/gcc/i686-pc-linux-gnu/4.1.2/crtend.o crtn.o
/tools/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/bin/ld:
crt1.o: No such file: No such file or directory
collect2: ld returned 1 exit status
I have no name!:/# gcc -dumpspecs > specs
I have no name!:/# diff -Naur /tools/lib/gcc/i686-pc-linux-gnu/4.1.2/specs specs
--- /tools/lib/gcc/i686-pc-linux-gnu/4.1.2/specs2007-09-19
03:10:39.0 +
+++ specs 2007-12-10 06:55:36.0 +
@@ -15,7 +15,7 @@
as %(asm_options) %|.s %A }
*cpp:
-%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT} -isystem /usr/include
+%{posix:-D_POSIX_SOURCE} %{pthread:-D_REENTRANT}
*cpp_options:
%(cpp_unique_options) %1 %{m*} %{std*&ansi&trigraphs} %{W*&pedantic*} %{w}
%{f*} %{g*:%{!g0:%{!fno-working-directory:-fworking-directory}}} %{O*} %{undef}
%{save-temps:-fpch-preprocess}
@@ -108,7 +108,7 @@
*startfile_prefix_spec:
-/usr/lib/
+
*sysroot_spec:
--sysroot=%R
@@ -133,7 +133,7 @@
elf_i386
*dynamic_linker:
-/lib/ld-linux.so.2
+/tools/lib/ld-linux.so.2
*link_command:
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:%(linker) %l %{pie:-pie} %X
%{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r}%{s} %{t} %{u*} %{x} %{z} %{Z}
%{!A:%{!nostdlib:%{!nostartfiles:%S}}}%{static:} %{L*} %(mfwrap)
%(link_libgcc) %o %(mflib)
%{fprofile-arcs|fprofile-generate|coverage:-lgcov}
%{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}
%{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}
I have no name!:/#
So, we should not overwrite the /tools gcc specs in Chapte
Re: /tools gcc specs wrong after readjusting the toolchain in Chapter 6 (kinda long)
On Monday 10 December 2007, Chris Staub wrote:
> Ivan Kabaivanov wrote:
> > Hi all,
> >
> > I believe there's a untriggered bug in chapter 6, Re-adjusting the
> > toolchain.
> >
> > We've just entered the chroot, installed the kernel headers and built
> > glibc. At this point we still only have /tools/bin/gcc. We've just built
> > glibc so we have it under /lib.
> >
> > Now we re-adjust the gcc (the /tools gcc, note) specs to use the newly
> > built linker.
> >
> > This is the code:
> >
> > gcc -dumpspecs | sed \
> > -e 's@/tools/lib/ld-linux.so.2@/lib/[EMAIL PROTECTED]' \
> > -e '/\*startfile_prefix_spec:/{n;[EMAIL PROTECTED]@/usr/lib/ @}' \
> > -e '/\*cpp:/{n;[EMAIL PROTECTED]@ -isystem /usr/[EMAIL PROTECTED]' > \
> > `dirname $(gcc --print-libgcc-file-name)`/specs
> >
> > this expands to /tools/lib/gcc/i686-pc-linux-gnu/4.1.2/specs (LFS-6.3)
> >
> > So far, so (kinda) good, and still the problem is not triggered.
> >
> > Then we go on building the rest of Chapter 6. If this is all you ever
> > use /tools for, and I'd say about 98% of the people building LFS do just
> > that, you're ok.
> >
> > Now, I remember reading in the book that /tools could be kept in case you
> > want to build more instances of LFS. I quickly scanned the LFS-6.3 but
> > couldn't find the text. Maybe it was in an older book and has been
> > removed since. But this is what we do for ipcop, we pack up /tools for
> > speeding up future rebuilds.
> >
> > Suppose you do want to use /tools to build another LFS and you tar it up
> > (just /mnt/lfs/tools, not the rest in /mnt/lfs) and you unpack it on a
> > new host and you chroot into it:
> >
> > So, we should not overwrite the /tools gcc specs in Chapter 6, but keep a
> > copy of it in, say, /tools/lib/gcc/i686-pc-linux-gnu/4.1.2/specs-tools
> > and rename it back after we build gcc in Chapter 6. Then we can
> > guarantee that /tools is self-sufficient. Maybe we should do a pass 2 of
> > the readjustment in Chapter 6. This is what I'll do for ipcop, but if
> > you come up with a better solution, I'd rather stick with LFS book.
> >
> > IvanK.
>
> 1. The gcc in /tools, built in GCC pass 2, should be linking to /tools
> by default anyway, so if you want to re-use /tools after re-adjusting
> the toolchain you shouldn't have to do anything with the specs file
> other than removing it.
>
> 2. The other problem is that the linker has also been modified, so you'd
> also have to reverse the commands to switch /tools/bin/ld and ld-new.
>
> 3. There is a warning about this in both 6.3 and dev LFS books, on the
> "Changing Ownership" page at the end of chapter 5...
>
> http://www.linuxfromscratch.org/lfs/view/development/chapter05/changingowne
>r.html
>
> Caution
>
> If you intend to keep the temporary tools for use in building future LFS
> systems, now is the time to back them up. Subsequent commands in chapter
> 6 will alter the tools currently in place, rendering them useless for
> future builds.
Chris,
so that's where the text was -- my memory had selectively remembered the part
about using /tools for future builds and blocked the text about chapter6
altering /tools.
Sorry for sounding the alarm without merit :-)
Thanks,
IvanK.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [ANNOUNCE] Next Generation build method
On Monday 10 December 2007 16:41, Greg Schafer wrote: > Hi, > > While we are talking about the evolution of LFS, now seems like a good > time to announce to the wider LFS community the availability of a Next > Generation build method. > > The main advantages of the new method are: > > - sane x86_64 bi-arch (aka Multilib) > - no more weird host issues like those experienced recently by Alexander >on Debian Lenny > - when targeting x86_64, it doesn't matter whether the host is running >32-bit or 64-bit kernel or userland or combination of both, it just >works. Greg, this is perfect timing -- we're mulling over the same thing for ipcop, however our --target will still be i486-unknown-linux-gnu (no multilib). But I've found it such a mess adapting LFS build instructions to x86_64 build hosts, that I decided to just build a cross-compiler first to bootstrap the build. > > The new method is actually just a variation on the current build with > these key differences: > > - Pass 1's of Binutils and GCC are built as cross tools to form a cross >toolchain > - Temptools Glibc is cross compiled using the cross toolchain, with >everything after this built natively > - GCC is no longer bootstrapped. We've been kidding ourselves for years >on this issue. Detailed explanation later right, I was planning on doing the same thing by mixing the right parts of CLFS into current LFS, but having all the necessary instructions in LFS proper is ideal. I was thinking that we'll end up cross compiling even on 32bit build hosts just to keep the build instructions universal. Will have to see how you solved this. We're also using the linux32 shell wrapper to "emulate" x86. > > The new work is not yet finished, but I can say with good authority that > folks wanting x86_64 bi-arch will soon no longer have to refer to CLFS. > > Some background mailing list posts: > > http://www.diy-linux.org/pipermail/diy-linux-dev/2007-October/001123.html > http://www.diy-linux.org/pipermail/diy-linux-dev/2007-October/001125.html > http://www.diy-linux.org/pipermail/diy-linux-dev/2007-November/001161.html > > The Work-In-Progress new method is published here. Please heed the > warning, and note also that extra environment setup is required (detailed > earlier in the document). > > http://www.diy-linux.org/reference-build/temptools2.html > will have a look into this. Thanks, IvanK. > 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: [ANNOUNCE] Next Generation build method
On Monday 10 December 2007, Greg Schafer wrote: > Hi, > > While we are talking about the evolution of LFS, now seems like a good > time to announce to the wider LFS community the availability of a Next > Generation build method. Greg, is there another mailing list where you discuss matters surrounding the new build system, or will the discussion be conducted here? Tnaks, IvanK. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LiveCD or No LiveCD?
On Monday 25 February 2008 10:37, Jeremy Huntwork wrote: > Hello Everyone, > > It has recently been suggested to me that the LFS LiveCD project be > killed. The main arguments for this are, essentially: > > 1) It is currently unmaintained > 2) It removes the essential prerequisite of being able to configure a > Linux system > 3) It leads to less testing from other hosts > 4) A seeming lack of community interest in contributing. Especially, > essential testing (and reports on the results of tests!) on varied > hardware does not seem to be taking place > > As you may guess, I have mixed feelings about this. But after reflecting > on it a bit, my hesitancy to agree comes mostly from personal attachment > to the CD and perhaps not what is best for LFS. > > At this point I need community input. I realize that many of you may use > and appreciate the CD, just as I do. But realistically, this project > will die of its own if it does not get some help. And if that happens, > then LFS would be better off removing the dead weight. > > I have some energy and some ideas to put back into the project, but only > if I get some help with development and testing. I need to know two things: > > * Does the community still want the LiveCD project? (Consider that a > couple of the arguments above imply that the LFS LiveCD by its nature is > degrading the quality of LFS) > > * If so, is the community prepared to lend help in keeping it alive? > > If the answer to both questions is not a solid yes, I'm afraid that > we'll have no choice but to kill the project. > > -- > JH Jeremy, I say drop the project. Let me explain why. There are generally speaking two types of LFS users -- first time users and veteran users. We can assume for both groups that these are experienced linux users -- the fact that they've heard of LFS and are brave/confident enough to try it says a lot. These are people who are comfortable enough and knowledgeable enough to find answers to problems they come across compiling LFS on their specific host architecture/distribution. These are people who can boot with any of the other live cds out there and compile LFS. There is always the chance that an inexperienced user might stumble upon LFS. But this type of user would not be too comfortable with a very limitted live CD such as the LFS live CD. This type of user would most likely have achieved a level of comfort with the polish and nice features of an already installed distribution to venture into the uncharted waters of a live CD. The best approach is to wisely use the limitted manpower LFS has and channel it into LFS itself rather than dissipate it over a multitude of spin-off projects. We should hitch our wagon to an existing live cd platform -- be it ubuntu or knoppix or one of the other good ones there. No need to reinvent the wheel. The problem with using someone else's live cd is that there probably won't be enough, if any, development tools included on the CD. But you can include a prebuilt toolchain and the sources for the current LFS version and have the user chroot into that and just continue from chapter 6. Like we do it in IPCop, as Gilles already wrote. IvanK. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Bring up multi-arch again
On Saturday 01 March 2008, Thomas Trepl wrote: > Hi all, > > within the current discussion i try to start a balloon again which is named > multi-platform. I do not mean it in the way of cross-compiling but building > a LFS system for the current running maschine. Which ever this machine is. > Staying on the same architecture, the differences between the architectures > compared to others are not sooo much, i think (am i right here?). Staying > on the arch i mean, that i'm going to build a PPC-LFS on a PPC, or a > x86-LFS on a x86. the most different parts is the name of the dynmic > linker, i think, and the option on boot loaders (lilo, grub, yaboot, > whatelse). > > What do you think about having a a bit closer look to this? A separate > section about choosing the boot-loader? And of course a section about > required packages for a specific arch - if there are one? > > -- > Thomas I second that with this clarification -- I'd like to see a sort of merge between LFS and CLFS. What I mean: take the CLFS instructions and put them in LFS but not the cross-arch-compiling stuff, but just the arch specific stuff and make it a native build. From previous threads I've seen enough interested people in natively building LFS on ppc, sparc, alpha, mips, etc. I think LFS should cooperate more closely with CLFS (and DIY when Greg feels the time is right) so that the instructions work on more arches than just x86 or x86_64. With the current non-book dynamic approach this can be easily achieved. I think since we're talking about a major new direction for LFS now's the time to reevaluate this. Please do. LFS is not x86 just as Linux is not x86. I think it's imperative that the devels of LFS, CLFS, HLFS, and DIY (am I forgetting any other?) should all be involved in this discussion and try to pool their strengths together and move in one direction rather than pull the project in different directions. IvanK. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Poll about package management
On Monday 03 March 2008 04:55, Alexander E. Patrakov wrote: Alexander, I've added three new options that are important to me and to IPCop. Thanks, IvanK. [ ] I am an editor of LFS or one of the related projects [X] I use LFS as my primary Linux system [X] I use LFS on more than one PC (including virtual machines) [ ] I deviate a lot from LFS (not counting package updates as deviations) [ ] I deviate a lot from BLFS (not counting package updates as deviations) *[X] I use LFS on more than x86 (x86_64, ppc, ppc64, sparc64) I use the following package management technique: (X) It's all in my head! (X) I trust the lists of files in the book ( ) I rebuild everything every three months or less, so there is no need to manage anything! ( ) Installation script tracing with installwatch or checkinstall ( ) Installation script tracing with some other tool ( ) Timestamp-based "find" operation ( ) User-based ( ) RPM ( ) DPKG ( ) Simple binary tarballs produced with DESTDIR ( ) Other DESTDIR-based method of producing binary packages (X) Other -- a diff between filesystem state from before and after a package installation (not good with overwritten files) *(X) I rebuild everything every August after a LFS release I *would like to* use the following features provided by a package manager: [X] Knowing where each file comes from [X] Clean uninstallation of a package [X] Removal of obsolete files when upgrading to a new version [X] Ability to upgrade toolchain components (most notably, glibc) painlessly [ ] Ability to revert mistakes easily and quickly by installing an old binary package [X] Ability to compile once, deploy on many macines [X] Scripting the build I will ignore the future LFS advice on package management if it [ ] Can't be applied on a busy machine where many files are accessed/modified everyy minute [X] Can't be used to transfer packages to another machine [ ] Interferes with config.site files described in DIY-linux [X] Will clobber configuration files wen upgrading package versions [ ] Doesn't explain how to package software beyond BLFS [ ] Requires learning another language/syntax besides bash shell syntax [ ] Exists at all *[X] Breaks builds on x86_64, ppc, ppc64, sparc64 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
package management still a consideration?
I was wondering if the devs are, perhaps, working behind the scenes on putting together some PM as per the long thread(s) from a few weeks ago. Is there still interest in and momentum behind this idea? Thanks, IvanK. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
