Experimental BunsenLabs Lithium

Bearded_Blunder · 2019-02-15 18:15:54

Just wondering, rather than editing /etc/network/interfaces mightn't a better approach be tweaking /etc/NetworkManager/NetworkManager.conf

man NetworkManager.conf(5) wrote:

IFUPDOWN SECTION
This section contains ifupdown-specific options and thus only has effect
when using the ifupdown plugin.
managed
If set to true, then interfaces listed in /etc/network/interfaces are
managed by NetworkManager. If set to false, then any interface listed
in /etc/network/interfaces will be ignored by NetworkManager. Remember
that NetworkManager controls the default route, so because the
interface is ignored, NetworkManager may assign the default route to
some other interface.
The default value is false.

The default .conf it installs looks like:

[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

changing it to

managed=true

It certainly seems to do the trick here, & should anyone wish to subsequently purge network-manager later because they're on a wired connection & really don't need it, nothing breaks like it does if you'd edited /etc/network/interfaces & forgotten you did.

The Debian wiki also seems to indicate this would be a valid approach.

pet peeve with netinstall wrote:

Would also be kinder in the netinstall script than clobbering the existing interfaces file, which puts anyone who commented network-manager out of packages-norecs offline. Could test for /etc/NetworkManager/NetworkManager.conf existing & sed if so. Or even use your fancy new ini parser @johnraff ;-)

hhh · 2019-02-15 18:55:11

^ Nice suggestion! @johnraff?

Bearded_Blunder · 2019-02-15 21:43:19

Just noticed with the Lithium install browsing the Windows network doesn't work, on Helium that works OOTB you *can* still access shared resources, but you have to do the Thunar > Go > Open Location thing & then enter the ip or fqdn.

I've spent some effort with search engines researching possible causes, installing && removing various things, I've not found a proper cure yet, so if you do, I'd also appreciate knowing exactly what said cure is :-)

Last edited by Bearded_Blunder (2019-02-16 03:13:42)

johnraff · 2019-02-16 07:10:21

Bearded_Blunder wrote:

Just wondering, rather than editing /etc/network/interfaces mightn't a better approach be tweaking /etc/NetworkManager/NetworkManager.conf

Good idea!

According to 'man NetworkManager.conf' there are a couple of available directories to drop config snippets in, and so avoid overwrites by package upgrades:
/etc/NetworkManager/conf.d/
/usr/lib/NetworkManager/conf.d/
It will need some testing to make sure /etc/NetworkManager/NetworkManager.conf doesn't override them, though. If a snippet works, then it can be installed by bunsen-configs, and the netinstall script simplified a bit more.

---
There is a long-standing irritation with the Debian netinstall isos, that even though (with the "firmware" versions anyway) it's possible to do the install over a wireless connection, at the end of the install process all the wireless info is removed from /etc/network/interfaces. If you chose not to install any DE then your barebones CLI-only install will have no internet, and you have to write something in /e/n/i by hand to get it working. There are security arguments why this should be so, and they don't plan to change it AFAICS.

I hit this again just yesterday. It's possible to work around it by copying the functioning /e/n/i somewhere in the target system before exiting the installer, then copying it into place after reboot, but I always forget till it's too late.

I should do it all over again once more, just so I can document the fix properly for posterity, but it's quite a PITA.

Bearded_Blunder · 2019-02-19 10:59:20

earlier wrote:

Just noticed with the Lithium install browsing the Windows network doesn't work, on Helium that works OOTB you *can* still access shared resources, but you have to do the Thunar > Go > Open Location thing & then enter the ip or fqdn.

Seems this is tied to gvfs-backends which uses libsmbclient to get the info but since SMB1 is now deprecated doesn't have a mechanism to call the browse data as it's SMB1 only functionality.

Most of my info comes from the discussion in this Fedora bug which concludes:

While it is annoying, you can work around it by using avahi/bonjour/mDNS in addition to SMB browsing. Linux and Mac machines will pick it up.
Or just wait, until smbc_setOptionProtocols gets into Samba release (it is not yet in 4.9.2).

There's more in that discussion than what I've pulled out here.

It's not just Bunsen, I see the same non-functioning browse network icons in all the other Debian Buster DEs I've tried. Which seems to imply that's either not in or not being used by gvfs-backends with 4.9.4 (current Buster) either.

Think we may just have to live with it being as it is through the Buster release cycle unless someone figures out that avahi/bonjour/mDNS workaround, it's currently eluding me.

johnraff · 2019-02-20 02:41:37

Bearded_Blunder wrote:

unless someone figures out that avahi/bonjour/mDNS workaround, it's currently eluding me.

