Beryllium software replacements/additions

damo · 2021-10-31 09:16:00

It's a fair point having a bunch of useful applications on a live disc, but BL as a live "rescue" disc? There are others available which are specifically for that.

So let power users set up persistence, and use apt/apt-get for their favourites.

rbh · 2021-10-31 16:14:34

damo wrote:

but BL as a live "rescue" disc?

It has been said so for a couple of years ago.

hhh · 2021-11-01 02:51:29

It's definitely a rescue disc. It has almost all the non-free firmware pre-installed. Even without that, it's a USB bootable OS.

-edit- BL Live has saved my butt more than once.

Last edited by hhh (2021-11-01 02:52:40)

johnraff · 2021-11-20 09:27:56

Time passes, let's try and wrap this up. If anyone's unhappy with this attempt to compromise, please post!

Packages to add, small or uncontroversial:
colordiff
dmidecode
mdadm
xfce4-appfinder
alsa-ucm-conf

EDIT neither of these is installed OOTB, just offered in menu:

simplescreenrecorder (replacing gtk-recordmydesktop)

firmware-sof-signed
This installs to 10MB, so possibly omit from CD iso, hope isenkram picks it up?

Now, hw-probe: if you use '-all' it's very thorough and detailed, but unless you upload to the database then the information is very hard to navigate. The upload is supposed to be privacy-protected though. It also brings in quite a lot of dependencies. We already have inxi and hardinfo (although the latter crashes on Bullseye if using the BL-Lithium GTK theme). I suggest making hw-probe an optional install, using bl-welcome so we can show a bit of information first.

