similar to: klibc-1.5 released

I'm thinking it's time to release klibc-1.5; however, before releasing klibc-1.4.31 as klibc-1.5, I wanted to give a call to see if there is anything that either really needs to be done, or any bug reports I've missed... -hpa

Hi all, I realize I have been a bit MIA lately, but I'm going to try to make forward progress again on klibc. I have pushed the current integrated tree up to 2.6.21-rc2; so far, no functional enhancements, but I'm looking at the following: - Mount-by-label/mount-by-uuid. - Ability to fall back on different roots. - nfsroot on NFSv4. - nfsroot over IPv6, as soon as the kernel supports

Well, as of right now, both Linus and Andrew have rejected klibc in the kernel based on "it doesn't add anything new" (Linus) and "lack of interest" (Andrew). It seems that there is little hope of getting it into the kernel any time soon, unless there is additional features, and/or people start actively asking for it. I would appreciate hearing suggestions. The

This seem to be a good timing taking up the integration of klibc in the kernel again. Based one klibc-0.152 and klibc.bkbits.net/2.5-klibc I will take a shot of it. I will focus on getting the library compiled (should be pretty straighforward). Next two steps are: 2) Adding minimum applications to the kernel (if any) 3) Support applications outside the kernel I will put my work on bkbits.net

There are two hosted BitKeeper repos: klibc is a BK clone of the klibc CVS tree 2.5-klibc is my attempts to integrate klibc into the kernel If you want commit access to either repo, send me an ssh1 public key. <b

I just pushed out klibc-1.2.1; it actually has a working kinit. There are still pieces missing, but at least it works for ipconfig+nfsroot, which has been my test configuration. There is code to handle initrd already in kinit, but it hasn't been tested and so is almost certainly broken; I think the code to load a ramdisk from a floppy or other block device is not yet there. -hpa

The tools for raidN (mdadm and friends) don't seem to compile with klibc. Has anyone tackled that, lvm or evms yet in a klibc-based initramfs, or do you usually include uclibc or something when it comes time to get fancy (also, looking ahead to crypto-root and such) Tks, Jeff Bailey

kinit/nfsmount.c:mount_nfs_root() should use the bootpath specified by bootp/dhcp. If the "nfsroot" option is specified then it overrides the boot server bootpath and a message indicating the override is printed. --- klibc-0.194/kinit/nfsroot.c.orig 2005-01-05 04:13:47.043897880 -0700 +++ klibc-0.194/kinit/nfsroot.c 2005-01-05 04:13:09.316633296 -0700 @@ -66,34 +66,21 @@ const int

Commit-ID: c4b811a1e4647224ddc717fac59900d16d0e9d4d Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=c4b811a1e4647224ddc717fac59900d16d0e9d4d Author: Baptiste Jonglez <baptiste.jonglez at imag.fr> AuthorDate: Thu, 14 Sep 2017 09:22:21 -0700 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Wed, 2 Jan 2019 03:08:04 +0000 [klibc] nfsmount: support

This patch adds support for swap detection to fstype (to be applied on top of the previous luks patch). The patch is now against klibc's git tree instead of klibc-1.2. Signed-off-by: David H?rdeman <david@2gen.com> -- fstype.c | 42 ++++++++++++++++++++++++++++++------------ swap_fs.h | 18 ++++++++++++++++++ 2 files changed, 48 insertions(+), 12 deletions(-) --------------

Hi, I've been messing around with the early userspace for the last couple days. What are the goals of early userspace? Is the end goal to use it as an initrd replacement or is it simply to do all the mounting (nfsroot, initrd, hard disk) that is currently done in init/do_mounts*? thanks mh -- Martin Hicks Wild Open Source Inc. mort@wildopensource.com 613-266-2296

Peter, we found that nfs over udp will corrupt data under very extrem load, there is no way to fix it due to the way how UDP works. TCP will not have these problems. I also wonder why the package size is only 1k. Everyone who wishes a slow connection can pass the desired options via the kernel cmdline. Everyone else prefers probably the fast mount. The defaults should look more like that: ---

Hi, Greg - The latest set of klibc work is all accessible from http://www.speakeasy.org/~bos Here's a brief description of each part. The patches are as independent as possible, and are in BitKeeper format. * ipconfig-2.5.69.patch removes ipconfig from the kernel, and prevents CONFIG_ROOT_NFS from working. * nfsroot-2.5.69.patch removes nfsroot from the kernel. *

OK guys, I've been communicating with Greg KH and I think I'm ready to tackle getting the early userspace stuff to a more functional level than it stands today (quite a commitment there, eh?). Before I get started, I wanted to list the major points I see that need to be done to make sure I'm not duplicating anyone else's efforts, or reinventing something that's already

Hi, I've already submitted the attached patch to the Debian BTS: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480994 Basically it fixes the argument parsing when running something like "mount -t ext3,ext2...". If that is fixed, I assume that "-t auto" could also be faked by replacing auto with a long list of fs types (or running "fstype" in the

[ adding klibc ml to cc ] On Thu, Feb 01, 2007 at 09:29:52AM -0600, John Goerzen wrote: > > It appears to be largely undocumented, but a review of > /usr/share/initramfs/scripts/nfs shows that this package supports NFSv2 > and v3 only. I don't know why v4 isn't supported. yup, this needs nfs v4 support in klibc nfsmount. would be could to get that soon postetch, but someone

Hi all, in a somewhat unrelated discussion, a user wanted to run gpg in an initramfs generated by the Debian initramfs-tools package. Whether that is a good idea or not is a different discussion, but he noted that /dev/tty won't work in the initramfs because no controlling console has been setup yet (I think init is the first program to do so). So, I was wondering if it might be a good idea

As some people have requested, here is klibc as a historyless patchset against 2.6.17. The patchset consists of two parts: changes to the main kernel code taken straight from the git history (as it is rather few patches), and additions, grouped by rough divisions. The majority of the patches are independent in the sense that they should apply independently, but Makefile/Kbuild files may have to

coding style fixes. FIXME: check that compiled bin the same1!! --- usr/kinit/initrd.c | 3 ++- usr/kinit/kinit.c | 12 ++++-------- usr/kinit/kinit.h | 20 ++++++++++---------- usr/kinit/name_to_dev.c | 6 +++--- usr/kinit/nfsroot.c | 5 ++--- 5 files changed, 21 insertions(+), 25 deletions(-) diff --git a/usr/kinit/initrd.c b/usr/kinit/initrd.c index

The following patch swaps the command line handling of kinit. It seems apparent that, if one were to call kinit like so: kinit root=/foo/bar They would be attempting to override the /proc/cmdline. As it stands, kinit parses the /proc/cmdline *first*, meaning the above does not work. Just for a simple use case: User A has an encrypted root device, root=/dev/hda3 Some init scripts detect this,