I have done it with my LVMcache based solution without issue. Currently am running that on a Mac mini server If i could get a pair of spinners in there with an SSD cache i would. On Tue, Dec 20, 2016 at 1:36 PM, Michael Butash wrote: > How does one handle redundant disks *properly* or *officially* with EFI? > > First/Last time I dealt with EFI was an asus that had 2x SSD's (factory > raid 0[!]) that I intended to raid 1 for redundancy vs. performance. It > had no legacy boot option at all (shame, asus), so I was forced to work > with it. I eventually got my recipe up on it with mdadm, crypto, and lvm > with ubuntu after weeks of fiddling with it, but never really figured out a > better way to deal with efi partition. I had setup a cronjob to rsync the > efi directory, never really tested the actual failure scenario and/or > recovery however before I gave up on the laptop otherwise (and job). > > Maybe that is/was good enough, just wasn't sure how well the efi bios > would switch up disks like that, as something at the time made me believe > it wouldn't. I've read efi is somewhat fakeraid aware, perhaps that's an > option since mdadm works with fakeraids too... > > Surely I'm not the only one to do redundant disks in desktops, but do seem > to be one of an odd few. > > -mb > > On Tue, Dec 20, 2016 at 12:06 PM, Kevin Fries > wrote: > >> I suspect the issue was more with UDev and those fancy new drives. I >> just wiped then installed Arch on a brand new HP laptop with GPT, zero >> issues. I especially like the lack of a separate /boot partition by >> reusing the EFI/GPT boot sector. >> >> Personally, my install was very straightforward and stable as hell. >> >> Kevin >> >> On Dec 20, 2016 9:13 AM, "Michael Butash" wrote: >> >>> I agree, this is why I keep separate /usr partitions, both to allow for >>> growth, and to monitor my growth. Another weird thing Arch has such a >>> difficult time booting with a separate /usr, more like the dev's ass-u-me >>> again no one will *ever* do this... >>> >>> I started doing it as a means of checks for watching growth over the >>> years. In the old days of 8.04, usually a 4gb partition for /usr was fine, >>> and less than a gig for actual root (/). Now I fill /usr with at least 6gb >>> of data on install it seems, 7-8gb is more the norm. >>> >>> Use of GPT is/was really trying to keep up with tech, where early days >>> of SSD, fdisk was terrible about alignment, where most things can and still >>> do say to use GPT. Just no one tells you it is inherently broken still on >>> most platforms to consider booting off of. >>> >>> I'd be more inclined to try EFI, but I'm fond of consistent raid >>> approaches, even for boot partitions, where the inflexible FatFS nature of >>> EFI partition just rubs me the wrong way as it can't be made natively >>> redundant like I can with /boot being on mdraid partitions happily booting >>> linux otherwise. Curious what others do with redundancy around EFI desktop >>> drives... >>> >>> Even without another shed of M$ on here, it still finds a way to screw >>> things up. >>> >>> -mb >>> >>> On Tue, Dec 20, 2016 at 12:09 AM, Steve Litt >>> wrote: >>> >>>> On Mon, 19 Dec 2016 23:17:38 -0700 >>>> Michael Butash wrote: >>>> >>>> > I really had no idea GPT was such an anomaly still. Everything I >>>> > read was like "just do it!". Not. >>>> >>>> At this point in time, laptop hard disks still aren't big enough to >>>> require EFI, and desktops have multiple disks. So what I do on laptops >>>> that can still do MBR is MBR format the hard disk. >>>> >>>> With my daily driver desktop, with a 4TB disk, and a 3TB disk, and a >>>> 256GB SSD, I MBR boot to the SSD, which also contains the whole /usr >>>> and /etc tree for easy bootability in these days of symlinked /usr. So >>>> I get the advantages of GPT on my large disks, the simple booting of >>>> MBR on my SSD: It works fast and beautifully. >>>> >>>> SteveT >>>> >>>> Steve Litt >>>> December 2016 featured book: Rapid Learning for the 21st Century >>>> http://www.troubleshooters.com/rl21 >>>> --------------------------------------------------- >>>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>>> To subscribe, unsubscribe, or to change your mail settings: >>>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>> >>> >>> >>> --------------------------------------------------- >>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >>> To subscribe, unsubscribe, or to change your mail settings: >>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >>> >> >> --------------------------------------------------- >> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org >> To subscribe, unsubscribe, or to change your mail settings: >> http://lists.phxlinux.org/mailman/listinfo/plug-discuss >> > > > --------------------------------------------------- > PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org > To subscribe, unsubscribe, or to change your mail settings: > http://lists.phxlinux.org/mailman/listinfo/plug-discuss > -- A mouse trap, placed on top of your alarm clock, will prevent you from rolling over and going back to sleep after you hit the snooze button. Stephen