Re: beginnings of a diskless boot sequence being committed
Luigi Rizzo writes: :I haven't seen how you suggest to buildpopulate the MFS filesystems -- ... There isn't much to build. Most of the MFS filesystems start out empty. ok here we use a different approach. For simplicity I am using a single MFS system with all the things you put in /var, and including /var/dev and /var/etc (with /dev - /var/dev and /etc - /var/etc on the diskless machine). I have a wacky idea in this vein that I want to pursue sometime -- instead of pushing off lots of symlinks for the various writable portions of the read-only root directory (which strikes as a bit odd in itself), I was considering union-mounting an MFS filesystem directly over the read-only root partition. The advantage of this approach is that you do not have to know ahead of time what portions of the read-only partition need to be writable -- files get copied into the MFS partition only if and when they are written to. Thoughts? It seems like it would be feasible, and it might even be possible to do it directly in /etc/fstab without having to put any sort of cleverness in /etc/rc. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: mounting double-ended SCSI disks
Satoshi Asami writes: However, if I try to mount it from B read-only while A is mounting it read-write, it succeeds. This looks dangerous, as A writing data onto the disk could cause B's cache to go stale without B knowing it. Just about as dangerous al letting A mount it read-only, and then B mounting it read-write. Only in this case, nobody has a chance to know that something is amiss, and since you probably are letting this happen automatically at OS startup, the chances of a RO mount being followed by a RW one are about the same as the other way 'round. You're going to have the problem regardless of whether mount pays attention to the clean flag. If you are worried about a RO mount getting corrupted, don't modify the partition out from under it on another machine. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Can the bootloader create a file or set a flag in the bootblocks?
Mike Smith writes: It would be kind of cool if when managing a remote system if /kernel failed to boot, then on the next boot, the loader will fire up /kernel.old, or a /kernel.somethingorother. We're trying to work out a clean way of managing that sort of persistent state that doesn't involve nasty hacks like the 'nextboot' code did. It's kinda tricky if you don't want write implemented in all your filesystems (bloat!) Maybe I don't understand the problem here, but something akin to how kernel configuration changes are handled seems like a good way to deal with this problem. /boot/loader could stuff something into memory (sort of like the way you can stuff a splash screen into memory), and a user-level program can read that information and stuff it wherever it needs to be stuffed. That may be a little hard with tftp, but with most of the other media types it seems like it should be relatively straightforward. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