Isn't installing and using avahi-daemon enough?

Bearded_Blunder · 2019-02-20 10:50:54

johnraff wrote:

Isn't installing and using avahi-daemon enough?

EDIT:
Nope: To add to that an individual *might* make it work for an individual machine if they have iTunes installed & set iTunes to advertise shares using bonjour. Windows, however has no native means of advertising the shares in a manner that would enable avahi finding them.

What is needed is something that uses the WS-DISCOVERY protocol which Windows does use.

Personally, and absent a secure fix, I'd rather see the icon itself go away as it has in PCManFM than just left, because the internet is full of bad advice about turning on reinstalling & using SMBv1 to "get it working again".

original reply wrote:

Possibly for the majority case, does Thunar use it even if it's there? How would one make it do so if not? I'll need to set up a whole separate network to test that, avahi doesn't play nice with .local domains and my network was set up way back when kb296250 from Microsoft was current (actually when it was still Q296250 & referred to NT4 rather than SBS) . Microsoft now seem to be doing their dead level best to hide the fact they ever advised using .local even though they did for many years hey-ho.
That said the usual tweaks for avahi on a .local domain aren't cutting it here, they do on stretch so I'm wondering. I'm used to having to tweak whenever avahi gets on. Exactly why Poetttering couldn't have defaulted avahi to .avahi & not interfered with the widely deployed already .local defeats me also, but no, just force reconfiguring of already deployed networks for his avahi offering The guy seems to have zero concept of backwards compatibility.
I'm not wanting to turn this into help & support for my weird case, it's more about flagging that network browsing from Thunar is no longer operative OOTB for the far more common mixed Windows/SMB-shares+Linux environment with the default WORKGROUP which'll be somewhat awkward for me to test
Perhaps someone with a default Windows network can enlighten us if simply adding avahi-daemon is enough?

Last edited by Bearded_Blunder (2019-02-21 15:12:08)

Bearded_Blunder · 2019-02-23 05:57:01

Incidentally, latest apt upgrade updated catfish, and for me at least it now launches from the menu.

iMBeCil · 2019-03-18 17:07:33

Installing Lithium via Helium.

Instead of a bit more difficult route as explained in the Experimental BunsenLabs Lithium repository has been set up (by johnraff), at this particular moment, it is possible to install Lithium on fresh Helium install (at least).

What is it good for? Well, network installation is straightforward, all hardware supported - along with various quirks - is supported OOTB, and most importantly: one doesn't have to type manually all the stuff in johnraff's post (linked above)!

Steps, tested on real hardware:
1) Install BunsenLabs Helium.
2) After first reboot, start GUI. Do not start bl-welcome; instead, when prompted, press 'q' (quit). Open terminal, and execute

$ sudo apt update
$ sudo apt upgrade   # or:    sudo apt dist-upgrade

Do not reboot.
3) Still in GUI, open in terminal or in any editor:
- in '/etc/apt/sources.list' change all 'stretch' to 'buster'
- in '/etc/apt/sources.list.d/bunsen.list', change existing single line to

deb https://kelaino.bunsenlabs.org/~johnraff/debian lithium main

- execute

$ wget https://kelaino.bunsenlabs.org/~johnraff/lithium-dev.asc
$ sudo cp helium-dev.asc /etc/apt/trusted.gpg.d/

4) Reboot, and in grub select Bunsen on TTY, i.e. do not boot GUI! Log in, and then execute:

$ sudo apt update
$ sudo apt dist-upgrade

It takes some time to finish this. When finished, reboot, for example executing 'reboot'. Reboot into GUI.
6) If something is odd, reboot once again, into GUI.
5) ??????
6) Profit! Voila, you have Lithium.
7) Open terminal and execute:

$ bl-welcome

and do a postinstallation according to taste. Here, I didn't test everything, but some stuff probably doesn't work for one reason or another (for example, there is no bunsenlabs-extra-images package in Lithium).

Warning: I haven't thoroughly tested this way of installing Lithium; however, I can confirm that on my installation I was able to install Oracle Java 11, Eclipse 2018, and everything worked as expected.

Please, be gentle ... O:)

EDIT1: as of today (March 2020), I can confirm that the installation above works (with few easily solvable quirks [tint2? conky?]). And it owrks for both adm64 and i386.

PS: the described installation of the Lithium worked on my another (older) Helium install (in VBox), with various packages installed, and with bl-welcome executed during Helium install. This might be the sign that above procedure may be used, by experienced person, to update from existing Helium to Lithium.

Last edited by iMBeCil (2020-03-09 14:46:37)

hhh · 2019-03-18 19:30:08

