Boron Beta 2 isos available, amd64 and i386

rbh · 2023-10-17 09:29:36

rbh wrote:

In 64 bit VirtualBox vm, with Guest -additions installed, iso-boot with grml-rescueboot works, but with errors.

Just to clarify: That is the 32 bit iso.

johnraff wrote:

@hhh and @rbh I have no further ideas why the isoa are not booting in your situations. But could I ask two obvious questions:
1) Do the BL 32bit and 64bit beta2 isos you downloaded, successfully boot on any other machines?

For me, it is only iso-boot with grml-rescueboot of 32 bit iso, that is problematic. Iso boot, is a nice way to testdrive on hardware or start a "rescue mission", without needing to write iso to usb-stick.
As I wrote: on 32 bit hardware, 32 bit iso works but report errors. Same error from isobooting 32 bit iso in 64 bit VirtualBox vm. In Virtualbox VM, you do not need to use grml-rescueboot for booting iso image. But those problems should be reported in the release notes.
Written to usb-stick, the 32-bit iso boots on both 32 bit and 64 bit hardware.

2a) How about older BL isos like Beryllium or Lithium?

Yes, there has been problem before with some versions. Do not remember which versions. Can test later.

johnraff · 2023-10-18 02:47:30

@rbh thank you for clarifying.

For me, it is only iso-boot with grml-rescueboot of 32 bit iso, that is problematic. Iso boot, is a nice way to testdrive on hardware or start a "rescue mission", without needing to write iso to usb-stick.
As I wrote: on 32 bit hardware, 32 bit iso works but report errors. Same error from isobooting 32 bit iso in 64 bit VirtualBox vm. In Virtualbox VM, you do not need to use grml-rescueboot for booting iso image.
Written to usb-stick, the 32-bit iso boots on both 32 bit and 64 bit hardware.

If I'm reading this correctly:
1) Both 32bit and 64bit Beta2 isos, if written to a USB stick, will boot on the hardware you tested on.
2) On VirtualBox, using an iso file: the 64bit Beta2 iso will boot successfully, the 32bit Beta2 iso will boot, but with error messages.
3) Using grml, 64bit Beta2 iso will boot successfully, the 32bit Beta2 iso will boot, but with error messages.

Is there a difference between the 3) result using grml on physical hardware compared with trying to use it with VirtualBox? (I understand that grml is not necessary with VirtualBox - I presume you are using it in this case as a test.)

Can you test a Debian or Ubuntu iso with grml to see if they have the same issues or not? In fact, I doubt if Ubuntu are releasing any 32bit isos now, and Debian will soon stop, but there might still be something.

I wonder if, as 32bit support is slowly being dropped everywhere, there might be a 32bit issue with grml itself?

But those problems should be reported in the release notes.

Presuming we are unable to find a way round the remaining issues, could you write a suitable paragraph to put in the Release Notes?

JasonMehmel · 2023-10-21 19:16:33

General question... I've been eyeing this thread but haven't been studying it deeply.

Is Boron ready for those of us 64bit users using Beryllium? (As in, it's as safe as Beryllium was, but might cause things to go 'crunch-bang' anyway?

rbh · 2023-10-21 20:14:48

JasonMehmel wrote:

Is Boron ready for those of us 64bit users using Beryllium? (As in, it's as safe as Beryllium was, but might cause things to go 'crunch-bang' anyway?

Yes. There is som minor glitches but nothing serious. It is good enough for installing or upgrade.

rbh · 2023-10-22 01:06:22

johnraff wrote:

@rbh thank you for clarifying.

Took you quit a wile to read wthat I wrote about isoboot..

If I'm reading this correctly:
1) Both 32bit and 64bit Beta2 isos, if written to a USB stick, will boot on the hardware you tested on.

Once again: "For me, it is only iso-boot with grml-rescueboot of 32 bit iso, that is problematic." So, boot from usb stick, with 32 bit iso, on 32 bit hw or 64 bit version on 64 bit hardware, works ok, except for error message when booting 32 bit iso.

2) On VirtualBox, using an iso file: the 64bit Beta2 iso will boot successfully, the 32bit Beta2 iso will boot, but with error messages.

Yes. Initialy, I thought that the problem with isoboot I reported on beta1, still existed. But, that was only before installing VB guest additions.

3) Using grml, 64bit Beta2 iso will boot successfully, the 32bit Beta2 iso will boot, but with error messages.

