UP - 01/07/2014 [TESTING] [DONE]

SolydXK is too quiet for you? SolydXK Enthusiast Editions, based on Debian Testing is for you! Here you can find news about Debian Testing and Unstable too, and also tests on SolydXK programs.
The support for SolydXK EE is provided by the community.
User avatar
Arjen Balfoort
Site Admin
Posts: 9311
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: UP - 01/07/2014 [TESTING]

Postby Arjen Balfoort » 04 Jul 2014 16:41

Wow, you're taking this really serious!

To make it work with UM, and the repos, I make a few minor changes:

Code: Select all

Temp=/tmp/$ScriptName.d
...
Url0=http://home.solydxk.com/umfiles/prd/un-kdenext-amd64/Packages.gz
Url1=http://home.solydxk.com/umfiles/prd/un-kdenext-i386/Packages.gz
I run un-kdenext from /tmp, and the Packages.gz files won't exist in production when we got to production. So, I copied them next to the un-kdenext script in their separate directories.

and this to downgrade without user input:

Code: Select all

sudo apt-get -o Dpkg::Options::="--force-overwrite" --yes --force-yes install $OptSimulate $(cat $Downgrade)


SolydXK needs you!
Development | Testing | Translations

User avatar
Arjen Balfoort
Site Admin
Posts: 9311
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: UP - 01/07/2014 [TESTING]

Postby Arjen Balfoort » 04 Jul 2014 16:55

gdebi-kde crashes after closing the window (it installs perfectly):

Code: Select all

Application: GDebi (gdebi-kde), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[KCrash Handler]
#5  0x00007f01d3a6a1bd in QWidget::~QWidget() () from /usr/lib/x86_64-linux-gnu/libQtGui.so.4
#6  0x00007f01d4a19879 in ?? () from /usr/lib/python3/dist-packages/PyQt4/QtGui.cpython-34m-x86_64-linux-gnu.so
#7  0x00007f01d49db03e in ?? () from /usr/lib/python3/dist-packages/PyQt4/QtGui.cpython-34m-x86_64-linux-gnu.so
#8  0x00007f01d5679aa6 in ?? () from /usr/lib/python3/dist-packages/sip.cpython-34m-x86_64-linux-gnu.so
#9  0x00007f01d567ac79 in ?? () from /usr/lib/python3/dist-packages/sip.cpython-34m-x86_64-linux-gnu.so
#10 0x0000000000525bdb in ?? ()
#11 0x00000000005a0fa3 in ?? ()
#12 0x00007f01d5677e77 in ?? () from /usr/lib/python3/dist-packages/sip.cpython-34m-x86_64-linux-gnu.so
#13 0x00007f01d567aba4 in ?? () from /usr/lib/python3/dist-packages/sip.cpython-34m-x86_64-linux-gnu.so
#14 0x00000000005260c2 in ?? ()
#15 0x000000000058c097 in ?? ()
#16 0x0000000000600df9 in _PyGC_CollectNoFail ()
#17 0x00000000004ce49b in PyImport_Cleanup ()
#18 0x000000000047713a in Py_Finalize ()
#19 0x00000000005fd9b3 in Py_Main ()
#20 0x0000000000484dc1 in main ()
/usr/lib/python3/dist-packages/sip.cpython-34m-x86_64-linux-gnu.so is part of the package python3-sip, but there's no newer version available.


SolydXK needs you!
Development | Testing | Translations

User avatar
grizzler
Posts: 2177
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: UP - 01/07/2014 [TESTING]

Postby grizzler » 04 Jul 2014 17:02

Schoelje wrote:Wow, you're taking this really serious!
Can't help it. ;)

