similar to: Bug#409271: initramfs-tools: NFSv4 not supported for root fs

Hi everybody and thanks to those persons who make klibc being possible. I am booting a lessdisks system from a server. I have got it in NFSv3 but I would like use the features of NFSv4. I am using initramfs-tools so I have in my initrd.img the utility nfsmount wich make possible booting in NFSv3. I would like know if exists some version of nfsmount or some patch or, if does not, some program (a

Hi, The following set of patches is intended mostly to improve ipconfig and nfsmount compatibility with glibc. The context: I'm working on yaird, an alternative to mkinitrd, and currently implementing nfs root file systems. This is based on ipconfig and nfsmount from klibc, with a rewritten version of kinit. Users should be able to build the package with vanilla glibc, since klibc is not

There is a conflict in glibc between <linux/in.h> and <netinet/in.h>: one defines protocols with an enum, the other does the same, but adds a self-define for every enumerated value. #define IPPROTO_IP IPPROTO_IP This means the two cannot be mixed, and since loads of include files refer to <netinet/in.h>, effectively <linux/in.h> cannot be used with glibc. Since

2ad780978b7c0c3e7877949f098cbd06e7c73839 broke klibc build MNTPROC_MNT and MNTPROC_UMNT no longer defined. usr/kinit/nfsmount/mount.c: In function ?mount_call?: usr/kinit/nfsmount/mount.c:179: error: ?MNTPROC_MNT? undeclared (first use in this function) usr/kinit/nfsmount/mount.c:179: error: (Each undeclared identifier is reported only once usr/kinit/nfsmount/mount.c:179: error: for each function

Hi Timo, I just read about NFSv4 now being included in SuSE and Redhat Enterprise versions, and although I don't use it myself, wondered how this will impact Dovecot for those using it? Will it make life easier? Or is it even supported currently? Just curious... thanks... -- Best regards, Charles

Without this patch gcc 4.6 warns: KLIBCCC usr/kinit/nfsmount/dummypmap.o usr/kinit/nfsmount/dummypmap.c: In function 'dummy_portmap': usr/kinit/nfsmount/dummypmap.c:191:13: warning: array subscript is below array bounds [-Warray-bounds] Signed-off-by: Greg Thelen <gthelen at google.com> --- usr/kinit/nfsmount/dummypmap.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)

Hi, I've never been using NFS before, but I'm going to need it. I gathered some documentation (Deployment Guide, RHEL 5 Unleashed, general NFS docs) and I have a few machines to experiment with. After about two hours of reading and experimenting, I must admit the documentation is confusing, to say the least. Although some step-by-step tutorials are provided, none of them work. For

Various coding style fixes checkpatch warns about. The goal is not to be 100% checkpatch compliant, but to have more consistent coding style. As this is a trivial patch serie, will land in 24 hours in klibc git, unless of course ml review hits a bugger. Checked with size(3) that the generated kinit, fstype, ipconfig and nfsmount are the same. maximilian attems (4): [klibc] ipconfig: reduce

Hey all, bug report time. I started tracking this down, but am at a bit of a loss for time, so I figured I'd report over this list to see if anyone else has the time to fix this or at least find the error. When calling nfsmount on it's own, say "nfsmount 1.2.3.4:/home/nfs /root" it works just fine, however, when calling nfsmount_main from within kinit (via nfsroot=), things get

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: ---

some files depend on nodes.h, but there is no dependency for that fact. olaf@mandarine:~/klibc-0.87> grep -Er 'include.*nodes.h' ash/ | sed 's-^[^/]\+/\([^.]*\).*-\1.o-' | xargs echo OBJ_NODES = OBJ_NODES = cd.o eval.o exec.o expand.o jobs.o main.o nodes.o options.o parser.o redir.o show.o trap.o var.o make spotless doesnt work reliable, the patch adds a few more targets. Is

nfsmount doesnt work anymore for me. This patch fixes at least udp nfs mounts. tcp does still hang. client and server is 2.6. --- /dev/shm/bindresvport.c 2003-12-08 02:33:24.000000000 +0100 +++ klibc/inet/bindresvport.c 2004-01-06 21:05:02.283779072 +0100 @@ -23,7 +23,7 @@ int bindresvport(int sd, struct sockaddr if (sin == NULL) { sin = &me;

Hi all. Proposal for directory structure in the kernel: usr/include <= _all_ include files usr/include/{net,sys,..} usr/include/arch/$(ARCH) <= arch specific include files *1 usr/klibc <= klibc files usr/klibc/arch/$(ARCH) <= arch specific config and files except include files usr/kinit <= program integrated in the kernel usr/kinit/nfsmount <= used by kinit,

I have seen some talk about this but have not seen any answers. I know this is a problem on CentOS 7.1 and I also think it is a problem on CentOS 7.0. Basically if I have an NFS client only config - meaning that the nfs-server.service is not enabled then I have to wait 60 seconds after boot for the 1st NFSV3 mount to succeed. What I can surmise is the following. I attempt to perform a NFS

Hi, I'm resending since I got no feedback: I assume that the message was lost... The attached patch fixes a few bugs related to the spoofing portmapper used by nfsmount. Regards, Louis -- Dr Louis Rilling Kerlabs Skype: louis.rilling Batiment Germanium Phone: (+33|0) 6 80 89 08 23 80 avenue des Buttes de Coesmes http://www.kerlabs.com/ 35700 Rennes -------------- next part

I have a script that syncs my backups to an NFS mount every day The script works fine, without any errors, but there is a problem when it comes to some large files Let's take my pst file (8.9 gig) as an example Source: du -hs mypst.pst 8.9G mypst.pst ls -alh mypst.pst -rw-rw---- 1 me me 8.9G Jan 25 17:07 mypst.pst That seems OK Let's do that on the destination: du -hs mypst.pst

In case anyone's interested, I followed up in the linux-nfs mailing list: https://marc.info/?l=linux-nfs&m=156887818618861&w=2 Thanks, Alkis On 9/15/19 10:51 AM, Alkis Georgopoulos wrote: > I think I got it. > > Both nfsmount and `mount -t nfs` now default to rsize/wsize = 1 MB. > By lowering this to 32K, all issues are gone, even with the default > timeo=7. And

Hello, I have confirmed that the recently-reported vulnerability in Elm is also present in Elm-ME+ and thus also in Debian GNU/Linux version 1.2, prerelease version 1.3, and development tree "unstable". Below is a short diff to correct the problem. Debian GNU/Linux 1.2.x uses stock Elm 2.4pl25. Users of that version of Elm should upgrade to Elm-ME+ as detailed below. Debian 1.3

New clangs emit some warnings. The code isn't wrong, but should be updated to prevent warning creep. Bill Wendling (3): [klibc] dash: shell: Fix clang warnings [klibc] dash: shell: Fix clang warnings about format string [klibc] Kbuild: use an enum to silence a clang warning usr/dash/eval.c | 6 +++--- usr/dash/jobs.c | 2 +- usr/kinit/nfsmount/dummypmap.c

Hi, When mounting a NFS share and an error occurs for some reason, the NFS share is not unmounted correctly: the local path is used instead of the remote path in the umount_v[23]() call. This patch fixes this. I found this while debugging some problems mounting the root file system on NFS in a test system; I saw this in the logs (/mnt/duplicated is the legitimate remote path): Jun 21