I have read in a couple of pages I came across while searching for information that it was deprecated but ...

It does not seem to be deprecated in Devuan: I edited the grub2 entry in Devuan, it was picked by when I did grub-upgate from PCLinuxOS and worked perfectly well when I selected to boot Devuan from PCLinuxOS.

But I also tried vga=ask and the screen said that it was a deprecated option.

Anyway, I also discovered something else, the real origin of the problem (and I am rather embarrased about this).

I use grub-customizer (yes, I know ... ) and it happens that when I was booting Devuan from PCLinux's grub2, I was inadvertently selecting a 'custom' entry which I do not have a clue about or where it came from but I now know that update-grub does not modify it.

It's so damn obvious so as to go unnoticed but makes prefect sense: update-grub only modifies the scripts generated by OS prober, a 'custom' script entry remains just that so it stays unchanged. No idea where it came from or when.

Having tried out by editing and then adding vga=845 to the Devuan grub2 (and seen it worked) and seeing that it was not getting picked up by the PCLinux grub2, I started pouring over the grub.conf files and that's when I discovered this uncomfortable tidbit.  =^/

The vga=845 bit is now part of the grub2 command line in Devuan and it does get picked up by the grub2 in PCLinuxOS when I update-grub.
I was just not selecting the correct entry. What a dick ...

I see (sort of): it is what I am saying above?

Hmm ...
It took me a good while to sort of understand and get a (light) hold on what was going on, so I'll pass on that. =-)
I'll chalk all this up to experience and a lesson learned.

Irrespectively of this, if vga=XXX is deprecated then there must be a substitute way to do the same thing.

With time, I'll see about trying out different options in grub2: after all, I boot into PCLinuxOS without VGA=XXX, vesafb gets loaded without nokmsboot present and still get the monitor resolution I want using the Nvidia drivers.

I gues I can mark this as [Solved] - hopefully it will be of use to others.

Thank you very much (to all) for your input.

Best,

A.

So ...
Now I have to see about why this is happening.
And how to get this to be permanent even if it means using the deprecated vga=XXX entry.

That option may not be deprecated in pclinuxos (yet) even if it is in devuan/related dists.

Anyway, grub on devuan recognizes dists based on /usr/lib/os-probes/mounted/90linux-distro and makes a config with /etc/grub.d/30_os-prober.

I'm assuming the pclinuxos grub does something similar, but editing the 30_os-prober file to handle devuan is probably not a great idea... Have a look at it to see what I mean ;-)

You could make a custom entry for devuan (on pclinuxos) in /etc/grub.d/40_custom based on the original menuentry from the pclinuxos grub, with an added vga= option. I assume that would end up last in your grub menu.

I decided to try editing the grub2 entry for Devuan on my PCLinuxOS, adding vga=845 (1280x1024x32) to the command line.
I know vga=XXX has been deprecated but thought it was worth a shot.

And just what do I see?

My Devuan boot screen shows up at a clean and tidy 1280x1024x32.
Checking further, I see that the vesafb is loaded.

[root@devuan groucho]# dmesg | grep vesafb
[    0.636130] vesafb: mode is 1280x1024x32, linelength=5120, pages=0
[    0.636134] vesafb: scrolling: redraw
[    0.636138] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    0.636157] vesafb: framebuffer at 0xfb000000, mapped to 0xffffb05a41800000, using 5120k, total 5120k

Exactly the same (save for the mapping) as when I boot Devuan independently of the PCLinuxOS grub2:

[root@devuan groucho]# dmesg | grep vesafb
[    0.645586] vesafb: mode is 1280x1024x32, linelength=5120, pages=0
[    0.645590] vesafb: scrolling: redraw
[    0.645594] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    0.645612] vesafb: framebuffer at 0xfb000000, mapped to 0xffffad6701800000, using 5120k, total 5120k

So ...
Now I have to see about why this is happening.
And how to get this to be permanent even if it means using the deprecated vga=XXX entry.

Any ideas?

Thanks in advance,

A.

Yes.

My first drive hosts a PCLinuxOS installation, it is set as the first drive to boot in the SAS adapter card and uses grub2.
My second drive hosts my Devuan ASCII installation, it is set as the second drive to boot in the SAS adapter card and uses grub2.
My third drive is an old W7 installation I keep for reference purposes, it is set as the third drive to boot in the SAS adapter card (getting scrubbed soon).

When I boot my rig it starts from the first drive and its grub2 installation offers me to boot into PCLinuxOS, Devuan ASCII or W7 from there.
If I remove this first drive (or if the drive fails), the rig boots from the second drive and its grub2 installation offers me me to boot into PCLinuxOS Devuan ASCII or W7 from there (obviously it does not find PCLOS).

If the first and second drives change places, the same thing happens, with the first OS order changed.