galculator: drop it, leave users with xcalc, but add gnome-calculator to a "Utilities" sub-menu of the Install Favourite Packages menu with:
gnome-calculator
mc (which didn't get many yes votes, but users will be able to find it easily here)

Last edited by johnraff (2021-11-23 05:30:17)

hhh · 2021-11-20 11:45:13

If you want to add xfce4-appfinder, I recommend that our menu command uses the '--disable-server' switch so the finder closes without leaving a daemon behind. If you mean xfce4-appfinder is in there now and we should remove it, do it. It's still just an apt install away.

Last edited by hhh (2021-11-20 11:50:37)

rbh · 2021-11-20 15:20:02

johnraff wrote:

mdadm

I wanted mdadm in the live session. Not in standard installation. If you install BL to an raid array, mdadm will be added as it is needed. In an standard installation it is not needed.

Now, hw-probe: if you use '-all' it's very thorough and detailed, but unless you upload to the database then the information is very hard to navigate.

Just textfiles... Not so hard to examine. But, uploading the information increases the communities knowledge about hw compatibility with linux.

The upload is supposed to be privacy-protected though.

Default, all unique info like mac-adress etc, is filtered, like inxi can do if told to do.

It also brings in quite a lot of dependencies.

Most of them is installed althoug, like dmidecoe, lmsensors etc.

I suggest making hw-probe an optional install, using bl-welcome so we can show a bit of information first.

Would have prefered it to be installed, but its ok to have in welcome-skript.

Last edited by rbh (2021-11-20 15:21:37)

rbh · 2021-11-20 16:52:14

Oh, I forgot.
Hw-probe should be available in live session. Else, people who need to run it from live session, has to download other iso than BL...

johnraff · 2021-11-21 01:13:00

@rbh, basically the package list for the live system is the same as the installed system, on the basis of What You See Is What You Get. Another reason is the way the installer is organized: the squashed file system in the iso is expanded and copied over as-is to the new location, with only a few tweaks (like apt) which are mostly handled by Debian-Installer.

Even so, there is a short list of live-only packages (eg live-tools) that get removed at the end of the install process. I don't think that list should be long, but we could in principle add mdadm if there's no use for it in a normal session. That would mean it's in the squashfs file but gets explicitly removed at the end of installation. Looking at your helpful instructions here, though, 'sudo apt install mdadm' would be rather small saving in user effort. We could just put a link to your guide somewhere easy to find?

In fact, having just done some more reading about RAID and mdadm (eg Arch Wiki, also searching 'mdadm' on these forums) I'm starting to think the whole thing is a bit dangerous and should be left for advanced users, who can easily make sure they have mdadm without our help.

BTW there is currently a critical bug for mdadm in a chroot: https://bugs.debian.org/cgi-bin/bugrepo … bug=982459

So, I'm coming round to: drop the idea of shipping mdadm by default.

If hw-probe was installed via bl-welcome then that option wouldn't appear until after install. While apt-get in a terminal is always available, maybe a more accessible place would be to put hw-probe in the "install" > "Utilities" menu, along with mc and gnome-calculator? As long as a net connection was available that would work.

I think making a live iso that holds everything a user might possibly want without a network connection might be project-drift for BL.

johnraff · 2021-11-21 11:45:23

hhh wrote:

If you want to add xfce4-appfinder, I recommend that our menu command uses the '--disable-server' switch so the finder closes without leaving a daemon behind.

That's what I meant, and thanks that's a good idea for the command. That's a nice simple way of doing it. I had been thinking of, instead, shipping another of those xfconf xml files with the "do not run as daemon" option set. If people launch xfce4-appfinder from the "applications" menu they'll get whatever's set in the .desktop file so that might mean shipping a tweaked one in ~/.local/share/applications to enforce '--disable-server'. Hmm... maybe the xfconf file would be simpler after all?

But either way, to help new users, maybe xfce4-appfinder should have a hard-coded spot in the menu anyway? Perhaps even right in the top section just after Media Player? Alternatively, in the Utilities sub-menu?

rbh · 2021-11-21 21:27:26

johnraff wrote:

though, 'sudo apt install mdadm' would be rather small saving in user effort. We could just put a link to your guide somewhere easy to find?

It seems we don't talk same language...?
Once again; when installing BL or debian or... on an raid array, mdadm will automaticley be installed.

If you need to boot live iso and fix errors on a raided system, it is good to have mdadm automatically loaded.
It is not so simple task to installand run it in the live system...

Finix, grml and SystemRescueCD, is some popular live/rescue CD's that includesmdadm.

In fact, having just done some more reading about RAID and mdadm (eg Arch Wiki, also searching 'mdadm' on these forums) I'm starting to think the whole thing is a bit dangerous and should be left for advanced users, who can easily make sure they have mdadm without our help.

BL live session is of no use for system installed on raid. But, raid is not more dangerous than lvm or encrypted disk/partition/filesystem. And if the system do not have any raid system, the only loss is somemb disk space and som seconds delayed boot.

BTW there is currently a critical bug for mdadm in a chroot: https://bugs.debian.org/cgi-bin/bugrepo … bug=982459

If you want to reinstall grubb in chroot, you also have to mount virtual filesystem from the host. That is why I posted the Chroot help-script last year.

So, I'm coming round to: drop the idea of shipping mdadm by default.

A pity if you do.

hw-probe

I think it is handy to run from live session, for those who have hardware problem and not ableto pin down the problem..

I think making a live iso that holds everything a user might possibly want without a network connection might be project-drift for BL.

I would not mind swappingout Libre Office and instead install forensics-full. But, I will not argue for it.
I have argued for mdadm in the live session and and hw-probe both in live-session and default install.

Last edited by rbh (2021-11-21 21:29:34)

hhh · 2021-11-21 22:29:35

johnraff wrote:

But either way, to help new users, maybe xfce4-appfinder should have a hard-coded spot in the menu anyway? Perhaps even right in the top section just after Media Player? Alternatively, in the Utilities sub-menu?

Either sounds good. gmrun and dmrun are great but xfce4-appfinder has it's advantages. BTW, the command I use is...

xfce4-appfinder --disable-server --collapsed

This produces a simple run dialog that closes cleanly.

We'll need a keyboard shortcut, maybe Super+S for Search, I don't think that shortcut is used yet.

Last edited by hhh (2021-11-21 22:31:43)

hhh · 2021-11-21 22:37:21

BTW, I haven't tested this on BL OB yet, but it works perfectly in Xfce. It's a RAM fix for conky so that conky shows the same RAM as lxtask, htop, neofetch, etc... instead of a (wrong) higher RAM...

${exec free -h --si | awk 'NR==2{printf $3}'} / ${memmax}

Source...

https://forums.bunsenlabs.org/profile.php?id=666

johnraff · 2021-11-22 00:26:00

hhh wrote:

BTW, I haven't tested this on BL OB yet, but it works perfectly in Xfce. It's a RAM fix for conky so that conky shows the same RAM as lxtask, htop, neofetch, etc... instead of a (wrong) higher RAM...
${exec free -h --si | awk 'NR==2{printf $3}'} / ${memmax}
Source...
https://forums.bunsenlabs.org/profile.php?id=666

That's on my todo list. Maybe tweak the awk condition thus:

${exec free -h --si | awk '/^Mem:/{printf $3}'} / ${memmax}

Just because it feels a bit more solid to look for the line starting with Mem: than just count to the second line. Probably meaningless in practice though...

johnraff · 2021-11-22 02:57:07

rbh wrote:

It seems we don't talk same language...?

rbh, there does seem to be a communication problem here. Let's take it slowly and carefully, and assume good will on both sides! I am trying to allow for the fact that you're using a language which isn't native to you, but I don't always get it right. For example, earlier you wrote:

rbh wrote:

If you install BL to an raid array, mdadm will be added as it is needed.

I wasn't sure what you meant, but guessed that by "will be added" you might have meant "should be added" (by the user).
But now, this:

Once again; when installing BL or debian or... on an raid array, mdadm will automaticley be installed.

suggests you meant that Debian Installer will automatically install mdadm if it detects a RAID array. Is that correct? I have no experience at all of using RAID.

If you need to boot live iso and fix errors on a raided system, it is good to have mdadm automatically loaded.
It is not so simple task to installand run it in the live system...

Are you saying that the live system will not boot on a raid system if mdadm is not already installed? If you're not saying that, why is it not simple to install mdadm with apt? In your earlier guide here you say:

In BL Live session.
Install mdadm
Run "lsblk -f", to list all partitions with filesystem type.
All raid device members will be marked "linux_raid_member"
...etc

with no hint that "install mdadm" will not be easy on the live system.

Finix, grml and SystemRescueCD, is some popular live/rescue CD's that includesmdadm.

To repeat, I don't think it's fair to compare BL with the likes of finnix, grml or SystemRescue. Yes, BL can be used for rescue sometimes but for difficult cases I think it's quite reasonable for users to boot up a specialized rescue iso.

BL live session is of no use for system installed on raid.

Same question - why? Does a live system fail to boot on a computer with a raid array? Don't live systems boot to RAM, making the hard disk setup irrelevant? Why can't mdadm be installed after booting the live system, as you yourself suggested in your earlier post?

But, raid is not more dangerous than lvm or encrypted disk/partition/filesystem.

You're quite likely correct here. I use LVM and LUKS with no problems (so far), and haven't noticed a lot of help web posts from people with serious lvm issues. I have no experience of RAID but do see many warnings about potential destruction of data so got the impression it was only for experts.

So the big question: why is it difficult to install mdadm on a booted live session? If there's a big advantage in having it pre-installed, let's consider it.

I would not mind swappingout Libre Office and instead install forensics-full.

So here's the earlier point again. You seem to be arguing that BL's role should be shifted more towards rescue/forensics. LibreOffice Writer (not the full LO suite) is shipped by default because people are often sent Microsoft Office documents, especially .docx, which they will be able to open with LO Writer. OK we've put that goal higher than the rescue software. Of course many of the rescue utilities are very small and can be easily added to the iso - as many have been already - but if it was a question of swapping out LO then that would raise big questions of what BL is actually for...

---
Technical note:
The BL live system and installed system are basically the same thing. We don't have two separate package lists. While running live-build to generate the iso the system is put together and compressed into a squashfs file. That file is expanded when running the live session, and the same squashfs file is expanded and copied onto the computer's drive by Debian-Installer. D-I does have a system of hooks which allows packages on a small "live" list to be uninstalled by apt, right at the end of the install. We currently use that mechanism to uninstall bunsen-configs-live which makes a couple of small changes to the live menu, and in theory if mdadm was in the regular package list it could be uninstalled at that point. BUT that leaves the problem of computers with RAID, where D-I has specifically installed mdadm at an earlier stage of the install (if it's correct that that's what happens). Mdadm would be uninstalled for them too!

So, because there aren't two separate package lists (that's how live-build works) it might in fact be quite difficult to install mdadm only in the live session, while allowing it to remain in the installed system when it's actually needed.

