bug#41082: nomodeset

[Danny Milosavljevic <dannym@scratchpost.org>]

[-- Attachment #1: Type: text/plain, Size: 2880 bytes --]

Hi,

On Wed, 6 May 2020 10:19:05 +0200
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> wrote:

> (but the video resolution should be adjusted, probably something higher than
> 1024x768 is supported by the system).

> We could add a uvesafb-service-type to its own gnu/services/….scm.

> Autodetection of the best usable resolution via v86d:testvbe could be
> added (however the best resolution usable with uvesafb may be less
> than the screen’s resolution).

That could maybe cause something not to work too.

I know I keep harping on that, but our generation feature only helps if there
actually is a previous generation to go back too.  So any "improvement" to
what the installer did, which obviously worked if Guix boots up, could also
cause the finished installation not to work--and without recourse.

(Hmm, but then there's nothing preventing us from reconfiguring twice in the
installer)

> One way such a uvesafb-service-type could work is exactly like in the
> installler.  Would it be right to add a uvesafb service that runs
> modprobe itself?

Why not have uvesafb-service-type extend kernel-module-loader-service-type
and give it a module to load unconditionally?
That would make the whole thing more declarative, which we usually want in
Guix.

If that's not possible, sure, the uvesafb service could also modprobe stuff
on its own.

> Another way is to extend etc-service-type for this the way I wrote at
> <https://lists.gnu.org/archive/html/bug-guix/2020-04/msg00320.html>.
> Extending other services seems cleaner, but in the discussions by
> Brice Waegeneire and Danny Milosavljevic (I put them in Cc) they were
> not really satisfied with etc-service-type.

Well, it's okay--but we could also make a proper service that would allow
other guix services to specify what kernel module configuration they expect
and also guix to find and report conflicts in the global view.

I think it's the right thing to do since the Linux kernel (and the hardware)
keeps global state.
So the programs that run in user space have to kinda negotiate what global state
is okay for everyone.  That negotiation is a lot easier for Guix to do if
it actually knows what is what, as opposed to an opaque etc directory that could
be anything.

Maybe that's premature and we could use etc-service-type in the mean time.
However, if a kernel-module-configuration-service appeared later then users
would have to migrate to it manually.  Not great.

> > kernel-module-configuration-service if/when it exists.  (I did not
> > know how to extend etc-service-type with a file created at runtime not
> > build time, but maybe kernel-module-configuration-service works
> > differently anyway.)  

I think Brice already had a nice mockup for the design, but I don't know whether
Brice plans to do it or not.  Brice?

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]