No. (I don't think so)

Each installation (PCLinuxOS first and a year later Devuan) was done with only one drive in the first bay.
That way I could only screw up only one thing at a time.=^D! 

I'm sorry but it's not too clear to me which of these I am doing.
It has worked well and I've always had an OS at hand, which was my primary objective.

For emergencies, I also have a TinyCore Linux installation on an old 1Gb pendrive plugged into a USB socket I discovered on the mobo (Sun Ultra24).   
It's actually saved my skin a couple of times.

I'm sorry for that oversight on my behalf.

What files would you need to see?

No.
The screen output at boot is in the correct console resolution.

Both PCLinuxOS and Devuan use the non-free Nvidia drivers.

I do not remember adding it so it must have been added by the Nvidia drivers installation?

Looking for some info on this, I came across a post from 2012 in the Mageia forum:
https://forums.mageia.org/en/viewtopic. … 971#p14396

I expect that the nokmsboot parameter was set after I installed the Nvidia drivers in PCLinuxOS. I have not seen anything acting up since I removed it.
Since then I have seen the Nvidia drivers get updated more than once, so maybe they have caught up and the nokmsboot is no longer needed.

It was not put in Devuan when I installed the Nvidia drivers.
Let's see if any problems arise.

--- EDIT ---

I may have come across something:

You're quite right.

From my PCLinuxOS terminal

[groucho@groucho ~]$ dmesg | grep vesafb
[    0.341689] vesafb: mode is 1280x1024x32, linelength=5120, pages=0
[    0.341692] vesafb: scrolling: redraw
[    0.341700] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    0.341724] vesafb: framebuffer at 0xfb000000, mapped to 0xffffac3140800000, using 5120k, total 5120k

The frame-bufefr is only loaded if I boot Devuan from it's own drive ie: not from PCLinuxOS's grub2.
From my Devuan terminal (booted independently)

[root@devuan groucho]# dmesg | grep vesafb
[    0.645586] vesafb: mode is 1280x1024x32, linelength=5120, pages=0
[    0.645590] vesafb: scrolling: redraw
[    0.645594] vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[    0.645612] vesafb: framebuffer at 0xfb000000, mapped to 0xffffad6701800000, using 5120k, total 5120k

--- EDIT ---

Thank you very much for taking the time to write this up.
Much appreciated.

Best,

A.

But I don't have this problem when I boot PCLinuxOS.
[...]
That's what I have. (I assume it is what you are referring to)
I boot PCLinuxOS from it's own installation drive and use that same grub2 screen to choose to boot Devuan if I want to.

You have two drives, each has the grub bootloader installed, each can boot independently and boot either OS?  I'd expect you to have set up each to chainload to the other - but that's not a given.

As I've said, there are two ways of doing this - directly booting the kernel (this only needs one grub for the whole lot) or chainloading to the other drive and that OS' own grub and then booting from that.

No one can really guess as to how you have this set up, as thus far you have not posted the grub configuration files from both OS.

To clarify somewhat, you've stated that "PCLinuxOS" does not have the same problem.  So presumably this boots with the correct console resolution - perhaps native resolution and the nvidia blob is installed there too?

nokmsboot is a parameter you might need for both OS with the blob installed.  If you are going to continue with the blob going forward, then just keep that as standard.

I believe your issues are most likely a result of how your hdd are mounted. What is taking care of that?

Let's see.
Here's what I got:

From PCLinuxOS

[groucho@groucho ~]$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.12.10-pclos1 root=UUID=82ca71e8-fba7-4e36-a086-27e3be13a48b ro nokmsboot noiswmd resume=UUID=464724a6-5814-4f99-b422-3e180aabed08
[groucho@groucho ~]$

[groucho@groucho ~]$ grep -A 15 evu /boot/grub2/grub.cfg | grep vmli
menuentry "Devuan GNU/Linux (on /dev/sda1)" --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.9.0-6-amd64--d6841f29-e39b-4c87-9c52-3a9c3bafe2d3' {
		linux /boot/vmlinuz-4.9.0-6-amd64 root=UUID=d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 ro
menuentry "Devuan GNU/Linux, with Linux 4.9.0-6-amd64 (on /dev/sda1)" --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.9.0-6-amd64--d6841f29-e39b-4c87-9c52-3a9c3bafe2d3' {
		linux /boot/vmlinuz-4.9.0-6-amd64 root=UUID=d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 ro nokmsboot
menuentry "Devuan GNU/Linux, with Linux 4.9.0-6-amd64 (recovery mode) (on /dev/sda1)" --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.9.0-6-amd64-root=UUID=d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 ro single-d6841f29-e39b-4c87-9c52-3a9c3bafe2d3' {
		linux /boot/vmlinuz-4.9.0-6-amd64 root=UUID=d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 ro single
[groucho@groucho ~]$ 

From Devuan

groucho@devuan:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.9.0-6-amd64 root=UUID=d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 ro
groucho@devuan:~$

groucho@devuan:~$ grep -A 15 evu /boot/grub/grub.cfg | grep vmli
	linux	/boot/vmlinuz-4.9.0-6-amd64 root=UUID=d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 ro 
		linux	/boot/vmlinuz-4.9.0-6-amd64 root=UUID=d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 ro 
		linux	/boot/vmlinuz-4.9.0-6-amd64 root=UUID=d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 ro single 
