You are not logged in.
tynman, Thank you.
Let's start at the beginning.
You insert the Bunsenlabs cd.
ISOlinux magically reads your bios and sets your screen (try to forget that).
You START the live cd/installer and the kernel loads.
you install bunsenlabs. yay!
Now you install grub to the mbr, right? WHERE does grub get the screen info?
From the running kernel when you booted the install cd. ... Get it?
What gives grub those settings?
The legacy drivers for all the graphics cards provide this info to the bios, etc.
The legacy drivers are buggy.
Linus Torvalds et al. created a better way to get this info. (the first item in my second post.
This item SHOULD be enabled by default, as it does a better job.
If that item doesn't, the system falls back to the legacy drivers for the info.
I've tested the item above, and it allows for significant change.
I don't know if it will fix the op's problem.
Needs to be done anyway, with about twenty other pressing items.
How sleekmason?
Follow my guide (or any other you want!)
recompile the kernel with support for the above item.
unpack the iso.
switch kernels.
repack
enjoy the new method of retrieving all this info with a better boot screen and less graphics problems for the distro overall.
ohnonot. Before grub. Framebuffer.
Although grub doesn't get anything from the Linux kernel when grub is running -- because Linux isn't loaded yet -- ....
Exactly! Before the kernel loads the screen settings, grub depends on the settings it received during it's own install. It is a bootloader, and must make sure that the first thing you see is readable. (now anyway).
grub's configuration typically does happen while Linux is running (i.e., when we run the update-grub program).
Yes, but grub can only control items within grub.
Thank you tynman for asking questions that illuminate.
I would much rather be explaining how the definitions provided in the kernel configuration file are not always accurate, or discuss better ways of implementing new features. Thank you for your consideration.
Online
I would like to clarify that any who would like to try this out themselves, can do so with no harm to their system.
Working with kernels is a great way to learn more about how Linux works. The beauty of this is that IF a kernel fails after installation, just reboot into the old kernel and delete the offender!
You will need to download either the Debian Linux-Source from apt, or the stable (recommended) tarball package from the Linux Kernel Archives. (all in the guide).
All of the direction on how to get started are in the guide, with the fiddly bits being copy and paste. It has never been easier to do this.
The kernel guide is: HERE
When you get to "make menuconfig" after "make oldconfig", Drop down to:
Bus options (PCI etc.) ---> and go to the end of the list, and enable
Mark VGA/VBE/EFI FB as generic system framebuffer
Save, exit, follow the guide to install. reboot. Tell us how it went!
It is that simple, and this is one change out of many that could make your computer more stable, faster, and have better security.
On a note, When doing the "make oldconfig", you will see about 200-300 items flash by as you hold down the ENTER key. These are all of the changes to the Linux Kernel since the last time it was updated.
Now this part is important, even while they are adding new and exciting features, (200-300 items flying past), they only enable those that are deemed absolutely safe, and won't disrupt a persons current settings.
All 200-300 items, have NEVER been checked, or they wouldn't exist in the "make oldconfig". This also means that even BEFORE the current 4.9 kernel, there were changes that have never been addressed. Changing slab to slub should have been done 2014!
This includes the above code, new legacy drivers for nvidia, Changes in the allocator, general system calls that are deprecated and need to be removed, the addition of bfq as an option, debugging that the end user will NEVER use, security features unwarranted (anybody using yama over selinux?), staging drivers that keep getting added that just make the kernel bigger, and the list literally goes on and on.
Eventually, probably within a year or so, simply copying the Debian image won't cut it. There are already a lot of changes that were not initially enabled, but since, have become the default.
Anybody that needs help with this should post in the kernel thread. Unfortunately, the OP's problem has to be addressed before grub, so it won't change the initial problem without the fix being baked into the distro. They can however, get a better boot display as it scrolls by by enabling the above.
I will always help anybody who needs it. Generally pretty damn fast.
but my understanding of what he/she is saying is ...
Ah, why not. Male, age 50, wife, grandkids, backpacking, guitar, linux kernel. I am a stone mason. My profile picture is of a drawing I made when I was 15 or so. I think it tells a good story:)
for heaven's sake.
i think we're going to have a lot of fun with you.
I hope so! I like you guys
Last edited by sleekmason (2018-06-30 13:01:36)
Online
Doesn't the live kernel supply grub the initial screen settings that grub uses for it's settings on install from live cd?
No. The live system is self-contained, unpacked from a squashfs file and used for the live session. The live kernel is active then, but not at install time, when it's the Debian Installer kernel at work. During install, the live system files are copied into the new installed system, with some changes, like the grub and apt configuration which is handled by the installer. The live kernel then takes over on the reboot into the installed system, by which time it is unable to change the grub configuration, which was done by the debian-installer's grub-installer package.
BTW @Beep, I don't suppose running 'sudo update-grub' makes any difference to the grub screen?
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
Howdy Johnraff,
Thank you for responding. So, to clarify, Where does grub get it's initial screen settings?
Since Grub is not part of the live squash file, The Debian kernel in the installer becomes active before install, creating all of the finished paths and other computer particulars.
Grub is also a part of that install package, and takes place after the Debian kernel has loaded, grabbing it's initial settings from the information provided by the Debian Kernel.
When you insert the live cd (et al), and choose to install, the Debian kernel is the first thing to boot. Grub does not exist yet. It gets installed last.
Grub doesn't create it's own initial parameters. It grabs them from the running kernel during install.
Online
Where does grub get it's initial screen settings?
...the grub configuration, which was done by the debian-installer's grub-installer package.
Grub doesn't create it's own initial parameters. It grabs them from the running kernel during install.
Grub doesn't run during install (except to display the EFI boot screen, which is quite separate). Grub's config is written during install. Grub itself runs at the next boot.
I think you might be slightly overemphasising the role played by the kernel here. The Debian Installer consists (mostly) of a lot of shell scripts, but it would be misleading to say that "grub is configured by the shell".
---
Meanwhile, @Beep's problem is no nearer solution.
@Beep, how about if you set a different image altogether? Does everything look like that?
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
Okay, I'll stay in userland and leave the kernel go for now.
I think the OP's Grub pic is stretched. The options for this are located in Grub.d.
The line that might make the difference is in 39_bunsen-text-colours:
$(sed -nr 's/^.*background_image[ \t]+((-m|--mode)[ \t]+(stretch|normal)[ \t]+)?([^; \t]+).*$/\4/p' "${grub_cfg}.new")
Grub normally sets the picture as "normal" I think Beep's is being set as "stretch" somehow?
The OP could try:
sudo grub-mkconfig
That should reset using their current display settings, but it probably won't.
I suppose one possible test would be to comment out in /etc/default/grub:
GRUB_GFXMODE=800x600 The numbers may be different.
If this is commented out, grub will use the highest possible resolution. This may lead to some insight as well. This also might not work as expected depending on the initial settings gathered by grub. If it doesn't, it should just boot the first available, bypassing the screen entirely.
Last edited by sleekmason (2018-07-05 13:40:46)
Online
The line that might make the difference is in 39_bunsen-text-colours:
$(sed -nr 's/^.*background_image[ \t]+((-m|--mode)[ \t]+(stretch|normal)[ \t]+)?([^; \t]+).*$/\4/p' "${grub_cfg}.new")
This command is just to find what image has been set as grub's background. Easily tested - run it on grub.cfg:
john@helium-dev:~$ sed -nr 's/^.*background_image[ \t]+((-m|--mode)[ \t]+(stretch|normal)[ \t]+)?([^; \t]+).*$/\4/p' /boot/grub/grub.cfg
/usr/share/images/bunsen/grub/john.png
So it returns my custom grub image. That is then used in a test to see if the default BL image is being used or not, to determine whether to add BL text colours or not. The actual command setting the background image is not edited in any way, so 'stretch' vs 'normal' does not come into it. (read up on sed and regular expressions to figure out what's happening.)
Grub normally sets the picture as "normal" I think Beep's is being set as "stretch" somehow?
That's easily checked too. In my case:
cat /boot/grub/grub.cfg | grep 'background_image'
if background_image /usr/share/images/bunsen/grub/john.png; then
The background image is set via the (complicated) standard grub config. BL doesn't interfere in any way.
The OP could try:
sudo grub-mkconfig
That should reset using their current display settings, but it probably won't.
It certainly won't (grub-mkconfig outputs to stdout by default). The command on Debian is:
sudo update-grub
which I suggested a couple of posts earlier.
I suppose one possible test would be to comment out in /etc/default/grub:
GRUB_GFXMODE=800x600 The numbers may be different.
Sorry if I seem to be demolishing your suggestions one by one, but GRUB_GFXMODE is already commented out by default.
---
Anyway, to make any progress on this, we need some feedback from the OP.
@Beep, could you try:
1)
sudo update-grub
See if any strange messages appear and if the grub image display changes.
2)
cat /boot/grub/grub.cfg
Post the result here.
3)
Install the package desktop-base (you can remove it again later), and on Menu>System>Edit Debian Alternatives>desktop-grub choose one of the new (non-Bunsen) images available. These images ought to work.
And let's take it from there.
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
johnraff, please take another look at the image in post #1.
it's an actual photo of the screen, but it's good enough and i clearly recognize that the colors are extremely reduced. i can recreate this in gimp by choosing Image => Mode => Indexed...
Beep's picture for comparison:
https://images2.imgbox.com/c0/8b/vbthkHSn_o.jpg
i don't think this has anything to do with resolutions...
Last edited by ohnonot (2021-06-07 16:19:14)
Offline
Let's wait for beep to respond, he's the only one who's reported this issue AFAIK.
I don't care what you do at home. Would you care to explain?
Offline