> On 09/09/2013 11:48 AM, Kamil Paral wrote:
> >> On 09/06/2013 10:15 AM, Jiri Eischmann wrote:
> >>> Can this not be done automatically? If the system fails to boot because
> >>> of significant hardware changes, it's an obvious option to regenerate
> >>> initramfs. I can't image a normal user go to the rescue mode and run
> >>> "dracut --regenerate-all". Not that it's difficult to do it, but the
> >>> discoverability of the solution is bad.
> >> This has been discussed in the past and if we are going to head down
> >> that road we need a proper end user friendly UI rescue environment for
> >> the core/baseOS which automatically scans things for problem and
> >> proposes to fix that for the novice end user.
> >>
> >> I'm pretty sure nobody is against this but as usual as someone has to do
> >> all that work...
> > It should have been a prerequisite for dracut host-only feature.
>
> It's nonsense having an full blown rescue environment as an requirement
> for dracut-hostonly feature.
>
> JBG
I haven't spoken about "full blown". But this feature caused two things:
a) performance (boot speed) went up
b) robustness went down (change of hardware "breaks" Fedora)
I might be speaking with my QA hat on, but we should really strive hard to keep and increase the robustness of our system. Before host-only initrd was approved, we should have had a prerequisite that would eliminate the biggest drawback. Especially for the general audience the current behavior is a showstopper - they are not able to invoke 'dracut --regenerate-all' after they change their hardware. The implementation is not that important, something is better than nothing. A few ideas:
a) regenerate initrd automatically on every system rescue boot
b) present a simple ncurses dialog on every system rescue boot, that allows the user to regenerate initrd ("find new hardware") or continue booting to DE
c) if a standard boot fails, or if we detect a new hardware during that boot, automatically regenerate initrd and reboot the machine
Sure, those are just rough ideas, full of problematic use cases and whatnot. But some of them might not be _that_ hard to implement. And any of those would definitely be better than having nothing. Not to mention that our bright developers' minds would surely think of something even better.
And that's what we should have had as a prerequisite - having _some_ solution. But we ended up as always - having a cool feature and saying "RTFM!" to all our general users who get bitten by it.
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
