i have installed sg-utills in ubuntu in vmware workstation:
sudo apt instll sg-utills
and i want to use sg_sanitize.
as you can see in https://rackhd.readthedocs.io/en/latest/server_workflow/secure_erase.html , about sg_sanitize: "not all SCSI drives support SANITIZE command". how can i know if my drive supports sg_sanitize or not? when i enter the following command:
sg_sanitize --overwrite --zero /dev/sdc
the output is :
VMware, VMware Virtual S 1.0 peripheral_type: disk [0x0]
A SANITIZE will commence in 15 seconds
ALL data on /dev/sdc will be DESTROYED
Press control-C to abort
A SANITIZE will commence in 10 seconds
ALL data on /dev/sdc will be DESTROYED
Press control-C to abort
A SANITIZE will commence in 5 seconds
ALL data on /dev/sdc will be DESTROYED
Press control-C to abort
Sanitize failed: Illegal request, Invalid opcode
sg_sanitize failed: Illegal request, Invalid opcode
The "SCSI way" is basically to do exactly what you did: try the command. If it works, then the device supports it. There is a MAINTENANCE IN / REPORT SUPPORTED OPCODES action that is nice when it works, but not all devices actually respond to it. And, even when they do, sometimes its output isn't up to date.
You can try it on your system with the sg_opcodes command. Here's what it looks like on a high-end SAS drive:
% sg_opcodes /dev/sdc | grep -i sani
48 2 10 Sanitize
48 1f 10 Sanitize
But, I think you'll find that VMware doesn't support that opcode either.
Related
I created an image of debian 7 on an SSD disk and later restored it on another computer with excatly same type of SSD disk. however I'm getting the error message No bootable device -- insert boot disk and press key
The image was created using a live OS with the command: dd if=/dev/sda conv=sync,noerror bs=64K | gzip -c > backup.img.gz
And later restored to disk with:
gunzip -c backup.img.gz | dd of=/dev/sda
I've done this plenty of times before on older computers and it usually works fine. These computers has EFI, could this be the issue? Any ideas, or workarounds?
Thanks
Do you use MBR or GPT on SSD?
Possibly you will need to switch between UEFI/LEgacy boot mode as shown here:
https://phoenixts.com/blog/uefi-vs-legacy-bios/
Good Morning,
i'm trying to work out the reason to weird characters being outputted in a serial console in linux.
Device:
12d1:15c1 Huawei me906s module in a WWAN to USB adapter (working for normal operations and switches modes etc
The device is connected initially with the PID 15c1 and the output of lsusb -v below:
12d1:15c1 Output
When the device is sent the AT Command of AT^GODLOAD, it switches into download mode which changes its PID too 1568. Output of lsusb -v below:
12d1:1568 Output
OS:
Ubuntu 16.10
Speed:
9600 baud as reported by stty -F /dev/ttyUSB0
Expected: Send AT Commands through /dev/ttyUSB0 with minicom or echo/cat
Result and Description:
When the device is in normal mode (15c1) the device ttyUSB0 is used to send AT Commands, this works perfectly and we can set the chip into download mode (PID 1568)
After Download mode is enabled the chip reboots and reconnects too ttyUSB0, however weird characters show up in minicom and through terminal using 'cat
The weird characters are the same in both monitors and the hex is:
7e 03 00 06 9e 4c 7e
When we send any AT command in download mode the characters show up, except for one AT command as shown in the pictures. This command is significantly larger than any other ones.
Command examples which don't work in GODLOAD:
AT+CMGR?
ATI
-Results in the weird characters ~[][][][]L~
Command which does work:
AT^SIGNVER=5,0,1234567891011121314151617181920, 8502
We have used wireshark to capture the update process on a windows machine.
I actually have screen shots of the operation, commands etc but cannot post them due to limit.
Questions:
-Does the packet size matter for serial commands sent to the module?
-Are we missing some form of a line ending, carriage return or termination to start/end the message correctly?
Thanks for your help in advance
I am start learning Linux(CentOs 5.5 kernel 2.6.35.13).
When I try to install a usb wifi stick(TP-Link TL-WN823N,and "lsusb" will show ID 0bda:8178 Realtek Semiconductor Corp..)
It work fine in the window interface( ctrl+shift+F7).
But when I shift to the command window(ctrl+shift+F1),and try to start wifi connection by
wpa_supplicant -Bw -Dwext -iwlan0 -c/etc/wpa_supplicant.conf
I found it kept print logs to screen before I type the command above.
I use
ps axjf |grep wpa_supplicant
to list all related process and find
there is a process start by user "dbus" with the command
/usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -u -f /var/log/wpa_supplicant.log
I dont know whether is this dbus' command that lead the problem.
Below is the screen shot.
kept logging msg:(
Partly fix the problem.
There are two things that make the wifi information keep on loging on the screen.
First, if you use NetworkManager, it will automate run the command under /etc/sysconfig/wpa_supplicant, where you can find the default command write there has no -B parameter which will keep the log in the background.So you can either add an -B to that command or stop NetworkManager and start wifi connection with your own command like in the question.
Second, when you install the driver, the default run status is power saving mode, so when you transfer data with wifi, you can see the screen keeping log infomation like "get into the pw_saving","get out pw_saving" etc.
To fix this, you can shut down the power saving mode like this:
create a file /etc/modprobe.d/8192cu.conf with the following contents:
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0
Or you can rewrite driver code to stop print the info to screen, which I still don't know how to do.
I am trying to set latency timer value of my Intel PCI card using following command
sudo setpci -d '8086:0100' latency_timer=01
But when I read the value of this register back it is unchanged and shows previous value.
I am using following command to display value of the register
sudo setpci -d '8086:0100' latency_timer
Can anybody tell why I'm unable to change value of latency timer?
I'm using a Linux machine.
There is a good chance that you have more than one PCI devices or more than one functions with identical vid:did.
Find out the location of your PCI device using sudo lspci, then use
sudo setpci -s bus:slot.func ...
instead of
sudo setpci -d vid:did ...
Back in the good-old days of floppy, if you enable write protection of a floppy, DOS would kindly tell you that you cannot write to it. Now we have SD card that can hold the content of thousands of floppy and we still have the write protection - and it's handy sometime. But nobody is able to tell me I can't write to it, at least on Linux. I have a lovely script that partition and format a SD card in a way I like. It took me 1/2 hour of debugging just to find out that the SD card is write-protected.
So the question, is there a way that the software can detect such condition?
Thanks,
The driver knows when the card is write-protected, and it actually warns when you mount it via command line:
# mount /dev/sdc1 /media/flash
mount: block device /dev/sdc1 is write-protected, mounting read-only
In case you would like to check it yourself at device level, you can use the hdparm command to query read-only status of disk device, including SD card and USB flash drive in general. This program should be available in most GNU/Linux distributions, commonly in a package named "hdparm".
If you are not root, be sure to specify full path to the hdparm command; and this assumes you have read permission on your card of course.
For example: my SD card is inserted, detected as /dev/sdc, and write protection tab is at Unlock:
$ /sbin/hdparm -r /dev/sdc
/dev/sdc:
readonly = 0 (off)
When I slided the write protection tab to Lock, re-insert the card, and run the command again:
$ /sbin/hdparm -r /dev/sdc
/dev/sdc:
readonly = 1 (on)
If you would like to do it in shell script, you can try something like:
READONLY=`/sbin/hdparm -r /dev/sdc 2>&1 | sed -n 's/^.*= *\([01]\) .*$/\1/p'`
if [ "$READONLY" = "0" ]
then
echo Card is writable.
else
echo Card is not writable.
fi
Note: If you prefer to do it in C, you can try either:
Opening the device file in write mode and see if it fails with errno value EROFS (Read-only file system), or...
Opening the device file in read mode, then issue ioctl() named BLKROGET, and check if the result value is nonzero; this is the way hdparm work.