You mean isboot with grml-rescueboot? Yes.

Is there a difference between the 3) result using grml on physical hardware compared with trying to use it with VirtualBox?

No.

Can you test a Debian or Ubuntu iso with grml to see if they have the same issues or not?

The last Debian 32 bit live, is 11.8. The LXQT version, could not launch the desktop. Ok to log in on tty 1-6.

I wonder if, as 32bit support is slowly being dropped everywhere, there might be a 32bit issue with grml itself?

There is no problem isoboot grml32 iso, with grml-rescueboot, on 32 bit hardware. Neither with MX23 32 bit.

Presuming we are unable to find a way round the remaining issues, could you write a suitable paragraph to put in the Release Notes?

Ok.

johnraff · 2023-10-23 04:51:32

Since my last post I installed grml-rescueboot on my physical system and tried 5~6 of the isos I had available. Only grml64-full_2014.11.iso successfully booted to a desktop. The grml64-small_2022.11.iso which 'sudo update-grml-rescueboot -a 64 -t small' installed automatically failed part way through the boot process. Debian live, Beryllium, Finnix and Ubuntu all failed at some point - some produced a grub menu, some not even that.

Maybe it's related to my LVM setup, maybe web searching would produce an answer.

unklar · 2023-10-26 06:38:28

I would like to stop the 'shining through' of windows in picom.conf.

I have already entered these two, librewolf and keepassxc. However, this has no effect. What is missing?
]snip

# shadow-exclude = []
shadow-exclude = [
    "! name~=''",
#    "name = 'jgmenu'",
    "name = 'tint2'",
    "name = 'Notification'",
    "name = 'wbar'",
#    "name = 'Plank'",
    "name = 'Docky'",
    "name = 'Kupfer'",
#    "name = 'xfce4-notifyd'",
    "name *= 'VirtualBox'",
    "name *= 'VLC'",
    "name *= 'picom'",
    "name *= 'Chromium'",
    "name *= 'Chrome'",
    "name *= 'Librewolf'",
    "name *= 'Keepassxc'",
    "class_g ?= 'plank'", # see wintypes
    "class_g ?= 'Conky'",
    "class_g = 'Kupfer'",
    "class_g = 'Synapse'",
    "class_g ?= 'Notify-osd'",
    "class_g ?= 'Cairo-dock'",
#    "class_g ?= 'Xfce4-notifyd'",
    "class_g ?= 'Xfce4-power-manager'",
    "class_g ?= 'librewolf'",
    "class_g ?= 'keepassxc'",
    "_GTK_FRAME_EXTENTS@:c"
];

snap[

johnraff · 2023-10-26 07:19:00

^This is transparency not shadows.
Go to the # Transparency / Opacity # section that starts around line 160 of picom.conf.
Possibly also the wintypes settings around ~474.

unklar · 2023-10-26 07:46:17

Thanks, @johnraff !

done (wintypes did not need to be changed)

ghorvath · 2023-12-07 18:58:15

I installed the beta 2 amd64 ISOs on multiple machines, desktops and laptops. So far everything seem to work reasonably well. Nicely done!
(Spent half a day installing the nvidia drivers to my machine, but that is not Boron's fault byany means. )

One thing I'd like to note, though: after installing the beta, then bl-welcome runs and updates the system, then I reboot and a bunch of new bunsenlabs configs take effect. At this point, tint2rc points to boron-light-vertical.tint2rc, which has the following under Panel:

panel_position = center left vertical
panel_layer = bottom
panel_monitor = all

I have a multi-monitor setup, primary monitor is left from secondary (and somehow I have a feeling that this is the most generic setup for multi-monitors). However, maximizing windows is completely broken with the above tint2 setting. Problem is that "panel_monitor = all" sets tint2 to both monitors, and they are vertical due to panel_position. Hence a tint panel will appear in the middle of the 2-monitor Arand SCREEN.

Changing "panel_monitor = 1" fixes the issue, maximizing now works properly on both monitors. I would still prefer that when I open a new app (like a terminal or something), it would appear on the monitor where my mouse cursor is (currently it always opens on the primary), but for now I can live with this.

However, I'm wondering
1. Why tint2rc is by default a vertical theme instead of the well-known horizontal one?
2. Why is panel_monitor=all used in this case, why not use "panel_monitor=1" instead?
+1. Why is the default theme now a light theme, instead of the previously usual dark themes? Or is that just my preference, and even Beryllium shipped with default light theme?

Love the product, keep up the good work!

grubernd · 2023-12-07 19:16:00

ghorvath wrote:

I would still prefer that when I open a new app (like a terminal or something), it would appear on the monitor where my mouse cursor is (currently it always opens on the primary), but for now I can live with this.

For me that is an Openbox config, in the "WM Preferences" util go to Windows and set "Placing Windows" to "The monitor with the mouse".

johnraff · 2023-12-08 05:48:48

ghorvath wrote:

I'm wondering
1. Why tint2rc is by default a vertical theme instead of the well-known horizontal one?
2. Why is panel_monitor=all used in this case, why not use "panel_monitor=1" instead?
+1. Why is the default theme now a light theme, instead of the previously usual dark themes?

1) and +1) We change default settings from time to time, sometimes because it's the preference of a particular developer, but mostly to show users that Other Things are possible. We take care to make it easy to revert to what were previously default settings.

