I frequently use fwupdmgr (under Fedora 28) to upgrade the firmware of my DELL laptop and it works well. However I recently got the following error:
$ fwupdmgr get-updates
ignoring Latitude 7480 TPM 2.0 [54e80140e7d8cb6211a54dae2682399e653c0884] as not updatable
fwupdmgr is able to install other updates though.
AFAIU, TPM can't be updated if some information have been stored in it. There is an option in the BIOS to clear the data stored in TPM but I don't want to loose data.
I was wondering what are those data and if clearing them would allow me to upgrade.
In particular, I used the Machine Own Key infrastructure to be able to sign kernel modules (virtualbox). I guess those keys are stored in the TPM. If I erase the TPM data can I reinstall the same key with mokutil ?
As an aside, I discovered the problem because for quite some time, I have an error message when booting the laptop:
kernel: tpm tpm0: A TPM error (2314) occurred attempting the self test
I was wondering if those 2 errors are linked (and so if updating the firmware would suppress the error).
I cleared the data in the bios. Nothing bad happened and fwupdmgr doesn't complain anymore. The log message at boot is still there however. Thanks to #mnistic.
Related
I am in the process of migrating a very large multisite installation to newer OS platforms. Running ClearCase 9. In one particular migration stage all the VOBs appear to have migrated correctly, ct lsvob -s -host xxxx shows no VOBs remaining on the old server, but now I am getting packets stuck in the incoming bin on that old server. I assume it has to do with devs who still had views open before the migration, but the problem is that mt lspacket is complaining that it cannot find a VOB with a single UUID in the registry. Packets are piling up, and they are all complaining about the same UUID, so I assume they are all related to one VOB. ct lsvob -uuid xxxx says it cannot find a VOB with that UUID.
How would I go about correcting this?
Looking at multitool lspacket, check if a multitool lspacket –long /usr/tmp/packet1 (one of the packet listed by multitool lspacket) helps (a bit like the old CC7.0 multitool lspacket -l -dump)
If this is linked to dev views, check if you can get the a cleartool rmview --force -vob \avob -uuid an_uuid is still possible, to make sure there is no view referencing the old Vob.
The packets are getting routed to the old server by the other sites. It has nothing to do with developer views.
#VonC's lspacket -long answer will give you the name of the sending replica... Where you'll have to describe the target replica to see what it currently thinks the host is for the moved replica.
In the interim, you can copy/move the sync packets to the new server and the should import fine.
Assuming that you use the default jobs, and don't use -out to change the default packet names, running run multitool lspacket on the receiving host, you will show you names like "sh_o_sync_P50-rep_2022-11-14T160519-0500_17508." In this case, "P50-rep" is the name of the SENDING replica.
You will also see a line reading:
VOB family identifier is: 19fd6066.dbf111e1.9886.44:37:e6:60:fc:96
cleartool lsvob -family {above UUID} will identify the VOB whose sync packet this is.
* \bc-linuxtest \\this-is-the-vob-server-host\vobstore\bc-linuxtest.vbs public (replicated)
You can then combine that information to locate the sending site since the describe would look something like this:
replica "P50-rep"
created 2018-04-10T08:50:15-04:00 by CC VOB Admin (vobadm2.ccusers#Bullwinkle)
"Test replica 3."
replica type: unfiltered
master replica: P50-rep#\bc-linuxtest
request for mastership: enabled
owner: PROD\vobadm
group: PROD\ccusers
host: "this-is-the-vob-server-host"
identities: preserved
permissions: preserved
Once you go there, you will be able to see what IT thinks the replica host is, and then we can make it know where the replica is now... By hook or by crook if need be. However, the "by crook" method would mean that you need to open a support case to get the tool and the steps to use it.
My guess is that the problem replica is:
The problem replica is self mastering, and
Does not send updates to at least one "upstream" replica.
First of all, I don't mean version control such as git.
I do use git locally but, I'm trying to determine the best way to do back-ups of source code (as well as other app assets) in case of hardware failure or such.
I was thinking I could set up a script to tar my project folders, and encrypt them with gpg. I would then save the encrypted tar to external hard drives and to 1 or more off-site locations using a service such as amazon drive or dropbox.
Currently, I'm a sole developer so my thinking was that this method should be okay. But I wanted to get some input to make sure I'm doing this the best/most reliable way possible.
If there is a better approach to this that may be more applicable to small teams, then please let me know, as I'm more than happy to do the extra work implementing the approach.
There are much of ways of doing that.
But, if you always work local and you need a simple way of doing that, you may take a look at run scripts if some specific usb device is plugged in.
Meaning that a simple backup script with tar would run if you plug in your specific backup hdd.
Take a look at udev rules in linux.
udev is a generic device manager running as a daemon on a Linux system and listening (via a netlink socket) to uevents the kernel sends out if a new device is initialized or a device is removed from the system. The udev package comes with an extensive set of rules that match against exported values of the event and properties of the discovered device. A matching rule will possibly name and create a device node and run configured programs to set up and configure the device.
Take a look at these posts:
https://unix.stackexchange.com/questions/65891/how-to-execute-a-shellscript-when-i-plug-in-a-usb-device
&
https://askubuntu.com/questions/401390/running-a-script-on-connecting-usb-device
If you plan to go further, to extend the team or even to keep your code for a while in other words, if you want to be professional, I would go with a scalable and reliable tool designed for this: use a real backup and restore tool and don't use scripts. A lot of people, small (and even not so small) companies are doing it and they end up in trouble: maintenance, scalabolity, update, and so on.
There are plenty of backup & restore tools for different purposes and/or platforms, prices and so on. https://en.wikipedia.org/wiki/List_of_backup_software would be a good start :)
Cheers
Werlan
I am running a Windows 7 guest system with an Ubuntu 14 host, using VirtualBox, and have run into a problem running even the simplest examples provided by National Instruments, using the ANSI C API for NI-DAQmx.
The first time the DAQ Device is powered on, I can run a single measurement, and after that, any other measurement displays the following error message:
Attempted to read samples that are no longer available.
The requested sample was previously available, but has since been overwritten.
Increasing the buffer size, reading the data more frequently, or specifying
a fixed number of samples to read instead of reading all available samples
might correct the problem.
Property: DAQmx_Read_RelativeTo
Corresponding Value: DAQmx_Val_CurrReadPos
Property: DAQmx_Read_Offset
Corresponding Value: 0
Task Name: _unamedTask(0)
Status Code: -200279
In order to be able to start a new measurement, I have to restart the DAQ device, probably in order to clear any internal buffers that are being overridden.
I am interested in running a basic continuous voltage measurement using a callback function. (The ContAcq_IntClk example provided by NI)
The exact same configuration, same version of NI-DAQmx(9.7.5), and running on Visual Studio 2012, runs smoothly on a machine running Windows 7 directly.
I suspect the problem is with the internal buffer being somehow messed up because of the connection with the Virtual Machine, but can't figure out an elegant solution to fix it.
The device I am using is NI USB-6289.
FIXED:
VirtualBox seems to have compatibility issues with NI USB devices. It appears to work, but it's unpredictable.
VMWare works much better. Switched to VMWare Player and now works flawless.
Most use cases I've seen with xperf involve using xperfview on the same computer. A remote record and play back for me don't seem to work well. Symbols are not resolved correctly. Is there a known issue with remote record and local play with xperf/xperfview?
Why do you try remote connection? if you use xperf -d to stop logging the ETL contains all metadata, so that the symbols can be loaded from any PC you want. Copy it from PC A to PC B and view the ETL there.
Now that the 8.1 version of WPT is out, the recommended way to record traces is not with xperf.exe but with wprui.exe. This makes trace recording much simpler and much less error prone. See this blog post for details:
http://randomascii.wordpress.com/2013/04/20/xperf-basics-recording-a-trace-the-easy-way/
And yes, you absolutely should be able to record traces on one machine and view them on another.
I have read several articles about creating a Sharepoint Developer VM. They all say to "sysprep" them. Why (exactly) must the sysprep be done? What kind of problems (and why) will we run into if we don't sysprep them?
(I suppose what I am asking is, what would be the difference in doing "sysprep" and just bringing up the VM, changing its Name/IP, reboot then install SP?)
I've had success in the past with just copying Hyper-V vhd's as a method of cloning VM's - however, I now use sysprep when cloning any of my machines as it's been mentioned as a best practice in many places. And, it does some nice things like allowing you to cleaning up a bunch of stuff that I don't want to duplicate and letting me choose a new name for the machine on boot. From MS Sysprep Technical Reference:
Sysprep prepares a computer for disk
imaging or delivery to a customer by
configuring the computer to create a
new computer security identifier (SID)
when the computer is restarted. In
addition, Sysprep cleans up user- and
computer-specific settings and data
that must not be copied to a
destination computer.
And you may want to read Russinovich's post on The Machine SID Duplication Myth (and Why Sysprep Matters) for more good explanation of how SIDs work and the very last paragraph has another reason for going this route:
Note that Sysprep resets other
machine-specific state that, if
duplicated, can cause problems for
certain applications like Windows
Server Update Services (WSUS), so
Microsoft’s support policy will still
require cloned systems to be made
unique with Sysprep.
Good luck!