Moving this (mostly) non-Mailman (notwithstanding some relevant context/ examples) "discussion" to BALUG-Talk - as most of it is not BALUG administrivia (BALUG-Admin) specific, but of more general Linux interest. (FHS, filesystems, security, ...)
From: "Rick Moen" rick@linuxmafia.com Subject: Re: [BALUG-Admin] BALUG lists ... blank body with command in Subject: header, ... Date: Thu, 20 Jul 2017 12:48:35 -0700
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
originally the files in /etc/mailman/en/ match those in /usr/share/mailman/en/ And looks like the bits editable in web GUI default to
It doesn't help that Mailman uses symplinks for a number of things criss-crossing between /var/lib/mailman locations and /usr/share/mailman (I think) ones.
Well, as/where "it" does that (or distribution's (e.g. Debian's) modification/installation/configuration of such does so, I think it is a semi-elegant "solution" to a somewhat ugly problem. E.g. per Filesystem Hierarchy Standard (FHS) http://www.pathname.com/fhs/ https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard etc., it's permissible for /usr to be mounted read-only (ro) in "normal" operation (e.g. when not performing administrative actions such as adding/removing/updating software, but including administrative actions such as editing of configurations of installed software, routine changes which the software itself makes, etc.). However, fair bits of software don't follow FHS on that, or didn't in past and there's desire to have backwards compatibility with things being more easily alterable if not physically, at least logically, in their (former) location(s) on/under /usr. So, one quite common way to do that is to create symbolic links from relevant location(s) on /usr to relevant locations where things will be editable (and/or contain variable data), e.g. somewhere under /etc and/or /var (and/or for 3rd party applications, /opt - though better yet, /opt should also be possibly ro (though I don't think FHS goes quite as far as to explicitly state such?), and any otherwise "variable" stuff under /opt ought be symbolic link(s) to elsewhere, e.g. under /var/opt and/or something similar for /etc (e.g. /etc itself, or /etc/opt or the like)).
Similar applies to cases where a relatively common binary can be covered by somewhat different (but similar) programs ... and even both may be installed. E.g. update-alternatives(8) and /etc/alternatives. Though that may have first come to Debian (not sure which distribution used it first), I've even see it show up on Fedora and derivatives (Red Hat, CentOS, ...) - though on Fedora and derivatives thereof, I've seen it used on far far far fewer software packages compared to Debian ... but at least that number is greater than zero, and it does exist on Fedora and derivatives thereof (at least last I checked). Anyway, what the alternatives mechanism "solves" is essentially this (notably for those that may not be familiar). Let's see we're on a host, and after having settled the emacs/vi war, everyone wants vi(1) ;-) (okay, theoretical argument). But, alas, some want nvi (which is vi on BSD), and some want vim (which last I was aware, Fedora doesn't even make nvi available!). What if some want *both*, but, well, vi on standard PATH in /bin/ or /usr/bin ... well, it's got to provide one of those (or some reasonable vi-like alternative) ... ought that not be a reasonable matter of system configuration? Well, with alternatives, it is, but ... there's FHS. So, those configurations should be managed ... under /etc. But, what if/when the binaries are properly under /usr/bin? Well, we have, e.g.: $ readlink /usr/bin/vi /etc/alternatives/vi $ readlink /etc/alternatives/vi /usr/bin/nvi $ So those on such a lovely system can be treated to beautiful nvi (which is the vi on BSD systems) by using the command vi (and avoid all the annoyances of vim http://www.rawbw.com/~mp/linux/vim/vim_annoyances.txt ), but heaven forbid, should a user on such system actually want to execute vim (e.g. to redemonstrate its bugs/annoyances), they merely need type vim $ type vim vim is /usr/bin/vim $ readlink /usr/bin/vim /etc/alternatives/vim $ readlink /etc/alternatives/vim /usr/bin/vim.basic $ ls -l /usr/bin/vim.basic -rwxr-xr-x 1 root root 2240936 Mar 9 16:56 /usr/bin/vim.basic $ And the lovely alternatives mechanism also updates related links, so e.g. $ man vi will give what corresponds to /usr/bin/vi So ... a pretty darn good solution to a relatively difficult problem/issue. Some distributions, however decide thou shalt have no choice, and, e.g. provide only and exactly one editor for vi, namely vim and all its annoyances (or on BSD, one gets the lovely nvi for vi, but if one wants to get vim by invoking command vi, there isn't mechanism that puts that in place on the PATH and in standard location for all general users).
And per FHS, etc., the above typically wouldn't be editable (/usr filesystem may be mounted read-only....
Well, it's hardly the only offender. I discovered this when I did the research that produced http://linuxmafia.com/faq/Admin/linuxmafia.com-backup.html , and [re-]discovered that Apache httpd's cgi-bin directory is in /usr/lib/cgi-bin/
Egad, uhm, yeah, some software (notably often "upstream") may still have stuff in/under /usr that ought not be there. Some distributions will choose to alter the software such that the offending stuff is no longer under /usr - which fixes the FHS issue - and if also fixed corresponding changes are made for all related software for that distribution - is then mostly all fine and dandy - *except* it still breaks any backwards compatibility that may be expected - e.g. users might expect the stuff to at least logically appear to be under /usr, likewise software (e.g. random home-grown local script) may have been developed expecting the stuff under /usr - and that script breaks if it's no longer (at least logically) present under /usr where it was and where the script expects it.
I likewise keep /usr normally mounted ro, and likewise use the apt hooks to autoremount it for package operations -- but live with the fact that I need to also manually remount /usr to fiddle with cgi-bin scripts.
SpamAssassin's rulesets and scoring settings in /usr/share/spamassassin are another example (and I guess I should add that directory to my backup list).
Yes, many examples of stuff that ought not (at least physically) be under /usr, and is generally (FHS) fixed on quality distributions (e.g. Debian) to be FHS compliant, but may provide symbolic links or such on /usr - to allow for compatibility with things/users that may still expect it to appear/function as if it's on /usr - even if it's no longer physically on/under /usr.
I'll admit to getting a bit disenchanted with many of the more-recent additions to FHS (specifically /media and /srv). I've read the rationales, and I don't agree that /media is justified in addition to /mnt. I am now grudgingly reconsidering my reflexive opposition to /srv, because there's a good case that CGI-BIN scripts should be there rather than anywhere in /usr, including the '/usr may be ro' one. Therefore, SpamAssassin rulesets and scoring settings arguably are better there, too.
Well, not sure if I've read the latest FHS (I also miss something that was removed from earlier FHS - and I also continue to use: /var/local/ it answered the question of where variable content local stuff goes, which at least partially answered the question: So, I've got lots and lots of data that needs additional filesystem(s), where ought those be mounted? There doesn't seem to be a fully universal answer for that, and FHS (at least I last read) fails to fully and unambiguously answer that. Well, /usr/local (or beneath that) would be suitable for some stuff, /var/local (at least per earlier FHS) for some other stuff ... bits of FHS and what I'd guestimate for logical extensions ... /etc/local for config of local (not distribution or 3rd party) stuff, /var/opt for variable 3rd party stuff, etc. - anyway, at least something approximating that - but alas I see many (most) sites that don't do it that way, and often, egad, create semi-arbitrary additional mount points right under / <sigh>.)
I think /mnt is "nice", but has always been rather limited - as it's just a single mostly guaranteed (normally) available mount point - so mostly useful for a temporary mount location, or when one needs to mount directly under root filesystem and root filesystem is ro (e.g. recovery or maintenance scenario) and there may be no other filesystems mounted, but need a dir to mount something at least temporarily ... oh where oh where? - that's when /mnt is really your friend. So, ... /media, /sys, /srv ... I think things could've gone in better directions. Adding stuff right under / should be done very conservatively/minimally - I think there were probably better solutions for all of those. And I think /sys was (and is) totally unnecessary ... great stuff there, but it should'a gone elsewhere - e.g. /proc/sys.
Any time someone says 'Oh, let's solve this problem by putting it in a new directory off /', I get cranky and conservative-minded, though. Which is why I think /sys is regrettable -- even though I've heard how we haplessly fell into the need for that on Linux systems. (Essentially, the kernel people made such a dog's breakfast out of /dev that they had to make a new tree to start over. Nice going, guys.)
Whether it was /dev, or /proc, I think at least between *major changes* of Linux kernel versions, those were ample opportunities to clean up and fix (and add new stuff) under /dev and/or /proc - no need to add a whole separate /sys (or geez, at least don't mount it at /sys - why not have it just mounted as /dev/sys or /proc/sys, huh? I mean we have a perfectly good devpts mounted on /dev/pts - why not likewise put sysfs at /proc/sys or /dev/sys ? Ah well.
I've got mixed thoughts on /media ... I think it's at least better than /cdrom, but perhaps replacing /cdrom with something a bit more general than /media? E.g. perhaps combining functionality of /mnt and /media somewhere/somehow? I dunno.
But yeah, sometime it feels too much like feature creep, with too much stuff being added not quite, but almost willy-nilly, to FHS, with semi-arbitrary new locations.
I actually wanted to consult you on /boot being a separate filesystem. I've done that since forever, but am acutely aware that the original rationale no longer applies, that of old BIOSes being unable to branch from int 13h to disc cylinder locations 1024 and over.
So, is there a 2017 reason for still having /boot separate? I can think of scenarios, like you have most of the system on md mirrored partitions but want your bootloader to be able to run from a pair of ext2 ones on both drives, _or_ you have most of the system encrypted. Are there reasons I'm missing?
Well ... :-) I think there definitely still are reasons to have /boot as a separate filesystem. Some may not be relevant, or as relevant/significant as before, but I think many of the arguments/advantages of separate /boot still apply. Stuff I'd argue/advocate for separate /boot (I'll skip the counter-arguments): o ro/security( / accident reduction) - a separate /boot can be ro, without necessitating / be ro o faster/safer fsck/recovery - for filesystems/data critical to boot and getting to at least single user mode, within reason, smaller and separate is generally an advantage. Many often lump *lots* into root (/) filesystem and/or it may get rather to quite large, so having a separate /boot can be rather to quite advantageous. o one can be ultra-conservative on the filesystem type for /boot, independent of choice of filesystem type for /. E.g. I think many of my /boot filesystems are still ext2 - exceedingly backwards compatible with most anything that would deal with them or that I might want to have deal with them. And with /boot kept sufficiently small and clean, fsck time for recovery of /boot even if it's just ext2, is still pretty darn quick. Though as I think about it now / nowadays, and think what filesystem type is most widely and thoroughly tested and used, well supported, maintained, and works with pretty much any Linux tools ... might be time by now to advance /boot from ext2 to ext3. For similar I like to not have / be "too big", and like separate /usr, /home, and /var. Same also applies, as feasible, to those filesystems too. o lovely useful tip/"trick" I like and have always done on /boot: $ ls -ld /boot/boot lrwxrwxrwx 1 root root 1 Dec 29 2011 /boot/boot -> . So, bootloader configs and all that, to the paths have a leading /boot, or not? If the path is relative to the root of the filesystem used for boot, and that may be /boot filesystem, or may be / (root) filesystem, do we need to change having / not having that leading /boot in the boot loader configuration bits? No. Any reasonably sane boot loader deals fine with symbolic links. by having the symbolic link I note above, all boot configurations have the /boot prefix, and it doesn't matter if /boot is a separate filesytem or not, or changes back and forth - the logical pathnames all remain prefixed with /boot and the bootloader handled 'em all fine - period. End of all that silliness of whether or not we have a /boot prefix in there - we always do and it always works. o all kinds of stuff one might possibly want for / (root), but that bootloaders at least often can't handle or would prefer the bootloaders generally not deal with that complexity (even if the (claim they) generally can): o encrypted / (root) o md / (root) o LVM / (root) o latest wizbang spiffy/experimental filesystem type for / (root) o two or more of the above ;-) (I'm using at least two of the above on at least one host :-)) o separate /boot leaves open the possibility to do more "interesting" things with / (root) - even in future and if one isn't doing so presently and may not have any immediate or short-term plans to do so. o rather darn easy to get rid of a separate /boot and place it on / (root) - presuming suitable filesytem type, not encrypted, and other similar requirements, but significantly more difficult to later add a separate /boot filesystem - especially if one hasn't saved reasonable space at start of drive, it's a single drive system or that's the only drive that can be reasonably conveniently booted from; drive space is relatively cheap these days - probably good to invest in saving that space up front and separate on the drive - even if one isn't doing a separate /boot filesystem - in case one wants to change it later to separate /boot; to make such transition even easier in future if one isn't doing separate /boot, also create a partition there - even if not at all using it presently. o 1024 cylinder limit? Not much of an issue these days - but might want to still consider it for possibly high levels of backwards compatibility. With much larger drives, there's whole partitioning format issue and UEFI and all that - but that's a whole 'nother set of questions / can of worms.
I suppose too, I ought set up some user in group (or with access to group) list, so that many of the list related commands can be run fine with less-than-root privileges - a not otherwise privileged user but also in group list would seem optimal - as group list seems to have the permissions to do the needed, but would generally lack permissions to muck with stuff it ought not (e.g. files owned by list by not writable by group list). At least on Debian, of what I've seen so far, looks like all the normally needed actions to manage mailman lists, are controlled/accessed via the list group.
Makes sense. FWIW, when I need to muck about with Mailman's files I _generally_ just su to list. Most particularly, it's really important to be user 'list' if you regenerate a pipermail archive using /var/lib/mailman/bin/arch . Otherwise, if you make the mistake of doing it as root, the ownership of the generated Web archive is wrong and you'll get 403 errors until you figure that out and fix it.
Good points. But I noticed on Debian (presently still oldstable): $ grep '^list:' /etc/passwd list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin $ awk -F: '{if($3==38)print;}' /etc/group list:x:38: $ So ... su - list ain't gonna cut it. 8-O. But I added: $ expand -t 4 < ~root/bin/golist #!/bin/sh cd / && exec perl -e ' ($),$()=(q(38 38),38); ($<,$>)=(38,38); $ENV{HOME}=q(/var/list); exec {bash} (q(/bin/bash)); ' $ :-) It's a start anyway ... I ought add bits on that, to adjust PATH, read list's HOME from getpwent or the like for list's entry, probably even likewise read list's UID and GID similarly. Like I said, it's a start. But also, may want to have two different "list" role accounts, one using list's UID (and GID) - most notably for stuff that will, e.g. create new files/directories., and one that uses list's GID, but unprivileged user, for operations that are essentially read-only. Ought also make that thing entirely perl - it's not like perl lacks a chdir function.
Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Moving this (mostly) non-Mailman (notwithstanding some relevant context/ examples) "discussion" to BALUG-Talk - as most of it is not BALUG administrivia (BALUG-Admin) specific, but of more general Linux interest. (FHS, filesystems, security, ...)
Good idea. Thanks.
[Mailman symlinks criss-crossing from var/lib/mailman to /usr/share/mailman:]
Well, as/where "it" does that (or distribution's (e.g. Debian's) modification/installation/configuration of such does so, I think it is a semi-elegant "solution" to a somewhat ugly problem. E.g. per Filesystem Hierarchy Standard (FHS) http://www.pathname.com/fhs/ https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard etc., it's permissible for /usr to be mounted read-only (ro) in "normal" operation (e.g. when not performing administrative actions such as adding/removing/updating software, but including administrative actions such as editing of configurations of installed software, routine changes which the software itself makes, etc.).
Well, sure, it does have that very considerable merit. It's something that is merely initially a little bewildering, as you might think all of Mailman (other than /etc files) lives in /var, and suddenly you turn around a corner and find yourself in /usr.
Also, speaking in very general terms, at a couple of jobs involving large Internet installations, I developed a well-founded horror of overuse of symlinks, as they can get you in serious trouble if you are not careful: not just the nuisance of dangling symlinks (you see the link and assume it points to the thing it always has, but that thing has been moved or removed) but also circular symlinks.
The Mailman setup doesn't suffer those, of course, but if you've ever debugged symlink problems, seeing them used abundantly will make your skin itch, just by association.
Again speaking very broadly, symlinks are also a reason to be very careful about command options during mass-file operations, to ensure that you don't accidentally traverse a symlink onto an unintended filesystem. E.g., for rsync, option '-x, --one-file-system don't cross filesystem boundaries', and similar ones for other tools including cp and rm. (This is also, on the side, yet another argument for keeping /usr normally read-only -- because you might forget to use those options.)
/opt should also be possibly ro
IMO, /opt should be
lrwxrwxrwx 1 root root 14 Mar 4 2008 opt -> /usr/local/opt
I do not agree with the rationale for /opt existing at all. IMO, it was a bad decision kowtowing to proprietary software interests. But, like most other parts of an FHS implementation I don't approve of, it's easily fixed. /media, I got rid of completely.
(And, just to clarify, I don't mean I like having anything in /usr/local/opt, and IIRC there's still nothing in it. I just think /opt is a bad idea, and if anything _were_ written there, I'd want it to not land on the root filesystem. Honestly, I should probably just delete the symlink and the stil-empty directory it points to, but those remain present to catch anything that tries to write there before I can say 'No you don't.))
The reality of FHS, at least during its initial years under Dan Quinlan, was that it was a necessarily political effort to coax all of the Unixes into moving gradually towards more-rational file locations and less-wacky directory trees. E.g., as FHS points out, the sendmail binary was historically /usr/lib/sendmail, which is nuts since that ain't no library. And there were much worse things in the bad old days. However, as a concidence of FHS being an effort at persuasion by someone (Quinlan) with no inherent power base and quite the flock of cats to herd, it has always included quite a number of dodgy compromises
I'm not going to take the time to find examples, but you occasionally find strange wording in the FHS giving very grudging blessing to some subtree about which you think 'No, that's just bloody wrong', and then you realise Quinlan was avoiding offending indulgers of some wrongheaded Unix fossil practice that is still too prominent to ignore.
In the 2000s, Rusty Russell and (the late) Chris Yeoh, both former coworkers of mine, took over the FHS from Quinlan, and it's under their watch that FHS sprouted some innovations that at least at first (and in the case of /media, lastingly) got my back up, a bit, and made me say 'I'm not sure I'm OK with that.'
But I certainly applaud the project's goals even if it's under the wing of the at-best-useless Linux Foundation (https://landley.net/notes-2010.html#18-07-2010), because I know Rusty and know he doesn't do things without good reason.
BTW, in case I implied otherwise, I should mention that /sys is _not_ FHS-mandated, which makes sense when you remember that /sys is a Linuxism, and FHS aspires to create a standard most Unix at least vaguely resemble (other than OSX, which inherits a bunch of mutant silly stuff from NeXTSTEP, ideological 'the newbies hate FHS' efforts like GoboLinux, guix/nix, the 0install package system - https://en.wikipedia.org/wiki/Zero_Install, DJB's slashpackage scheme, and Poettering & Co's latest terrible idea to make our lives miserable - http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html).
[snip discussion of /etc/alternatives, which I agree is cool, and proved persuasive enough that RHEL/CentOS picked it up from Debian. I don't oppose symlinks generally. I just am wary of their overuse.]
Egad, uhm, yeah, some software (notably often "upstream") may still have stuff in/under /usr that ought not be there.
Rewriting and recompiling are then in order, say I. ;-)
Yes, many examples of stuff that ought not (at least physically) be under /usr, and is generally (FHS) fixed on quality distributions (e.g. Debian) to be FHS compliant, but may provide symbolic links or such on /usr - to allow for compatibility with things/users that may still expect it to appear/function as if it's on /usr - even if it's no longer physically on/under /usr.
Sadly, the SpamAssassin and cgi-bin trees are physically on /usr, not just symlinked in.
Well, not sure if I've read the latest FHS
3.0, the latest, appeared in 2015. http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html
(I also miss something that was
removed from earlier FHS - and I also continue to use: /var/local/ it answered the question of where variable content local stuff goes,
Yeah, I wonder what Rusty and Chris were thinking there? Too bad FHS lacks a changelog.
ISTR that FHS now says to place all variable data that dictates a program's state into /var/lib, that this data should stick around after a reboot, and that this data is host-specific. And it says /var/opt should house data of apps installed in /opt.
IMO, having a 'lib' directory that isn't libraries and nothing but is a mistake, but then much of /var remains a bit of a trainwreck.
So, I've got lots and lots of data that needs additional filesystem(s), where ought those be mounted?
Wherever the nature and role of that data dictates.
There doesn't seem to be a fully universal answer for that, and FHS (at least I last read) fails to fully and unambiguously answer that.
It couldn't possibly do so. 'Collection of data that needs additional filesystems' is too vague a specifier.
I think /mnt is "nice", but has always been rather limited - as it's just a single mostly guaranteed (normally) available mount point - so mostly useful for a temporary mount location, or when one needs to mount directly under root filesystem and root filesystem is ro (e.g. recovery or maintenance scenario) and there may be no other filesystems mounted, but need a dir to mount something at least temporarily ... oh where oh where? - that's when /mnt is really your friend.
Here's what I do: If there's going to be a temporary filesystem, I mkdir /mnt/$FOO and use that. The CD-ROM got mounted at /mnt/cdrom, not frellin' /cdrom nor /media. Keep all that casual stuff under /mnt. No need for a separate tree anywhere else -- particularly not off the system root..
[/sys:]
Whether it was /dev, or /proc, I think at least between *major changes* of Linux kernel versions, those were ample opportunities to clean up and fix (and add new stuff) under /dev and/or /proc - no need to add a whole separate /sys (or geez, at least don't mount it at /sys - why not have it just mounted as /dev/sys or /proc/sys, huh? I mean we have a perfectly good devpts mounted on /dev/pts - why not likewise put sysfs at /proc/sys or /dev/sys ? Ah well.
They certainly could have put the new stuff within /proc somewhere rather than punting and creating /sys (as of Linux 2.6 and later). It was a bad call.
[separate /boot:]
Well ... :-) I think there definitely still are reasons to have /boot as a separate filesystem. Some may not be relevant, or as relevant/significant as before, but I think many of the arguments/advantages of separate /boot still apply. Stuff I'd argue/advocate for separate /boot (I'll skip the counter-arguments):
Yes, I concur with a bunch of those. I _really_ like having system-critical boot stuff be on an isolated, quiescent, ultra-simple and conservatively chosen filesystem, kept normally read-only.
o lovely useful tip/"trick" I like and have always done on /boot: $ ls -ld /boot/boot lrwxrwxrwx 1 root root 1 Dec 29 2011 /boot/boot -> .
Eh, yes. Noted down for use.
A trivial thing I do, but it can save your life (metaphorically) some times: All mountpoint directories get this, before one mounts the tree that goes there:
# touch NOTHING_IS_MOUNTED_HERE # chattr +i NOTHING_IS_MOUNTED_HERE
If you ever unexpectedly see that zero-length file, you know... what it says is so.
Good points. But I noticed on Debian (presently still oldstable): $ grep '^list:' /etc/passwd list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin $ awk -F: '{if($3==38)print;}' /etc/group list:x:38: $
FWIW, I have list:x:38:38:Mailing List Manager:/var/list:/bin/sh
Can't remember whether the shell is a local tweak on my system or not. The list account's a little pecular, but I really do su to root and then list, to do mailing list archive manipulations, and it works fine.
Some interesting points!
Michael Paoli writes:
Well ... :-) I think there definitely still are reasons to have /boot as a separate filesystem. Some may not be relevant, or as
You have lots of good reasons already, but a couple more:
o Multiboot systems: you can have one shared /boot that all the systems use, rather than the confusion where you have the /boot files owned by one of your installed systems, and the other systems all need to somehow install their kernels onto another system's root partition (like the way grub2 wants to work).
o Related to your point on being conservative on filesystem type: on a portable disk or SD card, you can have /boot be a filesystem that any OS can write even if the root is ext4 or some other Linux-specific type. For instance, on Raspbian, it's handy that people who need to customize a headless Raspberry Pi but don't have Linux can put files on the VFAT boot partition.
...Akkana
Quoting Akkana Peck (akkana@shallowsky.com):
o Related to your point on being conservative on filesystem type:
Just to show I strongly concur:
linuxmafia:~# mount -l -t ext2 /dev/sda1 on /boot type ext2 (rw) [/boot] /dev/sda9 on /usr type ext2 (ro,nodev) [/usr] /dev/sda6 on /var type ext2 (rw,nosuid,nodev,noatime) [/var] linuxmafia:~#
(Parts of /var and /usr are separately mounted and ext3. This is an old build; on a modern one I'd use ext4 where I currently use ext3.)
As to vfat for /boot, sure that's simple and universal, but you pay the price that it's very much not robust.
Rick Moen writes:
As to vfat for /boot, sure that's simple and universal, but you pay the price that it's very much not robust.
Definitely agree. I wouldn't use any FAT on a normal Linux system. But it probably does make sense for Raspbian, since many Raspbian users have no other Linux system available, and have to use a Mac or Windows box to burn their SD cards. I'm seeing a surprising number of people on RPi IRC channels who bought their Pi as a cheap and easy way to teach themselves Linux, with no previous Linux exposure.
...Akkana