(If the user can install mdadm during the live session, this would avoid the problem though.)

This is why there are dedicated live-only rescue isos, where installation is not an issue.

Last edited by johnraff (2021-11-23 01:59:46)

johnraff · 2021-11-22 04:24:18

hhh wrote:

johnraff wrote:
...to help new users, maybe xfce4-appfinder should have a hard-coded spot in the menu anyway? Perhaps even right in the top section just after Media Player? Alternatively, in the Utilities sub-menu?
Either sounds good.

Now I think about it, if appfinder is too prominently at the top of the menu we'll have the same problem we have with the "Applications" menu: new users will dive in there for the preferences apps instead of using our crafted "Preferences" menu. Let's put xfce4-appfinder in the "Utilities" submenu. It's not something you use all the time, just when you need easy access to the .desktop file.

hhh · 2021-11-22 20:34:07

Good!

hhh · 2021-11-22 20:41:28

johnraff wrote:

That's on my todo list. Maybe tweak the awk condition thus:
${exec free -h --si | awk '/^Mem:/{printf $3}'} / ${memmax}
Just because it feels a bit more solid to look for the line starting with Mem: than just count to the second line. Probably meaningless in practice though...

Sorry, this discussion should probably be in the "Tweak the BL Menu" thread, but since it's here...