When a script I create grows beyond a couple of lines, it has to be perfect (never gets there, of course, but I can't help trying...).
To make it work with UM, and the repos, I make a few minor changes:
OK. I'll put that in 1.3.0 as well.
and this to downgrade without user input:

Code: Select all

sudo apt-get -o Dpkg::Options::="--force-overwrite" --yes --force-yes install $OptSimulate $(cat $Downgrade)
LOL! Just added a -y switch to 1.3.0. Guess what that does...
Actually, all it does is the --yes. I wasn't sure about the --force-yes. By the way, isn't using them both superfluous? I don't actually know, mind you, but I would have thought --force-yes implied --yes.
Schoelje wrote:gdebi-kde crashes after closing the window (it installs perfectly)
Wasn't there a known problem with the gdebi GUIs? I seem to remember you providing a downgrade a while back.
Frank

SolydX EE 64 - tracking Debian Testing

User avatar
Arjen Balfoort
Site Admin
Posts: 9311
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: UP - 01/07/2014 [TESTING]

Postby Arjen Balfoort » 04 Jul 2014 17:35

Unfortunately, downgrading gdebi-kde results in a crash:

Code: Select all

Traceback (most recent call last):
  File "/usr/bin/gdebi-kde", line 27, in <module>
    from PyKDE4.kdeui import KApplication, KMessageBox, ki18n
ImportError: cannot import name ki18n
https://bugs.debian.org/cgi-bin/bugrepo ... bug=743756

man apt-get
-y, --yes, --assume-yes
Automatic yes to prompts; assume "yes" as answer to all prompts and
run non-interactively. If an undesirable situation, such as
changing a held package, trying to install a unauthenticated
package or removing an essential package occurs then apt-get will
abort. Configuration Item: APT::Get::Assume-Yes.
--force-yes
Force yes; this is a dangerous option that will cause apt to
continue without prompting if it is doing something potentially
harmful. It should not be used except in very special situations.
Using force-yes can potentially destroy your system! Configuration
Item: APT::Get::force-yes.
Living on the edge with --force-yes!


SolydXK needs you!
Development | Testing | Translations

User avatar
pnlarsson
Posts: 21
Joined: 30 Aug 2013 21:19
Location: Gothenburg

Re: UP - 01/07/2014 [TESTING]

Postby pnlarsson » 04 Jul 2014 17:51

Did a upgrade on metal with my old trusted former mint workstation. All well in the end - this time I tried using the UM to upgrade (first time) and something happened and it froze - had to kill a bunch of apt stuff, and then do the remaining from shell (dist-upgrade and run the post-script).

No other hickups - well there was a conflict between the i386 and x64 versions of a packet (libgmd3?) that I had to resolv.

So it worked kind of.

/niklas

User avatar
grizzler
Posts: 2177
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: UP - 01/07/2014 [TESTING]

Postby grizzler » 04 Jul 2014 18:06

Oh yeah, forgot to mention. Version 1.3.0 of the script can selectively remove packages for foreign architectures, like libgdbm3:i386 on an amd64 system (or the other way around).

I'm running it through the whole downgrade/upgrade circus again and on separate systems this time, so it will be a while before it's available.
Frank

SolydX EE 64 - tracking Debian Testing

woodsman
Posts: 115
Joined: 06 Jun 2014 01:59

Re: UP - 01/07/2014 [TESTING]

Postby woodsman » 04 Jul 2014 18:56

sudo apt-get install --reinstall firefox firefox-solydxk-adjustments
Looks like firefox-solydxk-adjustments never got installed. Is this package new with the latest update pack? As this problem has been haunting me with each new test install, I suspect a problem with the update process not installing the package. Or not being updated correctly.

Regardless, the all-in-one context menu problem seems resolved by installing that one package.

I notice adblock-plus is installed. I do not recall that add-on being installed previously but I admit not paying attention. Is this new to the latest UPs? There is no user method to remove the add-on, only disable. I detest ads in any medium in any form, but I am uncomfortable with forcing the add-on upon users.

On a side note, when I test new systems I do not have any ad blocking scheme enabled at that point. When using the web browser during that phase I am unable to focus on anything because of the constant noise and distractions caused by ads, flash, iframes, animated gifs, etc. Not to mention I notice how slow pages load because of the additional bandwidth. No wonder so many people today have short attention spans --- they simply are not allowed to think or focus.

Back to the erratic mouse problem, seems the cause is not a conflict between mate and xfce. I do not have Mate installed right now. Seems certain dialogs cause the erratic behavior. The behavior is very much like massive CPU cycles being stolen that prevent basic multitasking of events. The mouse pointer movement is very jerky during such periods. I am unable to provide further details at this point but something is awry that I did not experience before the recent round of updates. With respect to the mouse pointer, SolydX was very stable previous to the latest update pack. I have two SolydX partitions, one for the testing repo and one for the production repo. I will try to watch the mouse pointer in both.

With respect to the Update Manager, any time there is an update the system tray icon stays fixed with the circular double arrow or the gear icon. I thought a blue circle with an "i" was the notification icon for updates and the circular double arrow was used to indicate checking is in progress. If that is the case then seems the UM is always stalling during the checks.
So /tmp is no longer a symlink to /var/tmp? Is that an 'official' change?
According to the FHS (Filesystem Hierarchy Standard), /tmp is designated for non-persistent temporary files and /var/tmp is for persistent temporary files that should survive a reboot or halt. That means /tmp files may be deleted during a reboot/halt, but /var/tmp files should remain untouched at all times except directly by users.
this version also tries to remove the old hal packages.
Seems a good idea to me.

User avatar
Arjen Balfoort
Site Admin
Posts: 9311
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: UP - 01/07/2014 [TESTING]

Postby Arjen Balfoort » 04 Jul 2014 20:37

If you don't like the FF/TB additions, just remove firefox-solydxk-adjustments. You'll have a plain vanilla FF/TB like Mozilla intended them to be. firefox-solydxk-adjustments was introduced in the previous UP.


SolydXK needs you!
Development | Testing | Translations

User avatar
grizzler
Posts: 2177
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: UP - 01/07/2014 [TESTING]

Postby grizzler » 04 Jul 2014 21:09

Version 1.3.0 of the un-kdenext script is attached (and available here).

This version has the options -y and -f to set the --assume-yes and --force-yes options for apt-get. It also has the modifications mentioned earlier. It can be used from a terminal to run the entire downgrade and dist-upgrade sequence in one go like this:

Code: Select all

un-kdenext -duyf
Leave out the u option and it will just do the downgrade, leave out the y and f and it will ask for confirmation before performing certain apt-get actions.

The Upgrade and Purge variables set at the start of the script contain names of packages that will be handled before the downgrade, ignoring packages that don't exist on the system the script is running on. For the purge list, if a package name ends in a colon, the package for the foreign architecture will be removed.

I have now tested it on three different installs. No problems, but on one of them I did run into the UM stall issue mentioned in the UM testing thread - I'll see if I can run the UM from a terminal one of these days.
Attachments
un-kdenext.txt
md5: 5a5c38a0beed324ef84a800be5bc374e
(6.44 KiB) Downloaded 51 times
Frank

SolydX EE 64 - tracking Debian Testing

woodsman
Posts: 115
Joined: 06 Jun 2014 01:59

Re: UP - 01/07/2014 [TESTING]

Postby woodsman » 04 Jul 2014 22:20

this version also tries to remove the old hal packages.
Similar to the request to autoremove hal packages, please consider removing the virtualbox guest addition packages. The guest additions serve no purpose when installed in a physical system and waste time because the modules have to be rebuilt with kernel updates. Actually, removing the guest additions should be part of the original installer scripts.
If you don't like the FF/TB additions, just remove firefox-solydxk-adjustments. You'll have a plain vanilla FF/TB like Mozilla intended them to be. firefox-solydxk-adjustments was introduced in the previous UP.
I don't know what purpose the adjustments serve. When I first installed SolydX many weeks ago, I had no problems with the Firefox context menu. That bug started only with the update to 30.0. Yet I do not see that bug in LMDE or other distros where I have 30.0 installed. The context menu bug is SolydX specific.

I do not believe that package was ever installed on my SolydX system. I say that because I do not remember seeing the adblock plus add-on being installed. I noticed that the first time only with the recent wave of updates. I presume that package is how the add-on is installed.

Installing the firefox-solydxk-adjustments package solves the problem of the incorrect all-in-one context menu, but needing to do that indicates something else is not correct. I should be able to use the generic 30.0 without issues.

User avatar
Arjen Balfoort
Site Admin
Posts: 9311
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: UP - 01/07/2014 [TESTING]

Postby Arjen Balfoort » 05 Jul 2014 06:18

The live installer doesn't know if it installs in a VM or on metal. If you remove VB when installing in a VM, which many do, especially those who'd like to try it out, will have to install it manually.


SolydXK needs you!
Development | Testing | Translations

User avatar
grizzler
Posts: 2177
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: UP - 01/07/2014 [TESTING]

Postby grizzler » 05 Jul 2014 08:09

Schoelje wrote:The live installer doesn't know if it installs in a VM or on metal.
Does the live installer have access to the dmidecode command? If it does, maybe it could use dmidecode -s bios-version (as root) to find out. This will return a numerical value if it isn't run inside a VirtualBox VM and "VirtualBox" if it is.
Frank

SolydX EE 64 - tracking Debian Testing

User avatar
grizzler
Posts: 2177
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: UP - 01/07/2014 [TESTING]

Postby grizzler » 05 Jul 2014 08:24

woodsman wrote:
this version also tries to remove the old hal packages.
Similar to the request to autoremove hal packages, please consider removing the virtualbox guest addition packages. The guest additions serve no purpose when installed in a physical system and waste time because the modules have to be rebuilt with kernel updates.
While I do agree with this (the guest additions are long gone from my main system), I think it's time to stop bolting things on to un-kdenext. If I keep adding functionality, I might as well rename it to ukwlobaw (I'll leave it to you to figure out what that stands for... ;) ).
Frank

