I forgot my password and now unable to reset it.
I tried to update he below file in SD Card with init=/bin/sh
recovery.cmdline
But when I inserted the SD card in Raspberry Pi again it gave me error and unable to start.
On SD's root folder (/) edit the cmdline.txt file. It should contain below line of text:
dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
You should write init=/bin/sh at the end.
Put SD card with edited file to Pi and power it up. Next step is to mount root:
mount -rw -o remount /
Then run below command for pi user, type desired NEW password:
passwd pi
Next two more commands:
sync
exec /sbin/init
Probably the screen will go black, if so, wait few minutes then turn it off.
Last step is to revert changes in cmdline.txt file (remove init=/bin/sh).
After that put SD card to rPi and log in with NEW password.
Related
I want my Raspberry Pi 4B, running Raspian 10, to boot up with a permanently-inserted USB flash drive mounted to /srv/www. The flash drive will never be removed. I formatted the flash drive with an ext4 filesystem. I can manually mount the drive to /srv/www and perform normal file operations.
When I add an entry to /etc/fstab like this:
/dev/sda1 /srv/www ext4 0 0
or like this:
UUID=651003ce-5261-4b00-9940-6207625a5334 /srv/www ext4 0 0
the mount does not succeed when the system boots. I've been at this for hours, trying various suggestions for configuring systemd and see a variety of errors in system logs such as "/dev/sda does not contain a filesystem" but fsck tells me it does. Before I go spend more hours, is what I'm trying to do possible and where am I going wrong?
Unable to find a fstab-related solution, I solved the problem by placing these two lines in /etc/rc.local
sleep 5s
mount /dev/sda1 /srv/www
I just wanna boot my windows install (already installed) via Qemu. I was able to do it by VMware Fusion. But it got buggy and after days trying to solve it. I give it up and thought about Qemu.
I have this lines
qemu-system-x86_64 -m 9072 -cpu Penryn,+invtsc,vmware-cpuid-freq=on,$MY_OPTIONS\
-machine q35 \
-smp 4,cores=2 \
-usb -device usb-kbd -device usb-mouse \
-smbios type=2 \
-device ich9-ahci,id=sata \
-drive id=WIN,format=raw,if=none,file="/dev/disk2s4",index=0,media=disk \
-device ide-hd,bus=sata.4,drive=WIN \
-monitor stdio \
-vga vmware
It is "draft". I was trying out. But my issue is that I wanna pass my SSD NVMe to this machine. I couldn't find anything useful for MacOS in the internet, searching for hours. Those lines are what I found. Not even in Qemu docs I couldn't find anything.
I got "Booting from Hard Disk..." forever...
from https://www.qemu.org/docs/master/system/qemu-block-drivers.html
https://www.qemu.org/docs/master/system/images.html#nvme-disk-images
should be :
qemu-system-x86_64 -drive file=nvme://0000:06:00.0/2
where dmesg | grep nvme you see [1] and you want p2
[1]
nvme nvme0: pci function 0000:06:00.0
nvme0n1: p1 p2 p3 p4
but for me still doesn't work ...
qemu-system-x86_64: -drive file=nvme://0000:06:00.0/0002: Failed to find iommu group sysfs path: No such file or directory
Well, I've tried the same but with SATA SSD drive, I just pointed to the main drive (not specific partition), and with other configurations in the args, it booted normally. Actually this SSD drive had a Windows 11 installed on it already, so just attaching it via QEMU took a little bit to configure new hardware then worked properly.
First, you need to find the disk name in Disk Utility, right click on the drive itself, not the partition. In my case it's disk1, so I'll be using /dev/disk1 when running the command.
See below in order, you can save this text to boot-windows.sh file, then run it from terminal with sudo.
DISK="/dev/disk1"
OVMFDIR="usr/share/edk2/ovmf" #for enabling secure EFI boot
diskutil umountDisk "$DISK" #to make sure it's forcibly unmounted
MY_OPTIONS="+ssse3,+sse4.2,+popcnt,+avx,+aes,+xsave,+xsaveopt,check"
ALLOCATED_RAM="8G" #GB
CPU_SOCKETS="2"
CPU_CORES="4"
CPU_THREADS="4"
args=(
-m "$ALLOCATED_RAM"
-vga virtio
-display cocoa #default,show-cursor=off,gl=es
-usb
-device usb-tablet
-smp "$CPU_THREADS",cores="$CPU_CORES",sockets="$CPU_SOCKETS"
-drive if=ide,index=2,file="$DISK",format=raw
-machine type=q35
-accel hvf
#-drive file=/Volumes/OSes/win/21H1.iso,media=cdrom,index=0
#-drive file=virtio-win-0.1.208.iso,media=cdrom
-nic user,model=virtio
-rtc base=localtime,clock=host
-cpu Nehalem,hv_relaxed,hv_spinlocks=0x1fff,hv_vapic,hv_time
-device intel-hda
-drive if=pflash,format=raw,readonly=on,file="$OVMFDIR"/OVMF_CODE.fd
-drive if=pflash,format=raw,readonly=on,file="$OVMFDIR"/OVMF_VARS.fd
-boot c
)
qemu-system-x86_64 "${args[#]}"
Make sure you download the win-virtio drivers if needed.
Files needed for enabling secure EFI boot can be downloaded here.
Credits:
Kholia's detailed GitHub project.
Hikmat Ustad's amazing video tutorial.
My setup is complicated and I think I have a clear way ahead, but please let me know if you see a better way to accomplish my end state of using a terminal window over Xbee. My use case is that RPI #1 has internet connectivity, but RPI #2 does not, and I want to fully control and access RPI #2 via RPI #1 over Xbee.
I have x2 Raspberry Pi 3B+ and am using x2 Xbee Pro S3B modules to communicate between the RPIs over Xbee USB Development Shields. The Xbees show on the RPIs as /dev/ttyUSB0. I want to use the Xbees as a transportation layer to the RPIs, much like 802.11/15 or plain old ethernet would be used in a headless situation with bash. The Xbees are running at 115200 baud rate, and are named and setup via the X-CTU tool. I have no illusions of high speed data, but want to "see" RPI #2 terminal on RPI #1, the same as when SSH is accomplished with traditional transport layers.
I am able to use the Xbees in Transparent Mode, and send plain text with Screen, Minicom, "echo "text here" > /dev/ttyUSB0", and "cat < /dev/ttyUSB0". Despite the ability to pass messages, I want to use these plain text messages as bash input. For example, when I pass the command ls via any of the three methods listed from RPI 1, I want to have bash exectue "ls" on RPI 2, not just see it listed on the screen for RPI 2.
I've found several tools for Xbee, but don't want to wire up the GPIO pins and go that method; I want to use the Xbees as simple transport, nothing more. How do I pass text from /dev/ttyUSB0 to bash as a command, and see the results? Short of a more direct route, I'm considering using crontabs and an executable file that is erased and re-written to accomplish this task, but feel that is a last, very ineffective, method.
Is there some tool I am missing that does this already? Can I "screen" over a serial port as command line and serial I/O simultanously?
I found pyserial, which could allow for a TCP binding to the /dev/ttyUSB0 port, but am not sure if that is the right way to go or not. As of now, my code is as simple as
RPI #1:
echo "ls" > /dev/ttyUSB0
RPI #2:
cat < /dev/ttyUSB0
I was able to send and recieve commands from command line of a local (although remoted) XBee host to a remote (secondary, off net) Xbee host. I found the answer when I started looking at how serial devices could open a login terminal, and arrived at the getty tool. Here are my setup instructions for Transparent Mode use, I am still trying to get python-xbee and other tools to work to allow for the same concept, but via API mode. Note that the below instructions are a 95% solution, but should get the common user to a solid way ahead. I am not the original author of the steps below in their format, but found each step and combined them through various other Q&A forums to arrive at a solution:
First, acquire Digi Xbee X-CTU software (does not install on ARM devices such as Raspberry or Odroid):
XCTU:
Install from the following Digi.com link, but navigate to the corrresponding software FTP link:
https://www.digi.com/support/productdetail?pid=3352&type=drivers
Linux 64 Bit: ftp://ftp1.digi.com/support/utilities/40002881_R.run
Linux 32 Bit: ftp://ftp1.digi.com/support/utilities/40002880_R.run
Windows: ftp://ftp1.digi.com/support/utilities/40003026_T.exe
Mac: ftp://ftp1.digi.com/support/utilities/40003026_T.exe
Install X-CTU Via:
sudo wget ftp://ftp1.digi.com/support/utilities/40002880_R.run
sudo mv 40002881_R.run xctu_64bit.run
sudo chmod +x xctu_64bit.run
sudo ./xctu_64bit.run
Find X-Bee Device:
make sure Xbee is not plugged into a hub, power will be too little, recognizable via the below error, YMMV:
dmesg | grep ttyUSB0
and returning error: [ 228.800021] ftdi_sio ttyUSB0: failed to get modem status: -32
lsusb -v -d 0403:6001
sudo nano /boot/cmdline.txt
change the console tty device from AMA to USB, then for the kgdboc, which allows the remote end to watch the boot process, add/make match as appropriate
console=ttyUSB0,115200 kgdboc=ttyUSB0,115200
sudo nano /etc/inittab
make sure to uncomment (remove #) if present, change tty from AMA to USB
T0:23:respawn:/sbin/agetty -L ttyUSB0 115200 vt100
On Ubuntu x86 system, use X-CTU via
sudo ./XCTU.desktop
update firmware to the latest version
currently 8075 for the Pro S3B, then set baud rate to 115200 on each device
other xbees on in the vicinity can be updated by using a local xbee via X-CTU, then setting the api mode to “api mode with escapes”. Note that Transparent Mode should be used unless you have an indepth knowlege to make API mode work. I started with Transparent Mode to demonstrate the below works, but have since moved to API mode to gain the enhanced send-recieve control capabilities (pending a working version as of this writing).
do the same steps for all the devices that will be used on the network; once the local device is complete, other remote devices can be updated if visible (close enough).
Close out X-CTU and add the current user to the dialout group via:
sudo usermod -a -G dialout root
reboot then:
Setup Minicom Via:
sudo aptitude install minicom
minicom -s
serial port setup
a, set to /dev/ttyUSB0, then hit enter
e, set baud rate to 115200, then hit enter
hit enter again to close the window and arrive at the configuration page of minicom
select to save as dfl, followed by enter
then move to exit, and hit return
test connection to a locally connected device via
three plus symbols without hitting return
if it replies “ok” in a few seconds or less, all is well
OR Screen:
screen /dev/ttyUSB0
again, if you see a login prompt, you are connected. Note that screen is probably the best choice for most users; it has the inherent quality of ease of use (when compared to Minicom), handles low bandwidth connections with ease, and stays alive despite a disconnect from remote host. Ctl+a and then k will disconnect.
Install Coreutils to add more options than Minicom (Screen is also advisable):
sudo aptitude install coreutils && screen
stty -F /dev/ttyUSB0 -a
this will check serial port capabilities and settings
Communicate with your devices:
Note you interact with your network on a local machine with an X-Bee plugged in, or on a remote device you SSH over the internet, as long as it has an X-Bee attached. Also, note that the below settings to rc.local weren't keeping my settings after a reboot; this is a work in progress. I was setting them manually until I got automation worked out.
Also, I added rc.local to the RPI manually, the how-to for that is out there somewhere:
sudo systemctl stop serial-getty#ttyAMA0.service
sudo systemctl disable serial-getty#ttyAMA0.service
sudo systemctl enable serial-getty#ttyUSB0.service
sudo nano /etc/rc.local
add the below before exit 0
The stty line is twice because it has been noted that the first instance changes the reported baud rate to 9600, the second to 115200. If you are doing this manually, do a “stop” then re-do the start command to receive the prompt. This could be automated; I will update this post with a process monitor.
stty -F /dev/ttyUSB0 speed 115200 cs8 -cstopb -parenb raw
stty -F /dev/ttyUSB0 speed 115200 cs8 -cstopb -parenb raw
sudo systemctl start serial-getty#ttyUSB0.service
Then, use Minicom, Screen, or "cat" and "watch" to view messages sent. When using Minicom you will receive a login prompt via the above directions. As previously stated, I am still trying to get this working smoothly for API mode, but at least I know I have connectivity and can do basic command & control via the command line remotely with Transparent Mode, including running command line programs and commands. Transparent Mode does not offer any enhanced RF propagation correction techniques, hence my desire to get API mode working; RSSI values and error correction would be nice.
I've tried to run my first objective-c code in Xcode... Compilation process was successfully, however an error returns " invalid host string: 'localhost' ".
After some Googling, I found out and connected the points that it might had something to do with the hosts file I recently deleted.
Now I cannot recreate the /etc/hosts through terminal using:
sudo cat >/etc/hosts <
#
Host Database
#
localhost is used to configure the loopback interface
when the system is booting. Do not change this entry.
#
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%1o0 localhost
EOD
sudo: /private/etc/sudoers is mode 0666, should be 0440
Thanks in advance for any workaround.
You have broken your system by making inappropriate changes.
First, you need to fix the permissions on /etc/sudoers. You might try opening Disk Utility, selecting the system volume, and clicking Repair Disk Permissions. I am not sure that will change the sudoers permissions. If it does not, reboot your system and immediately press and hold the Command and S keys. This boots to single-user mode. When the command prompt appears, enter these commands:
mount -uw /
chmod 0666 /etc/sudoers
reboot
When the system boots, your sudo command might be working again, if you have not otherwise broken it. At this point, you may be able to recreate /etc/hosts. In addition to restoring its contents, you may need to set its ownership and permissions:
sudo chown root:wheel /etc/hosts
sudo chmod u=rw,go=r /etc/hosts
You could also restore /etc/hosts while in single-user mode, rather than booting normally and using the sudo command. Before the reboot command, use cat (or cp to copy from a file you prepared previously) to recreate /etc/hosts, then execute the chown and chmod commands (without sudo), then reboot.
I cannot guarantee these commands will suffice or that there are no errors; diagnosing problems such as this remotely is troublesome.
Stop tinkering with your system without making backups that you know work or taking other steps to be able to revert your changes.
I'm attempting to create an automated bash script that fills up a file with urandom in the unit's flash storage. I can manually use all of the commands to make this happen, but I'm trying to create a script and having difficulty figuring out how to check for the usb device. I know that it will be either sda1 or sdb1, but not sure if the code below is sufficient ...? Thanks! Below, is the code:
if /dev/sda1
then
mount -t vfat /dev/sda1 /media/usbkey
else
mount -t vfat /dev/sdb1 /media/usbkey
fi
The way I script mountable drives is to first put a file on the drive, e.g. "Iamthemountabledrive.txt", then check for the existence of that file. If it isn't there, then I mount the drive. I use this technique to make sure an audio server is mounted for a 5 radio station network, checking every minute in case there is a network interrupt event.
testfile="/dev/usbdrive/Iamthedrive.txt"
if [ -e "$testfile" ]
then
echo "drive is mounted."
fi
You can mount by label or UUID and hence reduce the complexity of your script. For example if your flash storage has label MYLABEL (you can set and display VFAT labels using mtools' mlabel):
$ sudo mount LABEL=MYLABEL /media/usbkey