To switch to a horizontal tint2: menu > User Settings > Tint2 > Tint2 Manager
You can choose boron-light.tint2rc or boron-dark.tint2rc (depending on your theme), or any of the other tint2rc's on offer. Uncheck the one(s) you don't want. ("tint2rc" is just a symlink to the current default.)

To switch to a dark theme: menu > User Settings > Appearance for GTK theme and icon theme,
then: menu > User Settings > Openbox > GUI settings for the openbox theme (window frames etc)
If the menu colours don't match: menu > User Settings > jgmenu > Sync theme with Openbox

Some of the default settings changed with the recent update of bunsen-configs: the default theme is now the dark Boron-aqua.

A very convenient way to change all the GUI settings (GTK theme, Openbox, jgmenu etc etc) in one go is BLOB:
menu > User Settings > BLOB Themes Manager
If you want to get your desktop into the default Boron state, choose to apply the "Boron-Aqua" themeset.
You can also save a desktop themeset you have arranged for yourself, for future use with "Save Current Blob".

---
2) It looks to me as if tint2's panel_monitor = all is a leftover from when it was horizontal, where it would make sense. Agreed, with a vertical panel panel_monitor = 1 looks more sensible. I'll check with the other devs and we'll likely upgrade the vertical tint2's. Thanks for the catch!

ghorvath · 2023-12-08 16:07:23

johnraff wrote:

("tint2rc" is just a symlink to the current default.)

johnraff wrote:

Some of the default settings changed with the recent update of bunsen-configs: the default theme is now the dark Boron-aqua.

After a full-upgrade today, I still see this for default tint2rc symlink:

/usr/share/bunsen/skel/.config/tint2/tint2rc -> boron-light-vertical.tint2rc

----

johnraff wrote:

A very convenient way to change all the GUI settings (GTK theme, Openbox, jgmenu etc etc) in one go is BLOB:
menu > User Settings > BLOB Themes Manager
If you want to get your desktop into the default Boron state, choose to apply the "Boron-Aqua" themeset.

Thanks, I never checked this, but indeed it was quick to set it to the current default. However, as said above, tint2 didn't update to the dark theme, that I had to manually set to my liking. I guess default tint2 not pointing to the dark is still a bug?

johnraff wrote:

2) It looks to me as if tint2's panel_monitor = all is a leftover from when it was horizontal, where it would make sense. Agreed, with a vertical panel panel_monitor = 1 looks more sensible. I'll check with the other devs and we'll likely upgrade the vertical tint2's.

Makes sense, thank you!

rbh · 2023-12-08 19:51:55

ghorvath wrote:

johnraff wrote:
("tint2rc" is just a symlink to the current default.)
However, as said above, tint2 didn't update to the dark theme, that I had to manually set to my liking. I guess default tint2 not pointing to the dark is still a bug?

No. Both Debian and Bunsenlabs use symbolic links quite frequently.

If you want to change what tint2 panel to load at start, You can edit the symlink "tint2rc" or in "Tint2 Manager" choose other configfile than "tint2rc" or in ~/.config/bunsen/autostart, disable line " ( sleep 2; bl-tint2-session ) &" and start tint2 in autostart with the line " tint2 -c /path/to/your/config &" or...

