On Sun, Feb 12, 2017 at 5:07 PM, Chris Murphy <li...@colorremedies.com> wrote: > On Fri, Feb 10, 2017 at 4:34 PM, John Hendy <jw.he...@gmail.com> wrote: > >> >> I did a couple of things after I sent this. For one, I ditched >> arch/root. Now I just have arch. That let me get away from the call to >> a nested subvol. >> >> That on it's own didn't work, but I started playing with the >> rootflags. I haven't tried one by one, but re-specifying my mount >> options seems to work. So instead of just rootflags=subvol=arch, I >> have: >> >> rootflags=compress=lzo,subvol=arch,ssd,discard >> >> Is there a reason that would make a difference? > > The only change that should matter is subvol path change, and I'm not > even convinced of that. But I don't even know where exactly the > failure is. It sounds like the failure happens right away and you get > back to the syslinux menu; that suggests to me the kernel isn't even > loaded let alone executed, and the boot parameters don't matter until > the kernel is executed. > >
Indeed, and see my most recent reply. Unfortunately, I think the issue might have been paring down extra options (I had some libata.force stuff), including the loading of intel-ucode at the same time I was adding explicit rootflags options. Thus, compress=lzo stood out as a notable change, but I think I overlooked the real culprit which was intel-ucode. So, as you said, I think the issue was it not even getting past the bootloader and not what I initially thought. John > > -- > Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
