I received this error:
This is an automatically generated mail message from mdadm
running on host.xx.xx
A Fail event had been detected on md device /dev/md2.
It could be related to component device /dev/sda2.
Faithfully yours, etc.
P.S. The /proc/mdstat file currently contains the following:
Personalities : [raid1]
md2 : active raid1 sdb2[1] sda2[2](F)
523200 blocks [2/1] [_U]
md4 : active raid1 sdb4[1]
1901261760 blocks [2/1] [_U]
bitmap: 5/15 pages [20KB], 65536KB chunk
md3 : active raid1 sdb3[1]
51198912 blocks [2/1] [_U]
unused devices:
Then I received this other email:
Subject: FailedOpenDevice
Device: /dev/sda [SAT], unable to open device
How can I know if I have a problem in one of the 2 disks I have?
How can I know if I have a problem in one of the 2 disks I have?
FailedOpenDevice Device: /dev/sda [SAT], unable to open device
You have a problem with your /dev/sda. You see sda2[2](F) in your mdstat, that (F) means that that disc (/dev/sda2) is faulty. See your dmesg for further errors.
Related
I am looking to connect to Bluetooth devices on Linux and store information about them in a database. I have used the code from here as the starting point. It uses
prop_changed = g_dbus_connection_signal_subscribe(con,
"org.bluez",
"org.freedesktop.DBus.Properties",
"PropertiesChanged",
NULL,
"org.bluez.Adapter1",
G_DBUS_SIGNAL_FLAGS_NONE,
bluez_signal_adapter_changed,
NULL,
NULL);
to be notified when new Bluetooth devices appear. And I reuse its bluez_device_call_method() function to call the DBUS Connect() method documented in the BlueZ D-Bus Device API on every new device that appears:
bluez_device_call_method(object, "Connect");
Most devices just time out, but some devices appear to connect sucessfully. My question is, for those devices which I've connected successfully to, how do I get more information about the device I'm talking to?
The only other APIs documented in the BlueZ D-Bus Device API that seem like they'd let me retrieve more information are "void ConnectProfile(string uuid)" and "void Pair()". For ConnectProfile() how am I supposed to know the UUID? Is it just what's printed out via entries like the below?
[ /org/bluez/hci0/dev_48_57_DE_00_AA_09 ]
Address : s : 48:57:DE:00:AA:09
AddressType : s : random
Name : s : Blood Pressure
Alias : s : Blood Pressure
Paired : b : 0
Trusted : b : 0
Blocked : b : 0
LegacyPairing : b : 0
RSSI : n : -65
Connected : b : 0
UUIDs : a :
0000180a-0000-1000-8000-00805f9b34fb
00001810-0000-1000-8000-00805f9b34fb
And if it succeeds, where would I find the returned data?
And for Pair(), it says "This method will connect to the remote device, initiate pairing and then retrieve all SDP records (or GATT primary services).", but if it succeeds, where would I find the returned data?
So far I've tried:
ret = bluez_device_call_method(object, "Connect");
if(ret == -1){
bluez_device_call_method(object, "Pair");
}
else{
printf("Connect() succeeded! Now what?!\n");
}
But I don't think Pair() has ever succeeded, whereas Connect() has succeeded occasionally with some devices.
[Question posted by a user on YugabyteDB Community Slack]
I'm just testing yugabyte under some negative tests and I'm facing a kind of issue. I'm running a 3 node cluster (master and tserver running on same node) When I stop one node and start it up again, T-server is not booting up under this log
F20220506 06:50:49 ../../src/yb/tserver/tablet_server_main.cc:220] Invalid argument (yb/util/universe_key_manager.cc:73): Could not init Tablet Manager: Failed to open tablet metadata for tablet: eb1e5457022f42c084148ca8fa4ba5c6: Failed to load tablet metadata for tablet id eb1e5457022f42c084148ca8fa4ba5c6: Co
uld not load Raft group metadata from /data/yugabyte/data/yb-data/tserver/tablet-meta/eb1e5457022f42c084148ca8fa4ba5c6: Key with version number c7b91fad-dd60-404f-8846-cab568e52468 does not exist.
# 0x7fcdace5ee4c yb::LogFatalHandlerSink::send()
# 0x7fcdaa5e28ee google::LogMessage::SendToLog()
# 0x7fcdaa5dfa7a google::LogMessage::Flush()
# 0x7fcdaa5e3169 google::LogMessageFatal::~LogMessageFatal()
# 0x4124ea yb::tserver::(anonymous namespace)::TabletServerMain()
# 0x7fcda6811825 __libc_start_main
# 0x410f99 _start
# (nil) (unknown)
The only way to start it up is remove the old data.
My steps were:
1.- Cluster up with 3 server
2.- Create a taable with 3 partition on different tablet id confirmed via UI)
3.- Insert 3 different row to diff partition
4.- Select * working fine
5.- Shut down one Table server
6.- Select * working fine
7.- Starting up the table server (error)
We are running using config file:
/usr/local/yugabyte/src/yugabyte-2.11.0.1/bin/./yb-tserver --flagfile /data/yugabyte/etc/tserver.conf
and config:
--tserver_master_addrs=ip1:7100,ip2:7100,ip3:7100
--rpc_bind_addresses=fqdn
--server_broadcast_addresses=ip1
--enable_ysql
--pgsql_proxy_bind_address=ip1:5433
--cql_proxy_bind_address=ip1:9042
--fs_data_dirs=/data/yugabyte/data
--placement_cloud=cloud
--placement_region=reg
--placement_zone=zone
--use_client_to_server_encryption=true
--certs_for_client_dir=/data/yugabyte/ssl
--certs_dir=/data/yugabyte/ssl
--use_node_to_node_encryption=true
--ysql_enable_auth=true
--log_dir=/data/yugabyte/logs
--ssl_protocols=tls12,tls13
--ysql_pg_conf=pgaudit.log='DDL',pgaudit.log_level=notice,pgaudit.log_client=ON,log_min_messages=notice,log_line_prefix='\%m \%r \%u \%d [\%p]'
Looks like the key is not in memory:
/usr/local/yugabyte/src/yugabyte-2.11.0.1/bin/yb-admin -master_addresses $master get_universe_config
{"version":2,"replicationInfo":{"liveReplicas":{"numReplicas":3,"placementBlocks":[{"cloudInfo":{"placementCloud":"cloud","placementRegion":"region","placementZone":"zone"},"minNumReplicas":1}]}},"clusterUuid":"dccea8cb-9790-48ba-8a05-6218a8e875a4","encryptionInfo":{"encryptionEnabled":true,"universeKeyRegistryEncoded":"sZTzNciYu6b1KxZonpJx6v7CDDvexiv1jh/HIEAOkpV4YRrIZbIK9jtajdEMmVEUy706+dmz8bmnZvy6/n33u+qS7fzRSOTPOlpxYI6+k1lSM6bu2DRTTffhZtaiKN15gy8a3ifaZV7xJ9QJ3z9SvFYzb96+KDWw","keyPath":"/data/yugabyte/rest/universe_key","latestVersionId":"c7b91fad-dd60-404f-8846-cab568e52468","keyInMemory":false}}
KeyInMemory: False
We are using encryption at rest but the the file with the key should be there.
Am I doing something wrong?
usr/local/yugabyte/src/yugabyte-2.11.0.1/bin/yb-admin -master_addresses fqdn:7100 all_masters_have_universe_key_in_memory 7e13c99e-5278-4abd-ab78-79f70d6c2679
Error running all_masters_have_universe_key_in_memory: Operation failed. Try again. (yb/tools/yb-admin_client_ent.cc:1027): Unable to check whether master has universe key in memory.: Node fqdn:7100 does not have universe key in memory
The above error seems to indicate the tserver is looking for a key - “c7b91fad-dd60-404f-8846-cab568e52468” in order to open the file, but can’t find it.
Realizing that there’s an actual key file on the masters. That’s been deprecated for using more secure in-memory keys. I just did a little digging through the code, and sure enough, we don’t actually support sending on-disk keys to tablet servers on restart.
The command you have to run is this one:
yb-admin -master_addresses <master-addresses> add_universe_keys_to_all_masters <key_id> <key_path>
and then right after that it should work:
/usr/local/yugabyte/src/yugabyte-2.11.0.1/bin/yb-admin -master_addresses $master all_masters_have_universe_key_in_memory 1
Node fqdn1:7100 has universe key in memory: 1
Node fqdn2:7100 has universe key in memory: 1
Node fqdn3:7100 has universe key in memory: 1
I build open cryptoki library from source and try to initialize the software token.
but when running pkcsconf -I -c 3 for initializing the token, I get the following Error message:
Enter the SO PIN:
Enter a unique token label: poef
Error initializing token: 0xA4 (CKR_PIN_LOCKED)
The token Info looks like this:
$ pkcsconf -t
Token #3 Info:
Label: IBM OS PKCS#11
Manufacturer: IBM Corp.
Model: IBM SoftTok
Serial Number: 123
Flags: 0xD80045 (RNG|LOGIN_REQUIRED|CLOCK_ON_TOKEN|USER_PIN_TO_BE_CHANGED|SO_PIN_COUNT_LOW|SO_PIN_LOCKED|SO_PIN_TO_BE_CHANGED)
Sessions: 0/18446744073709551614
R/W Sessions: 18446744073709551615/18446744073709551614
PIN Length: 4-8
Public Memory: 0xFFFFFFFFFFFFFFFF/0xFFFFFFFFFFFFFFFF
Private Memory: 0xFFFFFFFFFFFFFFFF/0xFFFFFFFFFFFFFFFF
Hardware Version: 1.0
Firmware Version: 1.0
Time: 08:07:03
So as I understand I should reset the Software Token, to get a default SO PIN and could initialize the token, to use it. But I cannot find anything about that in the official docs.
To reset everything, you have to delete the content of /var/opencryptoki/swtok
Have you seen this page https://www.ibm.com/support/knowledgecenter/en/linuxonibm/com.ibm.linux.z.lxce/lxce_initializing_ep11token.html
I have no familiarity with this specific SW P11 implementation but the command sequence here seems to make sense.
The default pin is 12345678, you would want to change that, initialize the user pin, change that. Theory being that in that sequence you wont be locked.
How can I see the gateway connected individual device data in the IBM-watson-IoT dashboard ? Is there any specific way see that?
Right now I am sending data as:
//publishing device events with deviceType 'Raspi' and deviceId 'pi01' using the default quality of service
gatewayClient.publishDeviceEvent("Raspi","pi01", "status","json",'{"d" : { "cpu" : 60, "mem" : 50 }}');
console.log('event published');
But I am not able to see this data stream anywhere in the IBM-watson-IoT dashboard. It's showing the event as received but no data stream of device "pi01".
When data is sent as:
gatewayClient.publishGatewayEvent("status","json",'{"d" : { "cpu" : 40, "mem" : 50 }}');
this means as gateway. It shows "received data" when I am creating the card. But I dont want this, I have a different device connected with the gateway, so I want the new device data in a different data stream.
Please let me know if I am doing it right, and if yes then where can I see all that data.
The only way to do this in the Dashboard is in a Card. No other way in the Dashboard (though there are other ways outside of the dashboard). Your code looks fine. If you select your device in a Device centric card you can see the stream of values for just that gw-device in the properties or make graphs etc if they would help. It is its own stream of data; should not be mixed up with any other device even if they share the same gateway. Here is one gateway sending data for 2 devices using:
gatewayClient.publishDeviceEvent('SenseHat','sen-pi-xxx-gw' ,'event', 'json', '{"sugar":5, "salt":2}', 1);
gatewayClient.publishDeviceEvent('SenseHat','xx-gw-device' ,'event', 'json', '{"sugar":9, "salt":12}', 1);
I am building my own kernel. The device tree of the kernel is modified, because of an own designed mainboard.
I can enable the can devices by:
// here ATMEL is defining the can0 and can1 memory mapped devices
#include "sama5d3_can.dtsi"
...
can0: can#f000c000 {
status = "okay";
};
can1: can#f8010000 {
status = "okay";
};
But now I want to switch the names of them. Can0 should become can1 and can1 should be can0.
How to do that?
PS: the error print when switching the labels and building the kernel:
| ERROR (duplicate_label): Duplicate label 'can0' on /ahb/apb/can#f8010000 and /ahb/apb/can#f000c000
| ERROR (duplicate_label): Duplicate label 'can1' on /ahb/apb/can#f8010000 and /ahb/apb/can#f000c000
The network "devices" do not take their name from the DTS at all. They get it from the name that is given to the netdevice.name.
In your case, the at91_can.c driver calls alloc_candev() that explicitely sets the interface's name to can%d (can0, can1, ...). The number "assigned" to each device in then strictly dependant on the sequence of the "enumeration" of the hardware and its registration with the at91_can driver.
Changing the device tree will not help you in changing the name of the network interfaces. If you really need to change the name of the can interfaces, you could write udev rules that do so.