Recommended is to use "Tint2 Manager". If you do, "Tint2 Manager", will change configfile ~/.config/tint2/tint2-sessionfile, from default ~/.config/tint2/tint2rc, to your choosen configfile.
But, "Tint2 Manager", wont change the symlink tint2rc. If you start tint2 from the terminal without giving a config-file, it will read tint2rc (or that config-file symlink tint2rc, is pointing to).

Last edited by rbh (2023-12-08 19:53:24)

ghorvath · 2023-12-08 20:50:40

Thanks, I understand how I can change my own settings on tint2. I also understand that by a simple apt full-upgrade my .config settings don't necessarily change.

What I pointed out is that the /usr/share/bunsen/skel/.config/tint2/tint2rc symlinks to the light and not the dark config. That should be overwritten by the apt full-upgrade, because /usr/share/bunsen/skel/ is the default user setting, isn't it? That is, if I understand correctly, any new user creation will by default copy this setting, and will again point to the light config (in tint2).

How I read this is: either the default is still the light (at least for tint2), or this is a bug. Or I am mistaken somewhere. I don't mind either way, but to me the information I received about what is the default contradicts what I experienced after an apt full-upgrade.

rbh · 2023-12-08 22:31:19

ghorvath wrote:

How I read this is: either the default is still the light (at least for tint2), or this is a bug. Or I am mistaken somewhere. I don't mind either way, but to me the information I received about what is the default contradicts what I experienced after an apt full-upgrade.

Ah, Sorry. Yes, Johnraff forgot to update tint2rc last week when updating tint2-sessionfile.
Thanks for catching that.

johnraff · 2023-12-09 01:49:08

ghorvath wrote:

After a full-upgrade today, I still see this for default tint2rc symlink:
/usr/share/bunsen/skel/.config/tint2/tint2rc -> boron-light-vertical.tint2rc

Thanks, you've found a bug.
.config/tint2/tint2rc should now be pointing to boron-dark-vertical.tint2rc
The fix will go out in an upgrade of bunsen-configs soon.

But in fact the 'tint2rc' symlink is not all that important. It's only a fallback in case a tint2 session has not been set.

As @rbh explained:

rbh wrote:

Recommended is to use "Tint2 Manager". If you do, "Tint2 Manager", will change configfile ~/.config/tint2/tint2-sessionfile, from default ~/.config/tint2/tint2rc, to your choosen configfile.
But, "Tint2 Manager", wont change the symlink tint2rc. If you start tint2 from the terminal without giving a config-file, it will read tint2rc (or that config-file symlink tint2rc, is pointing to).

However:

ghorvath wrote:

johnraff wrote:
A very convenient way to change all the GUI settings (GTK theme, Openbox, jgmenu etc etc) in one go is BLOB
...If you want to get your desktop into the default Boron state, choose to apply the "Boron-Aqua" themeset.
...it was quick to set it to the current default. However, as said above, tint2 didn't update to the dark theme, that I had to manually set to my liking. I guess default tint2 not pointing to the dark is still a bug?

This is strange. After restoring "Boron-Aqua", BLOB should have set ~/.config/tint2/tint2-sessionfile to use boron-dark-vertical.tint2rc. The symlink 'tint2rc' is not used. Can you check your tint2-sessionfile? Also, are you using the standard BunsenLabs Boron ~/.config/bunsen/autostart? It should start the tint2 session by calling 'bl-tint2-session'.

rbh · 2023-12-09 12:50:04

ghorvath wrote:

However, maximizing windows is completely broken with the above tint2 setting. Problem is that "panel_monitor = all" sets tint2 to both monitors, and they are vertical due to panel_position. Hence a tint panel will appear in the middle of the 2-monitor Arand SCREEN.

I did not catch this...
I prefer horizontal panel, Maybe I only tested if I could change preferences, on my laptop.
Now I have tested vertical tint2 on my desktop, with dual monitors.
I experienced some errors, Maybe same as you?

The panels starts up ok on left side of monitor one and two.
I have tint2 manager un-maximized on screen1 (left, primary). When maximised, it jumps to screen 2 and left side of the window is under tint2 panel.
I have un-maximized browser window on screen 2. When maximized it jumps to screen 2, full height but about 20 % of screen width.
I have open terminal in screen 1. When maximized, it jumps to screen2. Squeezed in between tint panel and and left screen border. Impossible to read anything in the terminal...

So, with vertical tints on both monitors, window management does not work ok.