groucho@devuan:~$

As you can see, booting Devuan is done by both OSs in the same way with the same commands:

PCLinuxOS

linux /boot/vmlinuz-4.9.0-6-amd64 root=UUID=d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 ro

Devuan

linux /boot/vmlinuz-4.9.0-6-amd64 root=UUID=d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 ro

I removed nokmsboot (used prevent KMS driver from loading) from the PCLinuxOS stanza but it made no difference and PCLinuxOS still boots fine.
I cannot recall why it was there so I probably won't be put in again unless something happens.
Maybe Nvidia driver updates have made it redundant?

In any case, my Devuan istallation with non-free Nvidia drivers does not seem to require it.

But ...
There's all this in PCLinuxOS:

menuentry "Devuan GNU/Linux (on /dev/sda1)" --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.9.0-6-amd64--d6841f29-e39b-4c87-9c52-3a9c3bafe2d3' {

I have no idea if it is something that grub2 in PCLinuxOS has but the Devuan version does not or if it is something the PCLinuxOS packager included.

But I don't have this problem when I boot PCLinuxOS.

That's what I have. (I assume it is what you are referring to)
I boot PCLinuxOS from it's own installation drive and use that same grub2 screen to choose to boot Devuan if I want to.

Don't get how that would be done.
I could just try to update the Devuan grub2 without using the official repo (have to find a suitable *.deb file) but I fear possible havok.

Thanks to all for your input.

Cheers,

A.

Yes. I am using the Nvidia non-free drivers.

That's most likely why you have a text mode console (e.g. 80x50 characters).

I can't really advise on your grub setup, but if you're booting directly rather than chainloading, this could be the problem.  The best approach is to either just install one bootloader on one OS and use that to directly boot the other, or set up that bootloader to chainload to the other's bootloader.  It's actually pointless to try and replicate the same setup on both.

PCLinuxOS uses Grub2 2.02.0-3
Devuan uses 2.02Beta3-5

I don't know if there's any real difference between these two, but ...

Grub from pclinuxos  and grub from devuan may use slightly different boot command lines to boot devuan, you could check by doing:

cat /proc/cmdline

on both "devuan booted from devuan grub", and "devuan booted from pclinuxos grub", or by comparing the command lines used in both grub configs directly, something like

grep -A 13 evu /boot/grub/grub.cfg | grep vmli

in devuan and pclinuxos should work, although you would get multiple hits. Only the first one matters...

Sorry for the delay in answering.
Automatic subscription was off ... =^/

Yes. I am using the Nvidia non-free drivers.

It was the only way to get my two cards and three monitors to play nice.
RandR gets disabled because of Xinerama but I don't think it has anything to do with this.

I was looking into a possible version mismatch this morning.

PCLinuxOS uses Grub2 2.02.0-3
Devuan uses 2.02Beta3-5

I don't know if there's any real difference between these two, but ...

If both installations run of the same hardware and the problem in the Devuan installation arises when I boot it from the grub2 in PCLinuxOS and not with it's own grub2, then the problem seems to be with how grub2/PCLinuxOS "talks" with grub2/Devuan.

Is it a version mismatch or is it a configuration issue?
ie: is there something that grub2/PCLinuxOS needs to know or find to boot Devuan the same way it boots from its own grub2?

Thanks for your input.   =-)

Cheers,

A.

On most hardware made in around the last 15 or so years, once Linux KMS kicks in, your screen resolution will change to the LCD panel's native resolution.  If it isn't it may be due to some very old or obscure hardware or some changes you have made locally.

The other possibility is the proprietary AMD or Nvidia video drivers are installed?  As I recall these blacklist the Linux KMS/DRM stuff and load their own modules in their place.  But it's years since I've used any of those, so that could have changed.

I can't help much with grub as I don't use it, but it is only passing the console resolution you set to the kernel (bootloaders support passing all kinds of options to the kernel).  The best you will get out of it is probably going to be something like 1024x768 (but it has to be a supported VESA mode and not what you think your graphics adaptor or monitor can handle).

I'm not sure why it should influence the console resolution after linux was booted...

Yeah, once the system is booted it's up to the OS to use it's own settings. My guess is the kernel by default simply doesn't bother changing the resolution and just uses whatever grub has left behind. Way later console-setup kicks in and maybe changes stuff a bit. Just had a quick look and /etc/default/console-setup seems to have a VIDEOMODE option too. Not really sure what it does as i just use it to set an oldschool ascii friendly font. Besides all of that would happen way after the kernel boot messages are done anyways.

The grub versions from devuan, debian(-derivatives), pclinuxos and manjaro are pretty good at guessing, some others make a mess of it.

The resolution of the grub menu at boot is determined by the grub configuration from the 'local' linux version, not the grub configuration of 'other' versions.

I'm not sure why it should influence the console resolution after linux was booted...