Making up a chatty console screen on oracle enterprise linux 7

A lot of people, including me obviously, prefer to follow down the details of a boot process on a text console of oe linux. Unfortunaltely, populating such a detailed output is not the default setting after a fresh install of the operating system. You usually get a graphical boot progress animation, hiding most iff not all of the detail output, based on plymouth (rhgb). The boot screen dimension is another problem here, because following output on a 80×30 resolution is not fun kicking in. So where to start off? grub2, namely /etc/default/grub, GRUB_GFXMODE, GRUB_GFXPAYLOAD_LINUX, GRUB_CMDLINE_LINUX and some sort of update-grub I would think… but that’s wrong and even counter-productive for rh based distributions, really.

In fact, the integration of grub2 into oe linux is kind of different from the supposed picture given in https://www.gnu.org/software/grub/manual/html_node/index.html. That is, oe linux does not honour the variables being set with /etc/default/grub at all, GRUB_TIMEOUT being an exception on test, when recreating /boot/grub2/grub.cfg. There is no update-grub, like on debian likes, and moreover, do not use grub2-mkconfig -o /boot/grub2/grub.cfg, as recommended all around the net, on oe linux, because grub2-mkconfig may rewrite your kernel boot menue titles such that your default kernel setting may become stale (http://brainpan.io/wiki/Grub_2_Tips_%26_Tricks). Use grubby, see below.

Ok, instead of separating the grub2 boot variables in /etc/default/grub, oe linux derives any boot settings to be applied to a current kernel for reboot or most importantly for a new kernel on install from what is already present in /boot/grub2/grub.cfg for the running kernel. Its another approach, for whatever reason, like it or not. Changing the boot settings for the current kernel involves a script called grubby (https://www.mankier.com/8/grubby). Going for a kernel on install with yum executes the script new-kernel-package (https://www.mankier.com/8/new-kernel-pkg), which in turn again uses grubby under the covers. So what you need to make shure is that anything envisioned for modification or installation will already be present in /boot/grub2/grub.cfg. Check!

Tackling native screen resolution problems on virtual ubuntu guest installs

I remember a time when virtual box users got stuck when trying to run full screen ubuntu guests on ultrabooks with the (as of that time) unusual screen resolution of 1366×768 pixels. Of course, 1366×768 pixels was quite an esoteric resolution at the times of virtual box 4.0.x or so and the emulated graphics driver was simply not (yet) aware of such a circumstance. However, trying to set up an current ubuntu 12.10 guest on the latest vmware player 5.0.2 environment, targeting another 1600×900 ultrabook full screen resolution, showed up to produce the same issue again and I’m not the very first to learn alike, see the vmware threads for example.

The basic problem, as depicted above, is that the guest os just does’nt see the actual native resolution of the hardware because the emulated graphics driver does not provide or list it on request. It will, on the other hand, be able to run that resolution though. Ever tried to find the missing resolution in your display settings with no luck? Then switched the guest os to full screen and, plop, it is there? Then bounced the guest os and the game starts from scratch (and you get this oversized X error window of unsuccessful attempts to apply the latest resolution setting in ~/.config/monitor.xml)? Welcome at Denny’s!