Arch migration (success!!)

[Stephen Partington]

Good information, however "GPT as far as I can tell simply doesn't work
outside EFI" this is kind of the norm.

On Mon, Dec 19, 2016 at 6:30 PM, Michael Butash <michael at butash.net> wrote:

> I figured if I'm going to anything, I'd prefer to go to something I can
> control more, which always seems to bring me back to Arch, and more than a
> few of you seem to use it too.  I attempted before and failed, but this
> weekend I got there, got stable, and then found more or less all the same
> desktop bugs and more, particularly with KDE, with far more pain than I'm
> used to with Ubuntu or other debian derivatives.  Figured I would share
> some of the experiences for better and worse even if TL:DR, but HTH someone
> too.
>
> I like certain things about Arch, but found getting it working to be a
> dismal process, and one that kept teaching me just how different (or
> broken) every distribution's process can be.  I simply can't imagine most
> people using Arch that aren't simply diehard sysadmins, primarily even
> getting it to work outside of the most basic installations.
>
> Biggest things that totally screwed me up were my want to use GPT, these
> new-fangled nvme disks that aren't still fully baked into linux, adapting
> my disk/volume setup to all of this, and finding it really didn't like me
> making /usr a separate partition.
>
> GPT as far as I can tell simply doesn't work outside EFI, especially as a
> legacy bios thing that has been MBR-based for eons.  Usage of GPT seems to
> ass-u-me/implies it is being paired with EFI which knows these things.
> Trying everything with this intel board, it simply would never boot off it,
> and apparently most legacy bios are cranky about booting gpt, particularly
> intel boards.  I wasted thanksgiving long weekend attempting last time,
> even without raid or anything else on a standard non-nvme ssd, and never
> worked.  I give up as I didn't really need GPT, but more curiosity to keep
> alignment proper for ssd geometry.
>
> I got a pair of Samsung NVME-based 950 Pro M.2 disks as my end-goal, as
> their attachment to the pci-bus direct seems to be the future.
> Unfortunately the tech is still new, most tools like udev still aren't
> baked to detect them, and even when rigging it with rules to do so, fails
> because of other things around udev not baked in either.  This includes
> thins like hdparm, smart tools, any monitoring apps looking for drives at
> only sd[a-z]*, zfs libs (because udev won't build /dev/disk/by-* links off
> them), and most anything else looking for disks !=sd*.  Even samsung's own
> firmware utility "magician" doesn't know what they are under linux.
>
> Adapting my disk formula was actually fairly easy giving up on GPT and ZFS
> already, combining MBR+ traditional linux fs tools, mdadm, luks/cryptsetup,
> and lvm2 didn't so much care.  What last broke my booting linux was
> combinations of mdadm and luks, and my typical habit of building /usr as a
> separate partition.  I found out the hard way mdraid builds different from
> initrd or a fully-booted kernel, and arch didn't seem to want to work via
> UUID with grub, as it unlocks luks volumes differently in initrd than
> ubuntu does (poorly in arch, imho).  Once I created a static mdadm.conf for
> it, pointed grub to unlock it, it would work.  Then die on not finding /usr
> to init systemd.
>
> The usr problem was far more annoying, and took some digging, where all
> recommendations I found simply didn't work.  Arch devs just never presumed
> anyone would want to do that, and really have no good method of supporting
> it.  Quick fix was relenting and keeping /usr on root anyways, though
> annoying it wasn't so obvious with boot dying because of not getting
> /sbin/init to work (really a symlink to /usr/lib/systemd/systemd or like).
>
> After everything, I have mdraided nvme disks, luks encryption, lvm, and
> ext4 atop that, so I'm at least no worse off.  ZFS was my first choice, but
> linux tools not understanding nvme drives broke that as viable.  BTRFS
> didn't seem to get me much with chicken and egg issues around encryption
> that it would be simpler, but would have at least offered lzo compression,
> if not brokenness like ZFS+udev with nvme.
>
> Once at a desktop again, KDE with latest packages ala neon are still a
> clusterfsck though, still getting my taskbar flipping around with displays
> coming/going, but not Arch's fault, and at least I'm stable off of Ubuntu
> so far otherwise.  I probably need to try cinnamon or mate again, something
> the developers have tested more than a single monitor and video card with.
>
> I cannot say it's been terribly worth it so far moving to Arch, but this
> is only really my second full day of just simply "using it".  The fact it
> really is so minimal has been a bit painful, as it requires literally
> anything you might actually need to be installed, even with full desktop
> meta packages.  Actually need a terminal app with kde - need to add
> konsole.  Want screenshots with spectacle or music with banshee?  Need to
> figure out AUR, or yaourt as I did.
>
> Thankfully I've already learned their stupid app names for linux software
> to even begin to find most (like baobab, my favorite disk space utility
> with the most horrid name), but I don't expect most would/could but the
> most diehard linux users to get a moderately complete desktop back.  At
> least versus kubuntu giving you an adequate base to start with that I'm
> more used to.
>
> Any windoze person would have run away screaming long ago, and I think
> even most moderately skilled linux folks - it really shouldn't be this
> hard, yet here I am too.  Neither debian or ubuntu are good long-term with
> upgrades obliterating my system, so here's to hoping change is worth it in
> the long run for rolling releases and adding a new distribution to
> achievements earned.
>
> -mb
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20161219/26b40b0a/attachment.html>