Quotes of the week

Posted Mar 14, 2011 13:55 UTC (Mon) by nix (subscriber, #2304)
In reply to: Quotes of the week by daglwn
Parent article: Quotes of the week

Quite. One site I help administer just had a pile of FS corruption due to a power flicker at the wrong time. /usr was largely toasted, but it was all recoverable because / was intact, so there was enough machinery working to get /usr back.

FS-wide corruption is rare, but still does happen: splitting a small critical core in / from a massive pile of not-so-critical parts helps recover from that. We can call the non-critical parts '/usr'.

Quotes of the week

Posted Mar 14, 2011 18:08 UTC (Mon) by BenHutchings (subscriber, #37955) [Link] (5 responses)

The initramfs is now the minimal recovery partition.

Quotes of the week

Posted Mar 15, 2011 12:34 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

You need an awfully large initramfs for that. I don't know about you but I'd rather not have a 60Mb kernel image :)

Quotes of the week

Posted Mar 15, 2011 13:17 UTC (Tue) by foom (subscriber, #14868) [Link] (1 responses)

The default debian initrd has all *sorts* of useful tools in it. There's certainly enough there to do basic troubleshooting and recovery (including vi!). It's 28MB as an unpacked directory tree, and 8.8MB in initrd form. That doesn't seem like a real issue...

/bin:
busybox cat chroot cpio dd dmesg false fstype gunzip gzip halt insmod ipconfig kill ln losetup ls minips mkdir mkfifo mknod mount nfsmount nuke pivot_root poweroff readlink reboot resume run-init sh sh.shared sleep sync true umount uname

/sbin:
blkid dmsetup modprobe rmmod udevadm udevd

Commands included in /bin/busybox:
[, [[, adjtimex, arping, ash, awk, basename, blockdev, brctl, bunzip2, bzcat, bzip2, cal, cat, chgrp, chmod, chown, chroot, chvt, clear, cmp, cp, cpio, cut, date, dc, dd, deallocvt, df, dirname, dmesg, dnsdomainname, dos2unix, du, dumpkmap, dumpleases, echo, egrep, env, expr, false, fgrep, find, fold, free, ftpget, ftpput, getopt, grep, gunzip, gzip, head, hexdump, hostid, hostname, httpd, id, ifconfig, ionice, ip, ipcalc, kill, killall, klogd, last, length, ln, loadfont, loadkmap, logger, logname, logread, losetup, ls, lzcat, lzma, md5sum, mkdir, mkfifo, mknod, mktemp, more, mount, mt, mv, nameif, nc, netstat, nslookup, od, openvt, patch, pidof, ping, ping6, printf, ps, pwd, rdate, readlink, realpath, renice, reset, rev, rm, rmdir, route, rpm, rpm2cpio, run-parts, sed, setkeycodes, sh, sha1sum, sha256sum, sha512sum, sleep, sort, start-stop-daemon, strings, stty, swapoff, swapon, sync, sysctl, syslogd, tac, tail, tar, tee, telnet, test, tftp, time, top, touch, tr, traceroute, traceroute6, true, tty, udhcpc, udhcpd, umount, uname, uncompress, uniq, unix2dos, unlzma, unxz, unzip, uptime, usleep, uudecode, uuencode, vi, watch, watchdog, wc, wget, which, who, whoami, xargs, xz, xzcat, yes, zcat

Quotes of the week

Posted Mar 20, 2011 0:24 UTC (Sun) by daglwn (guest, #65432) [Link]

And none of it has documentation and --help is useless in busybox. An emergency is exactly when I need that stuff.

Quotes of the week

Posted Mar 15, 2011 15:07 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

Another point: unless the initramfs has /etc on it, it's not a good solution, because one advantage of a separate /usr (and /var) is that its relatively higher frequency of corruption is relatively harmless because all the systemwide configuration state in /etc is unaffected.

initramfses don't help there. (Sure, backups help, but restoring from backup is annoying.)

This is all fairly pettifogging, true, but anything that leads to /etc being lost less often is a good thing as far as I'm concerned. I suppose it would be possible to put /etc on a filesystem of its own, in a loopback filesystem stored in the root directory, and mount it at the very start of the boot scripts: that would let you have a single unified / and /usr while minimizing the probability that a severely-damaged rootfs would lose you access to /etc. (It wouldn't lower it as far as putting /etc on a different filesystem, but it's hard to get access to a different filesystem without /etc. You could have a skeleton /etc which is just enough to give you access to the real /etc, and is mount --moved out of the way and then overmounted by the real /etc early in the boot process: that combined with an initramfs nicely populated with recovery tools would fix all my concerns, I think, but at the cost of a very unusual mount tree.)

(and I am definitely overthinking this.)

Quotes of the week

Posted Mar 15, 2011 16:12 UTC (Tue) by nix (subscriber, #2304) [Link]

For the record, the total number of times having a separate / has saved me from /etc corruption is three, in thirteen years. That includes quite a bit of risky stuff like sudden power-cut tests and hibernation and so on, so a unified / and /usr are not the most terrible things in the world. However, for existing systems it is *very* annoying to transition to such a layout, to such a degree that it is almost certain I won't, and will merely curse anyone who decides to rely on too much in /usr in early boot and live with any breakage.