I'll gladly test this when I have an hour. Thanks!

iMBeCil · 2019-03-18 20:44:54

^You're welcome.

As I point out, there is basically nothing special about this, except that it saves a bit of manual typing, and it (greatly) benefits from already recognized hardware in Helium. (Although, updating packages from Helium to Lithium screwed video driver a bit (Intel GFX) - new one introduced an old bug, resolved by adding 'video=SVIDEO-1:d' to grub ... but that's not Bunsen problem.)

bigbenaugust · 2019-04-23 13:15:14

I know Buster is still a bit of a moving target, but this is what I am getting this morning:

# apt-get install --no-install-recommends bunsen-meta-all 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 bunsen-meta-all : Depends: intel-microcode but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

Installing intel-microcode complains that iucode-tool is uninstallable.

This is in VirtualBox if that matters.

hhh · 2019-04-23 19:06:52

What ISO are you using for the base-install, before pulling the Bunsen packages? Does it have the contrib and non-free repositories enabled? intel-microcode is non-free...

https://packages.debian.org/buster/intel-microcode

bigbenaugust · 2019-04-24 18:59:45

hhh wrote:

What ISO are you using for the base-install, before pulling the Bunsen packages? Does it have the contrib and non-free repositories enabled? intel-microcode is non-free...
https://packages.debian.org/buster/intel-microcode

I checked that... and don't I feel like a bonehead.
I had main and non-free, but not contrib.

Sorry about that.

hhh · 2019-04-24 19:07:53

... and iucode-tool is in contrib. No worries, glad to help sort out.

bigbenaugust · 2019-04-24 20:22:54

Other than that bunsen-meta-java didn't install, looks and works great so far.
(I might be the only guy who uses it, but I use BL at work, soo... )

hhh · 2019-04-25 04:31:54

i just checked, the meta package is trying to pull openjdk-8-jre but that's dropped in buster, the version there is openjdk-11. Install it yourself. Full install (Development Kit and Runtime]...

sudo apt install openjdk-11-jdk

... or just the Runtime...

sudo apt install openjdk-11-jre

There is no icedtea-*-plugin package available in buster.

bigbenaugust · 2019-04-25 13:07:46

I figured I would go ahead and install the JDK when I got to that point. Just noting the issue from the welcome script.

johnraff · 2019-04-26 08:16:52

Added update of bunsen-meta-java deps to my TODO list. Thanks.

dhalgren · 2019-05-16 12:20:45

I installed Buster RC1 using ethernet, then created wifi network with network manager after installing BL from the John Raff's repository.

The only problem I have had, apart from it all being very slow, is that the network manager was not managing the ethernet device, so I had to set it to managed in /etc/NetworkManager/NetworkManager.conf But this is not a BL bug, I suspect. (I don't know enough to know, so letting you know just in case.)

Otherwise, everything going fine.

#41 2019-02-15 18:15:54

Re: Experimental BunsenLabs Lithium

#42 2019-02-15 18:55:11

Re: Experimental BunsenLabs Lithium

#43 2019-02-15 21:43:19

Re: Experimental BunsenLabs Lithium

#44 2019-02-16 07:10:21

Re: Experimental BunsenLabs Lithium

#45 2019-02-19 10:59:20

Re: Experimental BunsenLabs Lithium

#46 2019-02-20 02:41:37

Re: Experimental BunsenLabs Lithium

#47 2019-02-20 10:50:54

Re: Experimental BunsenLabs Lithium

#48 2019-02-23 05:57:01

Re: Experimental BunsenLabs Lithium

#49 2019-03-18 17:07:33

Re: Experimental BunsenLabs Lithium

#50 2019-03-18 19:30:08

Re: Experimental BunsenLabs Lithium

#51 2019-03-18 20:44:54

Re: Experimental BunsenLabs Lithium

#52 2019-04-23 13:15:14

Re: Experimental BunsenLabs Lithium

#53 2019-04-23 19:06:52

Re: Experimental BunsenLabs Lithium

#54 2019-04-24 18:59:45

Re: Experimental BunsenLabs Lithium

#55 2019-04-24 19:07:53

Re: Experimental BunsenLabs Lithium

#56 2019-04-24 20:22:54

Re: Experimental BunsenLabs Lithium

#57 2019-04-25 04:31:54

Re: Experimental BunsenLabs Lithium

#58 2019-04-25 13:07:46

Re: Experimental BunsenLabs Lithium

#59 2019-04-26 08:16:52

Re: Experimental BunsenLabs Lithium

#60 2019-05-16 12:20:45

Re: Experimental BunsenLabs Lithium

Board footer