similar to: [bug] init arguments handling

Following mail advice from maximilian attems (thanks). The following patch changes 2 parts of kinit's command line parameter handling. 1) Parse command line parameters passed to kinit *before* /proc/cmdline, in order to allow overrides 2) Pass this resultant command line to the init program, rather than forcing the kinit caller to pass all /proc/cmdline parameters to the kinit call.

hello hpa, due to arch x86 merge and stricter linitian. lintian complained about empty dirs in the -dev headers package. hadn't seen that warning yet, so below is the fix. ah and that other patch was in some other branch.. please pull latest unless sam has a reservation git pull git://git.debian.org/~maks/klibc.git maks for the changes: Aaron Griffin (1): [klibc] kinit: skip md

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

In case people here don't follow the udev mailing list, udev seems to be quasi-dropping klibc support. Well, see the forwarded message below. As I don't agree with the "omg udev is complex! use glibc!" rationale, I want klibc and udev to remain working with each other.... Assuming some minor breakage in the near future, is klibc open to accepting patches for "basic C

hello hpa, nothing particular stands out, just syncing with latest Debian upload and subsequent patch emails. please review merge or nack. thanks :) maks git pull git://git.debian.org/~maks/klibc.git maks for the changes: Aaron Griffin (1): [klibc] kinit: skip md assembly if mdX exists Colin Watson (1): [klibc] mount/umount FUSE support Harald Jenny (1): [klibc] fstype:

The following patch will ignore already configured md devices in kinit. The rationale is that, if an md device already exists, it was previously assembled by some other tool (e.g. mdadm) and should remain there. Currently, kinit removes it and attempts to recreate it, which can cause all sorts of issues, especially in the situation that, the md device is further encrypted and/or is an lvm

Hello, I don't know if this is bug-worthy or not It can be fixed in numerous places, but I think it might make the most sense to do it here.... kinit uses /dev/root to mount the rootfs. In normal userspace, this causes the root system to be displayed twice in apps like Nautilus, as /proc/mounts lists rootfs on /dev/root, in addition to the real info (e.g. ext3 on /dev/hda3). This is

I'm not sure when exactly this started, but currently when I specify a ramfs image via the initrd line in grub, kinit picks it up as an initrd and tries (and fails) to unpack it and run linuxrc from it. I'm assuming this is not the intended behavior. Can anyone point me into the proper direction for unpacking an initramfs image ontop of the in-kernel image? Currently, I am using kernel

I must profane ignorance of complicated filesystem stuff, so feel free to call me out here. Booting a root ext3 drive produces the following message at boot: kinit: trying to mount /dev/root on /root with type ext2 EXT2-fs warning (device hda3): ext2_fill_super: warning: mounting ext3 filesystem as ext2 When remounted rw by init, everything looks fine: $ mount | grep hda3 /dev/hda3 on / type

I don't really understand the necessity of the /arch.cmd file to be parsed before /proc/cmdline. It seems simpler to just parse the program args first before /proc/cmdline. The whole point, as far as I see, is to composite kernel params based on scripts and/or the bootloader params. It makes sense to say "arg1=a" should override (come before) any other arg1, but I see no need to

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,

remove 'NFS-Root' from an error message, and get rid of the old_root check, as it's unused and fails if the target filesystem is mounted 'ro' for no good reason. --- kinit.c 2006-03-21 23:48:15.000000000 -0600 +++ kinit.c 2006-03-22 01:09:39.000000000 -0600 @@ -191,7 +191,7 @@ } } else if (!S_ISDIR(st.st_mode)) { - fprintf(stderr, "NFS-Root:

The klibc based early-userspace utilites I am using have the ability to bring up a raid device before control is passed to kinit. This is done in the case that one needs to do something else to the root device (i.e. it's encrypted or an lvm volume). That's fine and dandy, except that kinit reports a mess of errors about the devices, as they are already loaded. It appears there errors

Just curious if anyone has done anything similar, as I'd rather not reporduce work. I'm going to put alias handling (and only alias handling) into a modified version of insmod. The reason I'm doing this is to aid in boot time module loading via aliases exposed in sysfs. Sure, I could include modprobe directly in the initramfs, but it's a bit large, and I really only need alias

kinit.c contains the following lines before calling ipconfig_main: #ifdef INI_DEBUG args[a++] = (char *)"-n"; #endif In my attempts to debug the NFS mounting, this threw me off for a bit. (The -n parameter runs a "dry run" and does not actually configure the network). Thus, it seems it's actually impossible to debug NFS mounting with the stock, unpatched klibc. It

Commit-ID: 603f1bb024a03d9c50a89e7256ae7814292baf06 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=603f1bb024a03d9c50a89e7256ae7814292baf06 Author: Matthew Garrett <matthewgarrett at google.com> AuthorDate: Thu, 18 Apr 2019 12:12:27 -0700 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 20 Apr 2019 17:11:34 +0100 [klibc] run-init: Allow

[Who wants to be on CC here? I took several names from the posters to the last lkml and klibc list threads: Olaf Hering, H. Peter Anvin, Roman Zippel, Jeff Bailey, Aaron Griffin, Gerd Hoffmann, Milton Miller, Andi Kleen, Jeff Garzik. Since I'm not subscribed I only see the From unless I am Cc'd]. On Mon Jul 10 21:48:34 PDT 2006, Olaf Hering wrote: > On Tue, Jun 27, 2006 at

Commit-ID: 10059fddba9f8bec6aeb0d37d217df6d65e64c3b Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=10059fddba9f8bec6aeb0d37d217df6d65e64c3b Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Sun, 17 Jan 2016 19:50:28 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Wed, 2 Jan 2019 03:08:04 +0000 [klibc] run-init: Add dry-run mode

hello, Preparing my first klibc maintainenace release. :) My plan is to have the patches cook in klibc-queue and once everythings is fine deploy them in the main klibc repo. Please test/review belows patches. I plan to release the current queue really soon for klibc 1.5.20 due to the urgent ipconfig fixes. For now you find my patch queue on:

Hey guys, in case you have spam filters to handle this stuff, I've seen quite alot of spam come across this ML in the past week or so (7 or so). Just a "heads up" really. Thanks, Aaron Griffin