SolydX EE 64 - tracking Debian Testing

User avatar
grizzler
Posts: 2177
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: UP - 01/07/2014 [TESTING]

Postby grizzler » 05 Jul 2014 08:33

woodsman wrote:
So /tmp is no longer a symlink to /var/tmp? Is that an 'official' change?
According to the FHS (Filesystem Hierarchy Standard), /tmp is designated for non-persistent temporary files and /var/tmp is for persistent temporary files that should survive a reboot or halt. That means /tmp files may be deleted during a reboot/halt, but /var/tmp files should remain untouched at all times except directly by users.
I actually find this slightly worrying (well, I would if I worried a lot...). The current installations simply don't follow the FHS. If I install something that does and it expects /tmp/var to survive a reboot - and it has every right to - things could go pear shaped. I'm going to change this on my own system and I really think we should provide something for current users to do the same (and I don't mean a sequence of commands to enter in a terminal...).

Drat. Maybe I'll have to add another feature to un-kdenext after all...
Frank

SolydX EE 64 - tracking Debian Testing

User avatar
Arjen Balfoort
Site Admin
Posts: 9311
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: UP - 01/07/2014 [TESTING]

Postby Arjen Balfoort » 05 Jul 2014 09:12

grizzler wrote:
Schoelje wrote:The live installer doesn't know if it installs in a VM or on metal.
Does the live installer have access to the dmidecode command? If it does, maybe it could use dmidecode -s bios-version (as root) to find out. This will return a numerical value if it isn't run inside a VirtualBox VM and "VirtualBox" if it is.
I didn't know that command even existed!
On metal:

Code: Select all

sudo dmidecode -s bios-version 
ASUS M2N-SLI DELUXE ACPI BIOS Revision 1502
In VirtualBox:

Code: Select all

sudo dmidecode -s bios-version 
VirtualBox
That should be easy enough.
I'll adapt the live-installer.


SolydXK needs you!
Development | Testing | Translations

User avatar
Arjen Balfoort
Site Admin
Posts: 9311
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: UP - 01/07/2014 [TESTING]

Postby Arjen Balfoort » 05 Jul 2014 09:13

grizzler wrote:Drat. Maybe I'll have to add another feature to un-kdenext after all...
:lol: Shall I wait then?


SolydXK needs you!
Development | Testing | Translations

User avatar
grizzler
Posts: 2177
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: UP - 01/07/2014 [TESTING]

Postby grizzler » 05 Jul 2014 09:46

Schoelje wrote:
grizzler wrote:Drat. Maybe I'll have to add another feature to un-kdenext after all...
:lol: Shall I wait then?
LOL! Yeah, ok. I'm just not clear on the best way to handle this yet. I was thinking of removing the /tmp symlink, renaming /var/tmp to /tmp and creating a new /var/tmp, but exactly when to do that?

If you change things while in recovery mode as root, there's very little chance of breaking something. Do it while logged in normally (if the system will even allow that!) and you might throw some running application's files away. Main question is, are any of the files in /var/tmp actually used there or are they all accessed through /tmp? Don't know how to figure that out yet.

Edit: interesting. Just fired up my old LMDE machine which doesn't have /tmp symlinked to /var/tmp and /var/tmp is completely empty. Is that enough to conclude that doing what I suggested is safe? Questions...
Frank

SolydX EE 64 - tracking Debian Testing

User avatar
zerozero
Posts: 5373
Joined: 10 Feb 2013 23:37
Location: West Midlands, England
Contact:

Re: UP - 01/07/2014 [TESTING]

Postby zerozero » 05 Jul 2014 10:28

regarding this /tmp discussion are these links helpful?
https://bugs.debian.org/cgi-bin/bugrepo ... bug=674517
http://lwn.net/Articles/499686/
http://www.legendiary.at/2012/03/21/deb ... y-default/

debian jessie

Code: Select all

zerozero@debian:/$ ls -lA
total 88
drwxr-xr-x   2 root root  4096 Jun 18 15:11 bin
drwxr-xr-x   3 root root  4096 Jun 18 15:16 boot
drwx------   3 root root  4096 Jun 18 15:24 .config
drwxr-xr-x  14 root root  3000 Jun 19 05:45 dev
drwxr-xr-x 133 root root 12288 Jun 19 05:45 etc
drwxr-xr-x   3 root root  4096 Jun 18 15:24 home
lrwxrwxrwx   1 root root    29 Jun 18 14:40 initrd.img -> /boot/initrd.img-3.14-1-amd64
drwxr-xr-x  18 root root  4096 Jun 18 15:13 lib
drwxr-xr-x   2 root root  4096 Jun 18 14:38 lib64
drwx------   2 root root 16384 Jun 18 14:38 lost+found
drwxr-xr-x   3 root root  4096 Jun 18 14:38 media
drwxr-xr-x   2 root root  4096 May  4 13:42 mnt
drwxr-xr-x   2 root root  4096 Jun 18 14:38 opt
dr-xr-xr-x 150 root root     0 Jun 18 20:51 proc
drwx------   6 root root  4096 Jun 18 16:03 root
drwxr-xr-x  26 root root   900 Jun 19 05:45 run
drwxr-xr-x   2 root root  4096 Jun 18 15:24 sbin
drwxr-xr-x   2 root root  4096 Jun 18 14:38 srv
dr-xr-xr-x  13 root root     0 Jun 18 21:13 sys
drwxrwxrwt  11 root root  4096 Jun 19 05:17 tmp
drwxr-xr-x  10 root root  4096 Jun 18 14:38 usr
drwxr-xr-x  11 root root  4096 Jun 18 14:38 var
lrwxrwxrwx   1 root root    25 Jun 18 14:40 vmlinuz -> boot/vmlinuz-3.14-1-amd64
zerozero@debian:/$ 
tanglu

Code: Select all

zerozero@tanglu:/$ ls -lA
total 84
drwxr-xr-x   2 root root  4096 Feb 25 20:16 bin
drwxr-xr-x   3 root root  4096 Feb 21 23:11 boot
drwxr-xr-x  16 root root  2900 Mar 30 10:18 dev
drwxr-xr-x 127 root root 12288 Feb 25 20:21 etc
drwxr-xr-x   3 root root  4096 Feb 25 20:15 home
lrwxrwxrwx   1 root root    29 Feb 25 20:12 initrd.img -> /boot/initrd.img-3.12-1-amd64
drwxr-xr-x  20 root root  4096 Feb 25 20:16 lib
drwxr-xr-x   2 root root  4096 Feb 21 23:00 lib64
drwx------   2 root root 16384 Feb 25 20:12 lost+found
drwxr-xr-x   2 root root  4096 Feb 21 23:09 media
drwxr-xr-x   2 root root  4096 Feb  5 19:20 mnt
drwxr-xr-x   2 root root  4096 Feb 21 23:00 opt
dr-xr-xr-x 128 root root     0 Mar 30 10:16 proc
drwxr-xr-x   5 root root  4096 Feb 25 20:21 root
drwxr-xr-x  25 root root   720 Mar 30 10:18 run
drwxr-xr-x   2 root root  4096 Feb 21 23:11 sbin
drwxr-xr-x   2 root root  4096 Feb 21 23:00 srv
dr-xr-xr-x  13 root root     0 Mar 30 10:16 sys
drwxrwxrwt  14 root root  4096 Mar 30 10:18 tmp
drwxr-xr-x  11 root root  4096 Feb 21 23:11 usr
drwxr-xr-x  11 root root  4096 Feb 21 23:11 var
lrwxrwxrwx   1 root root    25 Feb 25 20:12 vmlinuz -> boot/vmlinuz-3.12-1-amd64
zerozero@tanglu:/$
bliss of ignorance

User avatar
grizzler
Posts: 2177
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: UP - 01/07/2014 [TESTING]

Postby grizzler » 05 Jul 2014 11:03

Thanks, but on the SolydXK installations (Home Editions at least) tmp is not mounted as a tmpfs by default (already knew that, but checked it anyway). Of course people can change it manually, so I guess any script changing the default /tmp->/var/tmp symlink situation will have to check for that first (won't making sure /tmp is a symlink do? I can't imagine a tmpfs mounted /tmp identifying as a symlink to /var/tmp...).

Somehow I think most SolydXK systems will still have tmp on a real drive.
Frank

SolydX EE 64 - tracking Debian Testing

woodsman
Posts: 115
Joined: 06 Jun 2014 01:59

Re: UP - 01/07/2014 [TESTING]

Postby woodsman » 05 Jul 2014 17:28

Just fired up my old LMDE machine which doesn't have /tmp symlinked to /var/tmp and /var/tmp is completely empty. Is that enough to conclude that doing what I suggested is safe?
KDE stores the user cache in /var/tmp. If your system is wiping /tmp, and /var/tmp is sym linked, then you are wiping the KDE user cache files every reboot. That means starting KDE always takes longer every time because KDE has to rebuild the cache. A performance hit that any user will notice.

Look in $HOME/.kde. There three temporary directories:

cache-$HOSTNAME -> /var/tmp/kdecache-$USER
socket-$HOSTNAME -> $TMP/ksocket--$USER
tmp-$HOSTNAME -> $TMP/kde-$USER

All three are sym linked. If $TMP is not explicitly defined then the code defaults to /tmp. While the latter two sym links can be deleted during a reboot/halt, the first link should not.

There are other distro maintainers who link /tmp and /var/tmp. According to the FHS that is incorrect.
The live installer doesn't know if it installs in a VM or on metal. If you remove VB when installing in a VM, which many do, especially those who'd like to try it out, will have to install it manually
I understand that and I think adding the GA to the DVD is a great idea that well supports testing in a VM. My point is after the system is installed to a physical machine, the GA packages are unnecessary and should be removed.
Does the live installer have access to the dmidecode command?
VirtuaBox systems are easily detected because of the way VB uses default strings in the VM BIOS. Here is a short list of known VirtualBOX BIOS default strings:

# Virtualbox BIOS Defaults

# Type 0 -- DMI BIOS information
#===============================
# DmiBIOSReleaseMajor = 0
# DmiBIOSReleaseMinor = 0
# DmiBIOSFirmwareMajor = 0
# DmiBIOSFirmwareMinor = 0
# DmiBIOSVendor = "innotek GmbH"
# DmiBIOSVersion = "VirtualBox"
# DmiBIOSReleaseDate = "12/01/2006"

# Type 1 -- DMI system information
#=================================
# DmiSystemVendor = "innotek GmbH"
# DmiSystemProduct = "VirtualBox"
# DmiSystemVersion = "1.2"
# DmiSystemSerial = "0"
# DmiSystemSKU = ""
# DmiSystemFamily = "Virtual Machine"

# Type 2 -- DMI board information
#================================
# DmiBoardVendor = "Oracle Corporation"
# DmiBoardProduct = "VirtualBox"
# DmiBoardVersion = "1.2"
# DmiBoardSerial = "0"
# DmiBoardAssetTag = ""
# DmiBoardLocInChass = ""
# DmiBoardBoardType = 0x0A

# Type 3 -- DMI chassis information
#==================================
# DmiChassisVendor = "Oracle Corporation"
# DmiChassisType = 0x01
# DmiChassisVersion = ""
# DmiChassisSerial = ""
# DmiChassisAssetTag = ""

# Type 4 -- DMI processor information
#====================================
# DmiProcManufacturer= "GenuineIntel"
# DmiProcVersion = "Pentium(R) III"

Two points define a line. Thus checking the values of DmiBIOSVersion and DmiSystemProduct both equal "VirtualBox" would be sufficient to confirm the system is in a VBox VM. That said, this method is not full proof. All of the above BIOS settings can be manually modified by a user. Those types of users would be extreme corner cases and are very unlikely to apply to most VBox users. Something like the following would work:

Code: Select all

DmiBIOSVersion=`dmidecode -t0 | grep 'Version:' | awk -F ': ' '{print $2}'`
DmiSystemProduct=`dmidecode -t1 | grep 'Product Name:' | awk -F ': ' '{print $2}'`
DmiBoardProduct=`dmidecode -t2 | grep 'Product Name:' | awk -F ': ' '{print $2}'`
if [ "$DmiBIOSVersion" != "VirtualBox" ] && [ "$DmiSystemProduct" != "VirtualBox" ]  && [ "$DmiBoardProduct" != "VirtualBox" ]; then
  # Remove VBox GA packages (there are three!)
  dpkg --purge package_name_1
  dpkg --purge package_name_2
  dpkg --purge package_name_3
fi
By the way, this VirtualBox GA remnant is inherited from Mint. Would be nice to offer any changes back to the them. :)


Return to “Testing Zone”

Who is online

Users browsing this forum: No registered users and 8 guests