RAM:$alignr${exec free -h --si | awk '/^Mem:/{printf $3}'} / ${memmax}

I just tried this in a real BL BE session (not VB) with mousepad open and conky RAM went from the 560s to 318, now matching what lxtask reports. Yes please, this should go in the config, we don't need our default conky showing heavier RAM that what is being used.

With at-spi2-core and clipit removed, my desktop idle RAM on an AMD64 install is currently 306, and always under 340. This is the way.

Last edited by hhh (2021-11-22 20:47:16)

johnraff · 2021-12-17 08:06:19

@rbh I've added mdadm to the "Install Favourite Packages" submenu where it will be available to users of the live system.
(The welcome script only runs after installation so it would be too late there.)

There's no easy way to add mdadm out-of-the-box to the live system only but not in the installed system.

rbh · 2022-02-18 00:07:36

johnraff wrote:

But now, this:
Once again; when installing BL or debian or... on an raid array, mdadm will automaticley be installed.
suggests you meant that Debian Installer will automatically install mdadm if it detects a RAID array.

I see I never continued this...
You can create raid in Debian installer advanced, and mdadm has to be installed to handle the raid. Or as you propose, you can install to an allready created raid and mdadm will be installed.

Are you saying that the live system will not boot on a raid system if mdadm is not already installed?

No, but you can not mount the raidpartitions.

If you're not saying that, why is it not simple to install mdadm with apt?

Install small nessesary tools to manage the system from live iso....?

To repeat, I don't think it's fair to compare BL with the likes of finnix, grml or SystemRescue. Yes, BL can be used for rescue sometimes but for difficult cases I think it's quite reasonable for users to boot up a specialized rescue iso.

The latest unofficial non-free firmware Debian live iso, has mdadm installed and auto assemble all recognized raids.

I would not mind swappingout Libre Office and instead install forensics-full.
So here's the earlier point again. You seem to be arguing that BL's role should be shifted more towards rescue/forensics.

Nope, I have not argued for it, but would not mind if it was done...

But, till next version, on a rainy sunday, test install an vm with raided disks...

rbh · 2022-02-19 08:49:58

Oh, I forgot to point out that mdadm does no harm if installed just, like btrfs-progs doesn't harm to be installed if chosen file-system is ext4.

#21 2021-10-31 09:16:00

Re: Beryllium software replacements/additions

#22 2021-10-31 16:14:34

Re: Beryllium software replacements/additions

#23 2021-11-01 02:51:29

Re: Beryllium software replacements/additions

#24 2021-11-20 09:27:56

Re: Beryllium software replacements/additions

#25 2021-11-20 11:45:13

Re: Beryllium software replacements/additions

#26 2021-11-20 15:20:02

Re: Beryllium software replacements/additions

#27 2021-11-20 16:52:14

Re: Beryllium software replacements/additions

#28 2021-11-21 01:13:00

Re: Beryllium software replacements/additions

#29 2021-11-21 11:45:23

Re: Beryllium software replacements/additions

#30 2021-11-21 21:27:26

Re: Beryllium software replacements/additions

#31 2021-11-21 22:29:35

Re: Beryllium software replacements/additions

#32 2021-11-21 22:37:21

Re: Beryllium software replacements/additions

#33 2021-11-22 00:26:00

Re: Beryllium software replacements/additions

#34 2021-11-22 02:57:07

Re: Beryllium software replacements/additions

#35 2021-11-22 04:24:18

Re: Beryllium software replacements/additions

#36 2021-11-22 20:34:07

Re: Beryllium software replacements/additions

#37 2021-11-22 20:41:28

Re: Beryllium software replacements/additions

#38 2021-12-17 08:06:19

Re: Beryllium software replacements/additions

#39 2022-02-18 00:07:36

Re: Beryllium software replacements/additions

#40 2022-02-19 08:49:58

Re: Beryllium software replacements/additions

Board footer