Personally I would recommend starting with a fresh image. Backup the current image of your sd card to your computer (google how if you need help) you can always go back to it.
With a fresh image you will be sure not to have any other weird artifacts such as you already have with the pdf.
As for the pdf itself, are you sure it's being displayed at boot, or ...
The answer was simultaneously subtle and obvious: Because I was booted into the SD card's operating system at the time, I was editing the the /etc/fstab on the SD card and not on the hard drive. This explains all the phenomena I was seeing:
The system fscking the filesystem and then failing to boot? The /etc/fstab on the hard drive was still mapped to the ...
If you booted unmodified Raspbian and it stuck at rc-local.service then your Raspberry Pi or your SD Card is broken. Try another RasPi or another SD Card. Use another flash program. Verify checksum of the downloaded Raspbian image.
Just download a new OS (which will have changed since whatever you are using) and install it. Seeing as you don't know what is on it there is nothing to lose.
One place to look for the autoboot sequence is in the /etc/systemd/system folder where you will find files with a .service extension. If the system was setup to display a pdf, you will see it among other services that are enabled to startup when the RPi boots. You will have to determine which service is auto-loading the pdf by executing the following command ...
I don't know what a CrowPi is or what version of Raspbian it is based on.
The config.txt file explains WHY the pins are outputs.
# SPi Related configuration
This sets GPIO 16, 17, 18 as outputs
Info: Enables spi1 with three chip select (CS) lines and associated spidev
dev nodes. The gpio pin ...
You have 3 options
1 use dd (which requires identically sized disks and copies everything)
2 use the SD Card Copier utility on the Pi (the ssd needs to be mounted on the Pi and can be slow as it does a file copy)
3 use rsync (on any Linux computer)
You can try to just copy the image of the source SSD to the destination SSD. The destination SSD must have at least exactly the same size than the source SSD, better a bit more to be on the save side so the image from the source will fit onto the destination. If it doesn't fit you will see it only at the end of copying after hours.
Just attach both SSD to ...
The ONLY thing you have to do is include in /boot/config.txt:
DO NOT fiddle with the software or attempt to manually synchronise - it all happens AUTOMATICALLY.
PS a DS3231 is NOT a ds1307 although they both use the same driver.
Without code it is unclear what you expect to get from the temp sensor which is principally for ...
When you resize a partition using a partition manager like gparted it may be possible that it silently changes the PARTUUID of the disk. But this is used by Raspbian to address the boot- and root-partition in /boot/cmdline.txt and in /etc/fstab. You should check if the entries in these files still match the actual settings of your disk.
Because of this ...
There are many reasons for the issue. I solved my problem, which is equivalent but maybe not the same with:
Edit the cmdline.txt and make sure you have: fsck.mode=force fsck.repair=yes
This from: Raspberry Pi 3 and Raspbian Jessie - How to run fsck at boot?
(you need a full setup with monitor and keyboard on the pi)
If it works, fine. In my case I did ...
Okay, I fixed it. Apparently, my (very old) Sony Bravia monitor was the problem. Having tried it on a newer monitor, the whole thing works perfectly.
No settings changes were needed on the Pi. Same cables, different monitor.
I hope this helps someone!
To manage to start programs you should use systemd Unit files. Because we don't know anything about your specific needs I can only give a general idea. Here is a very simple template you can use to start to solve your problem. Create a new service with:
rpi ~$ sudo systemctl --full --force edit yourstartup.service
In the empty editor insert these ...
As you can see at the Release notes on date: 2019-06-20 that this is supporting Buster. Versions before will not do it. You can try to "copy" modules, driver and firmware from that version to the Alpine Linux distribution as you already tried, but I don't believe that you will have much access. We have seen similar with Ubuntu on upgrade to RPi 3B+. I'm ...
For other people looking for this issue - solution in my case was hidden in video configuration file. When using the HDMI to VGA converter boot configuration file (/boot/config.txt) must contain proper entry of hdmi_group and hdmi_mode in order to work with every startup.
My suggestions are as follows:
Since you are running the script as a cron job, the PATH environment variable is not set, so the Python interpreter cannot be found and the script fails to run.
As your script already has #!/usr/bin/python3.7 on the first line, and assuming the path is indeed correct on your platform, then there is no need to prefix the ...
According to this site you may need to change your first line from this:
The first line in my working script is this:
ETA: OK, you've tried this and it's still not working. My working script is launching from rc.local, and I've caught another difference. You've put this in ...
Debian is able to upgrade to a new version but it is not an easy task for the upgrade procedure. It has to decide how to upgrade options you have modified and/or set. If it doesn't know it will ask you what to do. Usually it will present the old configuration as default but it may not be always the best decision. This also implies that you will not get ...
A rather straightforward approach would be:
flash your original (old, no modifications) image to a spare SD card
diff between the no-modification image and your current image
flash the new image (again, no modifications) to the spare SD card
apply the changes you've done to the old image to the new image with patch
If you don't have the above-mentioned ...
Supplying 5.5V to a Pi should not cause damage, although it is inadvisable. See https://raspberrypi.stackexchange.com/a/99653/8697
Test the voltage on Pin 1 (3.3V) - if this is absent the Pi is dead. NOTE be careful to avoid accidentally shorting 3.3V to any other pin - this is invariably fatal!
PS Measuring anything on a Pi with a multimeter on the ...
The author of that tutorial does not use the default Raspbian Buster Lite image. Default Raspbian is a 32 bit version. You should use the image that the author used and if there are problems you should also ask the author. It has nothing to do with default Raspbian.
So you doesn't have power on the 3.3V.
You may have made a shortcut, and fried the 3.3 power supply regulator. One way of trying to be sure of that (and verify the CPU), would be to power the board with an external 3.3V power supply (of good quality)
So remove all the wire who may have started the problem, and try to boot the board this way…
If the power ...
I can offer an alternative solution.
Instead of renaming the initramfs-image and modifying the existing /etc/kernel/postinst.d/* files, I added an initramfs hook that modifies /boot/config.txt so that it will load the initramfs with its current name.
Therefore, there is no need to rename the initramfs any longer after creation, and it can use the standard ...
I'm assuming your using Raspbian Stretch with Desktop or Raspbian Buster with Desktop.
Edit the autostart file using:
sudo leafpad /etc/xdg/lxsession/LXDE-pi/autostart
Autostart file should look similar to:
@lxpanel --profile LXDE-pi
@pcmanfm --desktop --profile LXDE-pi
Add your 4 Python programs to the end using @...
On recent versions of Raspbian, you can use a cron job for this.
Run crontab -e and select your favorite editor when prompted, then add the following to the bottom of the file:
using /etc/fstab is the proper way of doing this.
if you do not want your system to depend on the drive on startup in case the usb drive is missing you have to set the relevant parameter / options
from man fstab
nofail do not report errors for this device if it does not
so your fstab should have an entry like this:...
I had a customer who was using many raspberry pi 2. Those were booting from the sd card. 2-3 years ago he started having issues with corrupted sd cards.
I then decided to change the boot location from the sd card to the usb stick. The pro was that even if a usb stick failed, you wouldn't have to dismantle the machine to get access to the sd card. You just ...
Actually you do not need to "revert" from anything. The SD / TF slot will be still functioning as usual.
The OTP procedure will allow other boot options ( read: USB ) but it is AND, not OR.
SoC checks bootcode.bin on the SD card first. If not find proceed to USB.
So basically just taking out the USB and putting a TF in the slot will make the pi boot as ...
I continued my research and found an answer that works for me. There is a DiscoverableTimeout on /etc/bluetooth/main.conf which is, by default, set to 300s.
I just add DiscoverableTimeout = 0 on this configuration files.