Open Linux Forums
Like Ubuntu forums, except with beer.
361 posts
Oct 04 2017
21 June 2018 - 19:51

I need to get a usb wifi adapter for the County Weed Coordinators office.

The county has had a wired connection system all along but it has fallen into a crack. Seems no one knows anything about it at all. Doesn't fall under the ISP because it is all in the building and, of course, they didn't pay to have them service it. So now they are forced to use wifi only.

This is fine if you want to use Win all the time because all the damned things work with Win. The computer there is a dual boot and this worked fine for a while because the wired connection worked. Doesn't now and will not be fixed so the Linux install has no connection.

Has a Netgear usb adapter that uses a Broadcom chip that is not supported (bc43231 - don't recall what the actually is).

There seem to be plenty of adapters available that support Linux. What I don't know is if they support Linux without installing some crap proprietary driver that will not continue to be maintained. So I thought I would ask for some advice here.

Hopefully someone has more knowledge than I do. Pretty likely because I am still pretty much totally ignorant of wifi usage.

24 May 2018 - 20:18

I use chroot a lot to do my update/upgrade chores with numerous installs. I like to have the stuff dismounted when done so use umount to do this.

Normal usage by me is

# umount -AR /mnt/some & umount -AR /mnt/thing

using as many &'s as needed. The above is what is in use on this external drive that I am currently using for my main usage.

This works very well most of the time. I had some problems on the internal drives dismounting Mageia 5 but that was fixed by running

# fuser -c /mnt/Mageia5

before using umount.

But I also had some difficulties with pretty standard Debian installs, particularly Stable installs, sometimes. These were generally completely corrected by dismounting more than one install at a time rather than doing theme one at a time. Sometimes only one gets dismounted but just hitting the up arrow and doing the same command again will clear the bugger.

The other day I installed Devuan ascii (RC) and I am experiencing this problem with it. I just can't dismount the bugger at all if I just call for a umount of it by itself but have no problem doing so if umount calls for both installs.

I can even try umount on ascii and have it fail, try the fuser command and then try umount on it again and fail - but then use umount to dismount Xfce (sid based) which is never a problem and then run umount for ascii again and it will dismount with no complaints.

On this drive I am doing this almost always from Debian testing based install 'OB64' which is my default OS in the boot menu. Today I did umount for both

root@openbox:/home/tom# umount -AR /mnt/Xfce & umount -AR /mnt/Devuan

and both dismounted fine. But for the first time there was an added line in the output instead of simply a new # prompt

root@openbox:/home/tom# umount -AR /mnt/Xfce & umount -AR /mnt/Devuan
[1] 20429

WTF is that supposed to mean? Looked in 'man umount' but there are no error codes listed. Looked in 'man mount' where there are error codes listed but none that are applicable to that output. Running the '[1] 20429' through a search engine in a number of different ways got me nothing at all to explain that output. Used, for instance, 'umount', 'debian' and 'debian umount' before the output to see if it turned up something along with some others that I can't remember but got nothing useful at all. This is pretty strange to me because running about any weird output messages turns them up in a search engine.

I did find this which may be useful in the future

If you suspect you have something left running in a chroot, sudo ls -l /proc/*/root | grep chroot will find the culprit (replace "chroot" with the path to the chroot).

but everything was dismounted when the strange output appeared.

Obviously not a real critical problem - just would like to know what that output means.

As I generally reboot into one or both other installs and run on them for a while to make sure everything is running as expected even a total failure to dismount is not an earth shaking problem.

29 October 2017 - 20:56

Hope this is the right place for this.

If I pull up the main page for the forum and then go to log in it always fails. Get a message that the captcha stuff isn't working. Always.

If I simply go to any of the forum sections and login on the identical page that comes up hitting those "Login" buttons there is no problem.

As this has worked well three times I checked the remember me button so as long as I keep my browser open it should be fine. But my cookies are wiped when I drop the browser window used for any site so I do need to actually log in each time. Thought I would try the button just see if it will work for me.

Not sure it will simply because of the way my system is set up. Thought it would be fun though.

But figured you may want to know about the login issue.

23 December 2017 - 20:04

But it is what happens when you run off all your real hardware, bare metal install testers. That is damned dead common hardware being effected. No excuse for that not to have been caught in testing.

17 February 2018 - 05:37

You may not have been following this but this has been going on for a few years now.

In case you get into a bit of trouble working on your JD or know someone that is you might want to point them at these articles.

This is pretty good from folks that really don't understand the economics of agriculture. People in ag have been keeping up with tech pretty well. There really isn't much choice.

There is a mention of a GPS unit in that video. These are used primarily for soil nutrient applications. We used to do several soil samples in a field and then mix them all together, you need about a 5 gallon bucket of samples to mix and then you take a pound or so to get tested. Then you get the recommendation for that field and the intended crop. This is still a good idea but if you check you will find that orbital spectrometry is capable of very, very accurate soil analysis. Physical soil tests are primarily used, on large cropping outfits, to check on the remote soil analysis. By using the maps that are created of your field and feeding that data into your tractor you connect to the equipment to apply the soil amendments and they are then applied at the rates needed for the part of the field you are actually applying the stuff too.

This cuts down on runoff for better water quality protection and saves a lot of money by not over using the stuff that cost a lot of money.

GPS in tractors is not a new thing at all. Been around more than a decade in fairly common use. All new tractors, pretty much since the turn of the century, come with a place to set a laptop in the cab where you can reach it from the seat and use it.

Is the primary reason I am not holding my breath for self driving road vehicles in any large number. Or capable of actually getting somewhere correctly. They have been doing real work on this for a long time in tractors. You really have all the controls for equipment set up to run pretty well unattended. But you still need someone in the seat to drive the stuff. This is extremely boring driving. Up and down a field. Or around and around in a field. Something that sounds pretty simple to control really. You have damned good maps available for most fields. The turns in the "head lands" are pretty standard U turns. Just need to turn and then follow the GPS. No traffic problems. Just cover all the ground in stripes. Isn't ready for use. Been following the research on that since 03 pretty closely.

That research, rarely if ever mentioned, is the basis for self driving cars. Not ready yet at all. May be in another 50 or 10 years.

The cameras that vehicles use to navigate around hazards are getting pretty good but depending on those rather than GPS for navigation is pretty tricky in itself. And tractors don't need to do that sort of navigation. They just need to accurately, more accurately than the average, say, 13 year old can do in running up and down a field or around and around a field working either in to the center or out from the center.

I suspect you could train an Orangutan to do that job. I have known a whole lot of pretty seriously "impaired" people that are very good at that sort of thing. But they really haven't gotten a computer to do that job reliably.

I can see driving aids. I can see "linking" several trucks together electronically to follow a lead truck being driven by a person. I really can't see, except in very controlled and well marked areas, vehicles that can really do the job without being real hazards. Will come eventually but definitely not tomorrow.

And it may take some dumb farmer to figure it out.

20 April 2018 - 02:46

This is probably bogus for everyone. Definitely if you are not running some applications like emacs.

Bug is for libglib2.0-0 which is not actually in a default install and most people probably don't have it at all.

There is an older bug for this from 4-3-18 that was closed because it couldn't be reproduced.

The new bug from yesterday is posted by some guy claiming to be running Debian testing with kernel 4.4.1.

Stable may be running that kernel but testing surely is not.

tom@stoned:~$ uname -a
Linux stoned.lizard 4.15.0-2-amd64 #1 SMP Debian 4.15.11-1 (2018-03-20) x86_64 GNU/Linux

Stoned Lizard has had the package upgrade installed and works fine.

Looking at bug #894763 which the current bug seems to be a duplicate of

should give you confidence to install the package upgrade.

Current bug is #896019

For people not familiar with it you can look up any bug easily from the bug number which is listed by the package "apt-listbugs" (if you get bug reports from your system that is installed) at

Just copy/paste the bug number to the first search box on that page and hit enter. Handy bugger.

Any bug filed against a package is reported by apt-listbugs. Some, not a lot, are simply bogus like this one. Many are for architectures that you are not running however. That is usually in the apt-list bugs output and you can then safely choose to install the upgrade. Most people are going to be running amd64 (intel or amd 64 bit systems) and so if the bug has a list of architectures and that isn't included it is not likely to be a problem. If no architectures are listed then you should assume it effects all architectures.

You can "hold" a package at the current version by running

# apt-mark hold <package name>

using the package name of the buggy version. To unhold that version you run

# apt-mark unhold

To see what is on hold run

# apt-mark showhold

I use these regularly and find typing them silly (bad typist). So I have

alias hold='apt-mark hold'
alias unhold='apt-mark unhold'
alias sold='apt-mark showhold'

in my

21 April 2018 - 05:48

And folks using distros based on Debian Testing

Got kernel 4.15.0-3 in Sid. Seems to be running well got it about 24 hours ago on my most used install. Should be seeing it in testing in around 10 days (19th or 20th).

Distros based on testing but using their own repos or who configure apt to go for sid kernels may see it sooner. I know that Ubuntu used to get the new testing kernels installed pretty fast when they showed up in Debian Sid but this is 4th month of an even numbered year so 18.04 is due out on the 26th so I don't know if they installed that or not as I am not sure what their rules for new packages are now or if they granted an exception for this kernel or want to wait until the new release settles in for a bit.

Kernels that are in Sid are extensively tested in Debian Testing, by devs primarily, even before being released in Sid so kernels are generally pretty solid before Debian releases them.

28 April 2018 - 19:02

Good news is that Gimp 2.10 which I have been awaiting with bated breath has landed in Sid.

Kind of. Actually the package upgrade should be avoided as Gimp ends up being removed due to the lack, currently, of the appropriate gimp-data package to go with it.

I ran the package upgrade to see what happened. Sid is the secondary OS on this drive so not a big deal with me. I am using testing as the primary OS.

I find it strange that gimp and gimp-data have never shown up in an 'apt-cache policy gimp' (or gimp-data) query output. Gimp-data doesn't now either.

If it were there I would install it over on the Sid install. Would have a while ago actually.

Hopefully this means that the Debian crew thinks it is all good and just need to get their act together and get the .debs done and in the repo.

2.10 is supposed to feature non destructive editing which is really the only real disadvantage to using Gimp. It is not a disadvantage to most users but is pretty important to people that really like to do post processing of digital photos for more than just touching them up, cropping and scaling for screen or internet viewing.

I will post further developments on this in this thread.

This sort of thing is more common in Sid than testing but the only real difference between Sid and testing is the 'rule' that RC bugs in packages should not be released to the testing repos. RC bugs being defined as packages that will prevent the OS from booting to the desktop. But this is not that sort of bug at all. It merely removes Gimp. There is no rule that prevents that sort of thing in either sid or testing.

It does make me look at the list of packages to be removed in both sid and testing pretty closely. Have had 2 x11 upgrades this testing cycle (Debian10) in Sid that definitely would have prevented booting to a desktop. Just removed most, or all of, x11 packages and the stuff like any DE that depends on that stuff.

Learned to watch out for that stuff really closely in Ubuntu-testing. They always blamed it on "upstream" (Debian). I always believed that until I installed Debian testing along with the Ubuntu-testing things. Did that, at first, just to get a heads up on the crap Debian was sending to poor Canonical. Then discovered that there were no such problems with Debian testing in about 85 to 95% of the cases where there was a problem in Ubuntu-testing.

This turns out to be caused by Ubuntu not using Debian testing, or even Sid, packages but just grabbing them from the Debian experimental repo. I Debian the testing dev team actually uses those packages in testing to detect bugs and this is why, if using apt-listbugs, there are bugs filed against package that are new to Sid most times. This makes Sid actually more stable than Ubuntu-testing way too often for comfort.

Also goes a long ways in explaining the number of serious bugs that turn up in about every new release of new "stable" Ubuntu versions. This is particularly true of the "regular" Ubuntu versions which are nominally based on Sid but also the LTS versions nominally based on Debian testing. They pull in a LOT of packages straight from the Debian experimental repo for both.

I expect this to not effect Debian testing but I will be watching any Gimp package upgrades VERY carefully in testing until this switch to Gimp2.10 is complete. I have, as a precaution, put the package Gimp on hold in testing.

# apt-mark hold Gimp
01 May 2018 - 01:33

They always are trying to tweak things from release to release. Each release team leader has their own agendas and so do all the release sub team leaders.

But this was interesting to look at today.

Definitely getting into the serious stuff.

The "Freeze" period starts in January. First part of that (Transition) is cut from down time wise in half compared to the few I have been playing with. Last time it did seem to drag on way too long with little actually seeming to happen. There was a big surge of stuff leading up to it as people rammed things in so as to get that crap out of the way.

The final - Full-Freeze - is open ended because it is defined as ending when there are no Release Critical bugs and really is down to the opinion of the release team leader. So probably does point to sometime in June of 19.

And - really planning important stuff ahead -
During the Release Team sprint in Cambridge, it was decided that Debian 12 will be codenamed "bookworm".

Debian 12 should be out sometime in 2023 so it is damned important to get this kind of thing nailed down now.

For those yearning for details of such momentous decisions in the past
Version Code name Release date Toy Story character
1.1 Buzz 1996-06-17 Buzz Lightyear
1.2 Rex 1996-12-12 Rex (the T-Rex)
1.3 Bo 1997-06-05 Bo Peep
2.0 Hamm 1998-07-24 Hamm (the pig)
2.1 Slink 1999-03-09 Slinky Dog
2.2 Potato 2000-08-15 Mr Potato Head
3.0 Woody 2002-07-19 Woody the cowboy
3.1 Sarge 2005-06-06 Sarge from the Bucket O' Soldiers
4.0 Etch 2007-04-08 Etch, the Etch-A-Sketch
5.0 Lenny 2009-02-14 Lenny, the binoculars
6.0 Squeeze 2011-02-06 Squeeze toy aliens
7 Wheezy 2013-05-04 Wheezy the penguin
8 Jessie 2015-04-26 Jessie the cowgirl
9 Stretch 2017-06-17 Rubber octopus from Toy Story 3
10 Buster not yet released Andy's pet dog
11 Bullseye Not yet released Woody's horse
Sid "unstable" The next door neighbour