I do not think the setting "panel_monitor = all", is some "leftover. On tint's homepage, there is 5 vertical config-files. (https://gitlab.com/o9000/tint2/-/tree/m … type=heads) The first four of them, have the setting "panel_monitor = all". The last, vertical-neutral-icons-2.tint2rc, has setting: "panel_monitor = 1".
When changing settings to "= all" or " = 1, 2", I still only get panel on primary screen.

I think it is awkward not having taskbar / taskbar icons on each screen. With only one monitor, it does not matter... With every extra screen, the awkwardness level increases.

I propose that we change back to horizontal panel until it is fixed, having vertical panel on each screen.

johnraff · 2023-12-10 01:42:36

rbh wrote:

I do not think the setting "panel_monitor = all", is some "leftover".

Maybe my choice of words was poor.

johnraff wrote:

It looks to me as if tint2's panel_monitor = all is a leftover from when it was horizontal, where it would make sense.

I meant that when the vertical tint2 configs were written, the "all" setting was imported from the horizontal settings, without giving thought to the implications for a vertical panel.

It looks clear to me that for a vertical panel to be shown on multiple monitors is going to cause problems. It won't be "fixed" because this is how tint2 behaves, and development has stopped. Maybe a test of eg xfce4-panel would get better results.

Boron will continue to use a vertical tint2 in the default "Boron-Aqua" settings, but what BL can do is make sure that vertical tint2's are not shown on multiple displays, by setting "panel_monitor = 1". Ghorvath has reported that this fixed the problems for him.

Meanwhile, multi-monitor users who want a panel on all displays are recommended to switch to a horizontal tint2. This is extremely easy to do with "Tint2 Manager". Horizontal tint2's will continue to have "panel_monitor = all" set by default.

hhh · 2023-12-10 01:49:41

I've been using dual displays all day with a single vertical panel, both on Boron and on GNOME ("Dock to Panel" extension) and I love it, so it's not a terribly obscure possibility that someone will use dual monitors this way.

Both screens I'm using are the same aspect ratio (16:9 a.k.a. widescreen, which is very common), so it makes sense for me to put the panel on the left as there's so much horizontal space available. Think of it as a smart phone turned to landscape ratio. If they put the status bar down the side of your phone screen, you'd hate it!

If the screens are joined, having a single panel on the primary monitor works perfectly. If the screens are mirrored, the panel appears on both monitors anyways.

So yes, I agree... "1" for vertical and "all" for horizontal.

#41 2023-10-17 09:29:36

Re: Boron Beta 2 isos available, amd64 and i386

#42 2023-10-18 02:47:30

Re: Boron Beta 2 isos available, amd64 and i386

#43 2023-10-21 19:16:33

Re: Boron Beta 2 isos available, amd64 and i386

#44 2023-10-21 20:14:48

Re: Boron Beta 2 isos available, amd64 and i386

#45 2023-10-22 01:06:22

Re: Boron Beta 2 isos available, amd64 and i386

#46 2023-10-23 04:51:32

Re: Boron Beta 2 isos available, amd64 and i386

#47 2023-10-26 06:38:28

Re: Boron Beta 2 isos available, amd64 and i386

#48 2023-10-26 07:19:00

Re: Boron Beta 2 isos available, amd64 and i386

#49 2023-10-26 07:46:17

Re: Boron Beta 2 isos available, amd64 and i386

#50 2023-12-07 18:58:15

Re: Boron Beta 2 isos available, amd64 and i386

#51 2023-12-07 19:16:00

Re: Boron Beta 2 isos available, amd64 and i386

#52 2023-12-08 05:48:48

Re: Boron Beta 2 isos available, amd64 and i386

#53 2023-12-08 16:07:23

Re: Boron Beta 2 isos available, amd64 and i386

#54 2023-12-08 19:51:55

Re: Boron Beta 2 isos available, amd64 and i386

#55 2023-12-08 20:50:40

Re: Boron Beta 2 isos available, amd64 and i386

#56 2023-12-08 22:31:19

Re: Boron Beta 2 isos available, amd64 and i386

#57 2023-12-09 01:49:08

Re: Boron Beta 2 isos available, amd64 and i386

#58 2023-12-09 12:50:04

Re: Boron Beta 2 isos available, amd64 and i386

#59 2023-12-10 01:42:36

Re: Boron Beta 2 isos available, amd64 and i386

#60 2023-12-10 01:49:41

Re: Boron Beta 2 isos available, amd64 and i386

Board footer