I have a problem with (what is apparently,) the System D initramdisk segfaulting and not finding /dev/mapper/LUKS-{~UUID~} blocks because a systemd init daemon is not initialising the encryption blocks, [/, home] which when unlocked in a live (knoppix 6.4.4) system, they unlock, fsck{.ext4} clean, (so I kept them,) and I think I would just make a new boot sector, but I wonder what else is implied? I figure I would get the word out; and have you back off initramfs, because it appears to get damaged with System D, but possibly a bug in the LUKS systemctl method to unlock LUKS partitions; (presumably when it is supposed to unlock) breaks the initramdisk [init] [script] in System D? (This has happened twice.) please read these cognate references ##URL:
http://ubuntuforums.org/showthread.php?p=11417810[/B].## && infra.
Thank you for your suggestions, and remember that criticism and critical thinking are diametric opposites. I want a suggestion or a solution. I am working on a work around, but my first idea (if someone should see this, having better scripting skills than I do: to save changes from a boot partition to a master backup, with snapshots. (I have an SSD, to save a dynamic [viz: scripted to cron.d] backup of critical changes to the kernel images, with the [READ] bandwidth capability, while compensating for the noatime, norelatime, discard [WRITE] overhead on the boot, /, home disk. It may well compensate for problems in the b-tree i/o paradigm where conventional ioctl() is still a maintenance problem, (cf: hdparm-9.37., Ibid; wiper.sh, README by Mark Lord) but I would rather avoid the BTRFS for now, for TRIM breaking BTRFS on SSD. (I wouldn't dare!) Please RSVP at thread, and
kpharris32@gmail.com. All replies welcome. Flamers beware. P.S.: I am self-[read HALF-] taught, so go easy. RSVP kpharris32 dot gmail.com. Thanks!