Ubuntu Unity 21.10
Oh and by the way. The little text on lightdm screen still says “Ubuntu 21.04”
Ah, that’s because the ISO’s filesystem is heavily compressed (to make it as small as possible). I guess I’ll temporarily remove the LightDM text until @khurshid-alam updates the greeter text.
What’s the need, though? It doesn’t contain external PPAs and packages, does it?
The wallpaper rocks, though! It’s much better than the one on the main desktop. Excellent work!
After a bit more investigation I have a better problem description and some screenshots.
I instrumented the wrapper to both output the $LD_PRELOAD value as well as a indication
of which of the exports we were doing so I could know which was being executed.
This first screenshot is what happens if you open a terminal and type sudo dmesg:
This is the actual problem. For some reason we are getting the export LD_PRELOAD run when doing a sudo command(not application) in a terminal.
This second screenshot shows that if you invoke the the wrapper directly and launch a app
(in this case gnome-calculator) it works fine. Note the instrumented code that states that
the wrapper is being called directly.
This third screenshot is what happens if you invoke the same above command using sudo:
So for some reason the LD_PRELOAD is getting invoked when we are doing sudo and launching
a command or app from the terminal. This does not happen on 21.04 or on my build machine
which does not have the new libgtk3-nocsd code in it.
There is also another spot in the wrapper code where we do the export LD_PRELOAD that I have
instrumented but it not getting hit due to not calling the executable directly. Not sure if this gets
hit otherwise. We also do an export LD_PRELOAD in the /etc/X11/Xsession.d/51gtk3-nocsd-detect
file. This file is sourced and not executed by xsession so I am not sure how you would instrument it
or test it(maybe make a copy of it and make it a bash executable and run it manually?). I also am not
sure when this gets run but I assume this is what gets run normally when not invoking the wrapper
directly(or maybe it’s the other case in the wrapper).
That’s as far as I have gotten so far. In short the new libgtk-nocsd code works but I am getting
this weird artifact from it. It maybe because I have purge and replaced it a few time and something has gotten messed up.
Next steps:
1- make new updated iso without the new libgtk-nocsd code and install on test machine.
2- install new libgtk-nocsd deb again on the fresh install to make sure it’s reproducible.
3- if worse comes to worse I will have to install the actual Ubuntu beta and test it on it
(probably should do this anyway just for completeness but had mine already installed
and wanted to save time).
Questions:
1- which tool do you use for making your debs? I am using dpkg-deb -R and dpkg-deb -b
should I be using dpkg-repack or something else instead?
2- what do you use to build your iso?. Are you using the standard ubuntu build scripts
or something else?
I checked out your beta and it’s really well done. I usually make separate Unity, Gnome and
Plasma dists as well as Ubuntu Studio on occasion.
Anyway back to testing,
Brett “WolfMan” Bogert
Are you referring to the initial boot from the flash drive before install or the boot
after install.
When booting from the flash drive there is a check on the iso’s integrity. This check seems
to take forever and really extends the boot time.
To disable it just add “fsck.mode=skip” to the menu entry in your grub.cfg file.
If you need an example I can provide one.
Brett “WolfMan” Bogert
Nah, there’s no filesystem check in 21.10. I’ve already responded to his messages.
I beg to differ. It depends on whether you are talking about booting from the flash
drive or booting and already installed system.
Here is a screenshot of Ubuntu 21.10 desktop beta builds grub.cfg file.
Note that there is no mention of fsck.mode=skip. This means it will run
the fsck on boot:
Here a screenshot of my grub.cfg file that I use when I create my iso with WolfLandBuilder.
Note the fsck.mode=skip in the boot entry:
Oops…
And lastly here is the grub.cfg file from my iso from the flash drive.
Note it too contains the fsck.mode=skip in the boot entry:
This is why I asked if he was doing initial boot from flash before install or talking about the boot
on an installed system.
Brett “WolfMan” Bogert
I’ve been booting from a USB to test the images but the system has Xubuntu installed.
AFAIK the Ubuntu 21.04 and the 21.10 daily ISOs have removed the filesystem check in the live ISO before installation (and it was never present in the installed system).
I don’t think the problem is the filesystem check. I didn’t see the usual output of fsck, i.e. FILE checked: OK.
If no one else is experiencing long boot-ups, then it’s probably just my hardware, although Ubuntu main images boot up smoothly and quickly from the same USB stick.
Ok… I would have never noticed it as I have been disabling it ever since they started
doing it. I use a special version of grub.cfg that has a placeholder for volume name
that can be set via dialog in the builder. You can see that in screenshot 2 and in
screenshot 3 you can see the actual volume name as it appears in the grub.cfg file
after the iso is burned to flash or DVD so I have to use my grub.cfg file instead of
the standard one.
Sorry for the confusion,
Brett “WolfMan” Bogert
Ok after being up all night I finally was able isolate the problem and then verify I was
correct with a quick fix.
I wanted to be sure that the error was not caused by something in my build so I installed
Ubuntu Unity 21.10 beta, updated it and installed the new libgtk3-nocsd deb and tested
again. As it turned out it looks to be a day 1 bug in /etc/X11/Xsession.d/51gtk3-nocsd-detect.
It looks like the xsession file we source is for the “system wide” LD_PRELOAD and the wrapper
is for individual control by app.
The problem is that the 51gtk3-nocsd-detect code is not passing the lib path as well as the lib
file name to the LD_PRELOAD. Since it can’t find the file the LD_PRELOAD bork’s and we get
the error message.
I proved this was the case by adding the following line of code to the file in which I used find
to get both the path and filename and stuff in a variable which I then pass to LD_PRELOAD
statement to ensure we actually can preload the lib:
Here is a diff of what I did:
diff -Naur Downloads/Unity\ Development/gtk3-nocsd/tmp_test/etc/X11/Xsession.d/51gtk3-nocsd-detect Downloads/Unity\ Development/gtk3-nocsd/tmp_gtk3-nocsd_3-1ubuntu2/etc/X11/Xsession.d/51gtk3-nocsd-detect
--- "Downloads/Unity Development/gtk3-nocsd/tmp_test/etc/X11/Xsession.d/51gtk3-nocsd-detect" 2018-03-02 23:46:21.000000000 -0500
+++ "Downloads/Unity Development/gtk3-nocsd/tmp_gtk3-nocsd_3-1ubuntu2/etc/X11/Xsession.d/51gtk3-nocsd-detect" 2021-10-03 09:45:38.587385641 -0400
@@ -19,7 +19,8 @@
fi
export GTK_CSD
if [ x"$GTK_CSD"x = x"0"x ] ; then
- export LD_PRELOAD="libgtk3-nocsd.so.0${LD_PRELOAD:+:$LD_PRELOAD}"
+ GTK3_NOCSD=`find /usr/lib -name libgtk3-nocsd.so.0 -print`
+ export LD_PRELOAD="${GTK3_NOCSD}${LD_PRELOAD:+:$LD_PRELOAD}"
fi
;;
esac
This is simple and elegant and fixes the problem.
The question is do we want to use my testing fix for the solution for the “system wide”
LD_PRELOAD or do we want to clone the code as done in the wrapper an use it for
“system wide” as well. The drawback to doing this is that we now have 2 copies of the
mostly the same code that we must change/maintain instead of just 1 when we make
a change to the wrapper. The plus with this is that we would be using the same way
to determine the path for the bin and lib files in both “system wide” and the wrapper.
I leave it up to the code owner khurshid-alam to make this choice and can provide either
solution that he chooses(I have only actually tested my diff code so far but can code and
test the other should he chose that option).
I have tested debs available for both gtk3-nocsd and libgtk3-nocsd built with dpkg-deb - b
and can put them in my dropbox and provide links for download if anyone want’s to test
them or unpack and look at them.
I am not sure what the next step is as far as submission to launchpad goes so let me know
what I need to do next and I will do it. I think I have taken this one about as far as I can unless
we decided to impement the alternative solution, test and get it ready for submission.
Well I was going to give the links for the debs in my dropbox but the Nautilus plugin does
not seem to be working. I will make another post as soon as I get it straightened out.
Brett “WolfMan” Bogert
Now that I have the Nautilus dropbox plugin working again here are the links to the debs:
gtk3-nocsd:
https://www.dropbox.com/s/k3d27gize7oj2h1/gtk3-nocsd_3-1ubuntu2_all.deb?dl=0
libgtk3-nocsd:
https://www.dropbox.com/s/3876bp9qgmcylxp/libgtk3-nocsd0_3-1ubuntu2_amd64.deb?dl=0
I’m going to take a nap. Will check back when I wake up.
Thanks,
Brett “WolfLand” Bogert
1 Like
I just wanted to thank you for your work. I’m looking forward to this release 
Have a good one!
Folks
Don’t bother using/testing the debs.
This morning I took a fresh look at the problem I was seeing and it is not related to
the code but to my noob ignorance. I build the lib’s deb using a process for source
debs not binary debs. This means that the lintian overrides never get run/set so
the permissions on the lib file are wrong(the lintian overrides prevent the problem
I am seeing). Why my testing hack fixes it I do not know.
Anyway I will remove the debs from my dropbox and I need to know how I properly
build the deb. Since I have no experience with binary debs I don’t have a clue how to
build it. I have tried dpkg-buildpackage -rfakeroot but it bombs on not finding the
DEBIAN directory.
Anyway the new lib code works fine I just need to build the deb properly so that
the lintian overrides get processed and we get the right permissions on the lib
file to prevent the side effects I am seeing.
Any help would be appreciated.
Thanks,
Brett “WolfMan” Bogert
You can try installing the devscripts package and then run debuild in the directory containing the debian/ folder.
Folks,
After 10 hours of cussing I finally got the new .debs built.
I have opened a bug report and assigned it to me and am
just waiting for it to be screened(e.g. assigned a number)
so I can redo the changes file with the bug report number
and rebuild/test the .debs. (I assume that I need a bug report
number to commit a change).
I have tried to somewhat document what I had to do so I have
a step by step list of what needs to be done to create a new
.deb version from an existing one if anyone needs it.
If I don't have a bug report number by tomorrow morning I will
test what I have an then retest when I get the number before I
commit the .deb/.debs (not sure if I need to commit both as there
are no changes to the wrapper .deb).
Thanks,
Brett “WolfMan” Bogert
No, you don’t need a bug report (you can remove the Closes: bit from the changes line in dch or debian/changelog).
Ok… I will see if I can close the bug report and do the “Closes:bit” and then
do the commit as soon as I can figure out how.
Before I forget is anyone working on Unity-Tweak?. If I remember correctly it
has a schema issue with the “antialiasing” schema entry not being there any
more. I assume that we are using a “shared” schema with Gnome and they
have changed it and we just need to grap the one from 21.04 and probably
rename it, put it in a Unity specific schema directory, rename it and change
the code to reference it instead of the old shared scheme.
Anyway after I get the commit done I can look at it if needed. Be nice to
have it working for release.
Thanks again,
Brett “WolfMan” Bogert