Re: Glibc-2.6.1/2.5.1
On 7/12/07, Dan Nicholson [EMAIL PROTECTED] wrote: http://www.linuxfromscratch.org/patches/downloads/glibc/glibc-2.5-branch_update-3.patch It'd be nice if people could test this out so maybe someone can say Please release 2.5.1. That would nicely wrap up LFS-6.3 (hint, hint). I tested this out (non-bootstrap so far). I get one failure in nptl/tst-cancel1.out. This is a known failure, which needs gcc-4.2 to run correctly (I think). http://www.sourceware.org/ml/libc-alpha/2006-09/msg00039.html Hardware is a Core2 Duo running linux-2.6.20.14. Haven't done a full bootstrap yet, but will soon. I will probably update try on a more recent kernel, too. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
On 7/14/07, Randy McMurchy [EMAIL PROTECTED] wrote: Dan Nicholson wrote these words on 07/14/07 12:52 CST: It's their stable branch which contains many backported bug fixes and they're not producing any more releases. Is it better to use a known buggy glibc-2.5? If glibc-2.5.1 was imminent, I'd say wait, but recent history would suggest it's not likely. I'm just mentioning it, doesn't really matter to me. However I'm curious about something else. These branch update patches are huge, these are all bug fixes? There's no enhancements in these patches? I'm asking because I don't know the answer, but it would be nice to know. As far as I know, yes. But I'd be implying a lot more knowledge of glibc internals than I have if I tried to claim that. You can see all the changes here: http://sourceware.org/cgi-bin/cvsweb.cgi/libc/ChangeLog?cvsroot=glibconly_with_tag=glibc-2_5-branch This is also what would become glibc-2.5.1 if it's released. http://linuxfromscratch.org/pipermail/lfs-dev/2007-July/059606.html http://www.sourceware.org/ml/libc-alpha/2007-07/msg00045.html -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: initramfs support
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Alexander E. Patrakov wrote: I wrote: Bryan Kadzban wrote: Anything else that it should support? 1) Some users may want to use EVMS instead of LVM2. The packages conflict, but on-disk formats are the same. Unfortunately, I am not an EVMS specialist (and it is not on the CD), so no immediate help is available. Well, my impression of EVMS is that it's just a different toolkit on top of the LVM2 kernel driver (or at least, that's all it is *now*; it used to be a different driver too). I'd be inclined to punt it, at least for now. (The problem with that is, I bet the metadata is different, so it's not like we can say oh just use the LVM2 stuff. That'd be a problem.) 2) Software RAID (with the help of mdadm), even if the disk driver is a module (so that in-kernel autoassembly doesn't work). LVM2 on RAID. OK, I almost have LVM2-on-mdadm-RAID working. I just used different partitions on a single qemu disk for testing -- even though that's specifically not recommended (because if a disk dies, you lose at least 2 partitions), that doesn't apply in qemu, and I was just testing anyway. I created 5 partitions (2 for a RAID1 for /boot, and 3 for a RAID5 to hold an LVM PV that would hold / and swap). I named the arrays boot and main, so I got /dev/md/boot and /dev/md/main devices. (Along with /dev/md_boot and /dev/md_main, but I didn't use those.) The initramfs works fine (as long as I use v1.0 metadata, at the end of the disk) -- it assembles the RAID1 (although it isn't needed) and RAID5 just fine, and with a few tweaks to /etc/lvm/lvm.conf (filtering out the non-RAID devices), vgchange -ay finds everything on the RAID devices as well. The one sticking point is the same sticking point I had with dmraid -- how do you get the /dev/md/* named device nodes to be recreated once the initramfs is finished, from the system bootscripts? Device-mapper has dmsetup mknodes, and LVM2 has vgmknodes, but I can't find anything similar in mdadm. The filter that I have makes the LVM scan work fine (since the system does create /dev/md126 and /dev/md127 devices), but I'd rather have it create the names, if possible. I suppose the boot script could manually create them, using mdadm - --detail and some shell magic to generate the name. If there's no pre-built way to do it, I'll start hacking on that. 3) NFS root (including v4, which is not on the CD). I have no idea what'd even be required there, but I'll start doing some reading after I get the md and crypto stuff working. 4) Encrypted root (with dm-crypt, cryptoloop, or loop-aes). Note that this requires loadkeys and keymaps in the initramfs. Also, I have never tried this, but the 6.2-5 CD (not 6.3-X!) includes support for loop-aes. loadkeys/keymaps -- I assume that's just while typing in the passphrase, right? I'll see what I can find on this after md is fixed. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGmmj3S5vET1Wea5wRAx5rAJ0ZUELhO/6XgnV3oPLJrLl7EpAMRgCgkmJ6 EF5cj7Qj81QuD7WPKY5+N3U= =ACO2 -END PGP SIGNATURE- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Preparing for 6.3 Release
Dan Nicholson wrote: I think most of the issues brought up in this thread have been addressed. I'd like to see if glibc-2.5.1 will happen, but we can certainly just use the latest branch_update patch. The LiveCD is still kind of up in the air, but I think most of the big concerns have been addressed, and now Jeremy is back on the prowl helping out. Too many things to respond to in this thread... Since I'm mentioned here, seems a good place to reply. Being a little out of the loop these days, I'm not really in much of a position to speak about what things need to be done to get 6.3 ready. Still, it's my opinion that we should get a release out sooner rather than later. I'll help out wherever there's a need... As far as a native x86_64 build is concerned, I think that would be a good candidate for 7.0. It really shouldn't be that big of a deal to make generic commands that work for both native builds - there would be a handful of commands specific to whichever platform you're building, but most would be the same. And the LiveCD could be useful for that end, as well, since these days it comes with the option to boot a 64-bit kernel. Just making some noise and pitching in my half a cent or so. ;) -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
