>>>> Do you have any experience/advice/comment regarding dup data on ssds? >>> Very good question. =:^) >> Now the init on /boot is a "19 lines" shell script, including lines for >> keymap, hdparm, crytpsetup. And let's not forget this is possible by a >> custom kernel and its reliable buddy syslinux. > > FWIW... > And I'm using dracut for that, tho quite cut down from its default, with > a monolithic kernel and only installing necessary dracut modules. Just create minimal bootable /boot for running below init. (Your initramfs/rd is a bloated and packaged version of this anyway.) Kick the rest. Since you a have your own kernel you are not far away from it. #!/bin/sh # This is actually busybox ash or hush. Cant remember now. # You may compile/customize your busybox as well. Easy. mount proc /proc -t proc mount sys /sys -t sysfs mount run /run -t tmpfs mkdir /dev/pts /dev/shm /run/lock mount devpts /dev/pts -t devpts & mount shm /dev/shm -t tmpfs & mount -o remount,rw,noatime / & # '&' is for backgrounding/parallel_execution. # Use responsibly double checking its side effects # depending on your setup. hdparm -B 254 /dev/sda & loadkmap < /boot/trq.bkmap cryptsetup -T 10 luksOpen /dev/sdXX sdXX mount /dev/mapper/sdXX /mnt/new_root -t btrfs -o noatime,compress=lzo cd /mnt/new_root mount --move /dev ./dev mount --move /proc ./proc mount --move /sys ./sys mount --move /run ./run pivot_root . boot exec chroot . busybox init # Jump to your real roots init. Whatever it may be. > But particularly after the last dracut update pulled in kmod as a > mandatory dep as it now links against its libs, despite my monolithic > kernel built without module support, I've been considering similar initr* > alternatives, including hand-rolling my own initr* build scripts. > > Because I'm still not happy having to run an initr* at all, especially > since there's more "magic" there than I'm particularly comfortable with > since I like to grok the boot and thus potential recovery process better > than I do this, and dracut was just the most convenient option at the > time. >> Interestingly my seach for reliability started with "dup data" and ended >> up here. :) > =:^) -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
