Bug 859042

Does YaST set the value correct in the config files?

(In reply to comment #1)
> Does YaST set the value correct in the config files?

Apparently it does.

In fact, after some more experiments, I think this is neither yast problem nor initrd problem. I think it is rather that kernel and/or udev behaviour changed since opensuse 11.3, so that i915 gets loaded automatically anyway (just maybe later in boot sequence if NO_KMS_IN_INITRD is set) by means of standard device discovery and kernel module search (by vendor_id/device_id etc) and i915 in turn pulls in kms and everything.

Now, my original reason for using NO_KMS_IN_INITRD was actually this: "Do not load any graphics drivers until _really_ required by some graphics subsystem (like X)". In 11.3 NO_KMS_IN_INITRD did the trick perfectly fine. In 13.1, it is essentially useless, although formally it does work. I'm now going to study udev a little bit more to try to make it skip autoloading graphics card module(s) if NO_KMS_IN_INITRD is set.

Thanks, changing assigner away from YaST.

Disable plymouth(8) ... from manual page

DESCRIPTION
       plymouth  is  a  graphical  boot  system for Linux which takes advantage
       of the kernel-based mode setting (KMS) available for modern graphic cards
       to provide a seamless, flickerfree and attractive boot screen.

beside this you should also disable the graphical mode in grub2 that is to set

  GRUB_GFXPAYLOAD_LINUX=text

in /etc/default/grub and run

  grub2-mkconfig -o /boot/grub2/grub.cfg

afterwards. This bug does not belong to systemd nor udev.

(In reply to comment #4)
> Disable plymouth(8) ... from manual page
> 
> DESCRIPTION
>        plymouth  is  a  graphical  boot  system for Linux which takes advantage
>        of the kernel-based mode setting (KMS) available for modern graphic
> cards
>        to provide a seamless, flickerfree and attractive boot screen.
> 
> beside this you should also disable the graphical mode in grub2 that is to set
> 
>   GRUB_GFXPAYLOAD_LINUX=text
> 
> in /etc/default/grub and run
> 
>   grub2-mkconfig -o /boot/grub2/grub.cfg
> 
> afterwards. This bug does not belong to systemd nor udev.

No plymouth installed here, and graphics in Grub was disabled of course, I should have mentioned this, sorry.

Now, I have finally "solved" the problem by adding
blacklist i915
into /etc/modprobe.d/99-local.conf

This still allows automatic loading of i915 by X and manual loading by modprobe i915, but initially after boot text mode is retained (and this is all I want).

Obviously this is not a generic solution, but I'd suggest that some reminder in the description of NO_KMS_IN_INITRD (or elsewhere) mentioning grub, plymouth and autoloading by pci_id would not hurt at least.

(In reply to comment #5)

I'd like to know what the advantage is not using graphical mode if available? Speed can not be a reason to switch off graphical mode but use text mode only. In my experience the graphical mode systems do boot faster ... therefore I'd like to know what advantage do you have by switching off graphical mode.

(In reply to comment #6)
> I'd like to know what the advantage is not using graphical mode if available?
> Speed can not be a reason to switch off graphical mode but use text mode only.
> In my experience the graphical mode systems do boot faster ... therefore I'd
> like to know what advantage do you have by switching off graphical mode.

Reasons are various, although admittedly, not all of them are critical, but still:

* In case this box is (kind of) a server, not loading additional unnecessary (and quite complicated and possibly somewhat buggy) kernel-space code is good practice;

* Unless I use some huge 28' monitor, modern graphics resolution is too high for my eyes to comfortably read default console font characters as they become tiny (Yes this can be adjusted, but no friendly fool-proof dialog is provided for that anyway);

* Text-mode output is guaranteed to be usable (enough for urgent administration/repair) on ANY random monitor having vga connector, be it shiny new lcd from a shop today or 20 y.o. dusty crt dinosaur, and moreover, it does not matter if you have it connected at boot time or plug at some point later, it will unconditionally "just work";

* You can test/debug/update/tune i915.ko (or whatever appropriate) with comfort and no risk of suddenly being unable to even login; (This can also be achieved by using e.g. some backup kernel in bootloader, but that means more burden and implies some more expertise);

* Linux distributions are still about freedom: if you don't want something, you probably prefer to remove/disable it (well, unless absolutely technically pointless).

I think we need to differentiate drm/kms framebuffer and firmware (efifb/vesa) framebuffer here. The gfxpayload would only affect the firmware framebuffer, not the kms/drm here.

That is when you set nomodeset and gfxpayload=keep at the same time, the vesafb or efifb will start according to the mode setting done by grub and is actually conformed to NO_KMS_IN_INITRD.

NO_KMS_IN_INITRD doesn't equal to text mode, mode setting done by other means (firmware calls) is still possible.

(In reply to comment #8)

I'm aware ;) 

The trick is to use the same resolution for grub and text console as used later on with kms/drm. The problem is that most user arn't aware that this might happen.

Nevertless I'd like to know which before X11 is loding the kms/drm module if not done in initrd (mkinitrd or dracut).

Please show me the result of

   sudo lsinitrd /boot/initrd | grep i915.ko

also

   sudo journalctl --all | grep 'Inserted module'

clearly without the blacklist line

(In reply to comment #9)
> Please show me the result of
> 
>    sudo lsinitrd /boot/initrd | grep i915.ko
> 
> also
> 
>    sudo journalctl --all | grep 'Inserted module'
> 
> clearly without the blacklist line

zhubr-wrk:~ # lsinitrd /boot/initrd | grep i915.ko
zhubr-wrk:~ # journalctl --all | grep 'Inserted module'
Jan 20 19:45:37 zhubr-wrk systemd[1]: Inserted module 'autofs4'
Jan 20 19:45:37 zhubr-wrk systemd-modules-load[270]: Inserted module 'sg'
zhubr-wrk:~ # lsmod | grep i915
i915                  710199  1
drm_kms_helper         52710  1 i915
drm                   313440  2 i915,drm_kms_helper
i2c_algo_bit           13413  1 i915
video                  19507  1 i915
button                 13952  1 i915
zhubr-wrk:~ # dmesg | grep i915
[    3.849528] i915 0000:00:02.0: setting latency timer to 64
[    3.916394] i915 0000:00:02.0: irq 43 for MSI/MSI-X
[    4.157030] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[    4.157058] i915 0000:00:02.0: registered panic notifier
[    4.161949] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
zhubr-wrk:~ #

It feels like loading is initiated by either videocard's pci_id or maybe something like acpi:lnxvideo, but I've failed to find any traces of actual initiator.

Taking former udev maintainer into CC .. maybe Robert knows more about this.

Whats the actual question here from udev point of view?

(In reply to comment #12)

The question is which rule or similar triggers the load of KMS/DMR modules

Not as I know of. When i915 is loaded modeset is enabled by default as I know. It might not happen in the initrd, but it will have soon after.

OK ... maybe a stupid question: could it be that loading console fonts may cause a resize which then trigger loading the KMS/DMR modules for modeset?

If you are asking me, I wouldn't know. Usually KMS/DRM modules are loaded by udev because there is a kernel event.

NO_KMS_IN_INITRD variable has nothing to do with udev at all, nor it effects udev in any way.

The user can boot with modeset=0 or i915.modeset=0.

@ Nikolai ... this bug becomes more and more invalid.  You may try to set

     nomodeset modeset=0

or only

     nomodeset

on the kernels command line[1] but disabling kernel events by default due NO_KMS_IN_INITRD looks like no nogo for me.

To be able to boot a system in save mode grub already has normally a kernel line which includes nomodeset and x11failsafe.


[1] /usr/src/linux/drivers/video/console/vgacon.c ... 

    /* force text mode - used by kernel modesetting */
    __setup("nomodeset", text_mode);

(In reply to comment #17)
> on the kernels command line[1] but disabling kernel events by default due
> NO_KMS_IN_INITRD looks like no nogo for me.
> 

Agreed. As no clean solution is possible, I'd suggest it is OK to dismiss the issue. Maybe just add a reminder warning somewhere (e.g. in Yast's description for NO_KMS_IN_INITRD, for the lack of a better place)

(In reply to comment #18)

Please give the kernel command line parameters from comment #17 a try ... which of them are working (without blacklisting the i915 module)

In the meanwhile I'm reassigning this to the documentation people ... also the YaST2 or mkinitrd/dracut people may add a comment to the description of

    /var/adm/fillup-templates/sysconfig.kernel-mkinitrd

to mention then the kernels parameter

(In reply to comment #19)
> Please give the kernel command line parameters from comment #17 a try ... which
> of them are working (without blacklisting the i915 module)
> 

With both nomodeset modeset=0 and nomodeset only, visible result is the same:

Initially in runlevel 3, i915 not loaded, text mode is retained, console is OK.

After going init 5:

Normal graphical login appeared. It is possible to login, but after closing graphical session (by either logout or by pressing Crtl+Alt+F1) the screen goes pure black forever. Using ssh login I can e.g. see:

zhubr-wrk:~ # dmesg | grep i915
zhubr-wrk:~ # dmesg | grep drm
[    4.086340] [drm] Initialized drm 1.1.0 20060810
[    4.107260] [drm:drm_pci_agp_init] *ERROR* Cannot initialize the agpgart module.

So right now, specifying "nomodeset" on my box basically breaks things hard (as opposed to harmless blacklisting i915).

OK then nomodeset nor modeset=0 should not be mentioned but really the last resort for getting a not bootable system due DRM/KMS up and running without X11.

Nevertheless the trick/workaround of using a blacklist for a specific video kernel module in the file

   /etc/modprobe.d/99-local.conf

could be mentioned.

I'm wondering what this bug is about...  Is it about a misleading yast help text?

(In reply to comment #22)
> I'm wondering what this bug is about...  Is it about a misleading yast help
> text?

Essentially yes, I suppose... Adding more up-to-date hints to the description text would be good.

(In reply to comment #23)
> (In reply to comment #22)
> > I'm wondering what this bug is about...  Is it about a misleading yast help
> > text?
> 
> Essentially yes, I suppose... Adding more up-to-date hints to the description
> text would be good.

Ok, thanks for confirming--thus, we are back to square 1.

Please adjust the yast help text.  Or does yast just display the text from /etc/sysconfig/kernel?

## Type:        yesno
## Default:     ""
## Command:     /sbin/mkinitrd
#
#
# This variable disables the initialization of KMS in the initrd
# by not including the modules required for KMS even though KMS is
# supported on the underlying hardware.
# After changing run mkinitrd again.
#
NO_KMS_IN_INITRD="no"

Yes, YaST uses the description from the sysconfig file. So the documentation
must be changed there.

This bug does *not* belong to systemd.  For systemd it does not matter nor does it use NO_KMS_IN_INITRD ... it simply uses /dev/console.  The NO_KMS_IN_INITRD has to used by mkinitrd or dracut and nothing else.

Beside this: the documentation says that no KMS is loaded into the initrd ... it does not say that no KMS is loaded after initrd has finished.

IMHO it is up on YAST or any other configuration module to blacklist the i915 module ... but as already said: it is not specified with NO_KMS_IN_INITRD ... this would require soemthing NO_KMS_WITHOUT_X11, nevertheless this does not belong systemd nor udev.

Back to YaST people

Sorry, I didn't have time for this issue. In 42.1 the NO_KMS_IN_INITRD option is not present anymore, thus I guess the bug does not happen anymore.