On Tue, Jan 12, 2016 at 12:08:55PM -0500, Robert P. J. Day wrote: > i know, it sounds like a moderately inane question, but it came up in the > context of a legacy, DOS-formatted system where the quest was to install > linux, *but* retain the option of backtracking to DOS in case things didn't > go well, and the proposal was to retain the DOS formatting of the > filesystem. What kind of ***-awful monster is this? Why does it need to share the same filesystem, much less disk or computer? Couldn't you do some sort of loopback filesystem hack? Does DOS really need to see all of Linux? Since initramfs are just potentially compressed ODC CPIOs, and should be moderately hackable the right or the wrong way (at least with mkinitcpio), inserting a little script to pivot_root (yes, an odd case where you *would* use pivot instead of switch) or switch_root into that instead. > i suggested that there was little chance of that succeeding, but after the > chat, i sat down and tried to enumerate all of the reasons it wouldn't > succeed. based on the current Filesystem Hierarchy Standard (FHS 3.0), it > seems that all of the following necessities for a linux root filesystem > would be unavailable with a DOS (or FAT or VFAT) filesystem: > > * no proper execute bits on executables Only a problem if you mount with fmask=$fmask where $fmask & 0111 != 0. > * no essential sticky bits on directories like /tmp /tmp should have tmpfs mounted on it, and wouldn't that thus allow you to have sticky bit? > * no support for device files in /dev (which, according to the FHS, *must* > be part of the root filesystem) /dev should have devtmpfs mounted on it in most cases by that point, right? So can't this be ignored? > * no symbolic links, which most versions of linux require for backward > compatibility Really depends on how things are installed. You can hack away with bind mounts in some cases, not that I'd recommend that. And anyhow, my router doesn't give even give an iota of a hoot because *if* it's just busybox, dropbear, and a few scripts.