On Sunday 27 November 2005 19:59, Rob Landley wrote: > On Sunday 27 November 2005 11:37, Blaisorblade wrote: > > > Like "/tmp/uml.ctl" in arch/um/drivers/daemon_kern.c, line 70?
> Any user can create /tmp/uml.ctl and the sticky bit prevents anybody else > from deleting it, so any user can block UML switch from working right. There's a switch for the path, so it's only an inconvenience. > Under /var/run you can have a persistent directory belonging to a GID or > some such that UML switch is setgid to, so under /var you are at least > _capable_ of dealing with this sort of thing... > What argument for hurd systems? They by default have /usr -> /. > Hard drives are enormous these days, and > if your OS itself is larger than 10 gigs there's something deeply wrong > with it. (Your application data may be huge, but that's not your OS.) I usually size / as 500M, and split away /usr and /var on LVM. Especially /usr, I've been growing it via LVM 3 times this week. > Try "rdinit=/bin/sh", that affects what init gets run on the initramfs. > (Assuming the initramfs has a comand shell...) Missing from Documentation/filesystems/ramfs-rootfs-initramfs.txt. > So this was fixed in util-linux then? Don't remember the bug. > (I know _busybox_ gets it right, but > that's because I took it into account in my rewrite...) > http://www.busybox.net/lists/busybox/2005-August/015285.html I never tested --move, only --bind. Also, umount has other shortcomings: for instance, umount dev will umount /dev, even if I meant a udev mount on /mnt/gen32/dev with dev on first column (or something like that). I.e. umount tries to absolutize paths relative to /. Also, umount /var when /var is bind-mounted elsewhere is ambiguous, and I've no idea of a proper solution. (However, take this with a grain of salt - I'm trying to code rather than talking today, and I'm failing almost fully). > > > Just symlink it to /proc/mounts and recognize > > > that any tool that can't handle that is a buggy tool that needs to be > > > fixed. > > No - the kernel doesn't allow storing the full set of infos which are > > added by mount there. And frankly I don't want the kernel to do that. > For which use? Don't recall exactly... > I got the loopback functionality working just fine (to the > point where you don't have to specify -o loop anymore. With busybox I guess - you using it on a non-embedded system? I though it was thought to be _small_ and feature-limited. > If you try to mount > a file instead of a block device, it'll do the losetup for you. I'm > pondering adding support for "mount -o offset=12345 file.img /woot" even... You get a namespace conflict that way - the day a fs supports offset= you're burned. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade ___________________________________ Yahoo! Messenger: chiamate gratuite in tutto il mondo http://it.messenger.yahoo.com ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
