I guess your image is OpenELEC as @Lawrence said that. OpenELEC uses squashfs compressed image filesystem so you can't edit without uncompressing.
To uncompress it, convert your sd-card content into image with dd command in another computer which runs linux.
dd if=/dev/mmcblk0 of=/tmp/openelec.img
Then install squashfs-tools to get compress/uncompress ...
Have a look in /var/log/syslog and see if you can find some indication of why. If the filesystem is mounting read-only, the last thing in that file will be whatever happened when it was still read-write, since the system cannot log there otherwise. Which may or may not be helpful...
The kernel's own log is in memory, however, and does not require a ...
Linux kernel is caching disk operations. That means data is written not in real time, but when it is "time to do it".
There could be two reasons of behaviour you described:
1. Your SD card (or disk) is not fast enough to receive all the data you are producing.
2. Once in 30-40 seconds kernel is 'flushing' it's disk buffers, which unluckily freezes all disk ...
Turns out it was some sort of OS glitch or incompatibility. I ran the following commands overnight and it fixed the problem
sudo umount /dev/sda1 # /dev/sda1 is the name of my external drive partition
sudo fsck -Cy /dev/sda1
I just installed OpenElec on a Pi 3, and it puts the partition that is normally mounted as /boot on other distributions as /flash.
OpenELEC:~ # df | grep p1
/dev/mmcblk0p1 524008 151736 372272 29% /flash
As you say, it is mounted by default as read-only.
OpenELEC:~ # mount | grep flash
/dev/mmcblk0p1 on /flash type vfat (ro,noatime,fmask=...
You can do this very easily with a shell script:
echo "$now $*" >> $LOGFILE
while true ; do
writelog "Exited with status $?"
If you really want to use python:
import time, subprocess
This is most likely because something (by the looks of that command it is the BASH shell and SFTP-Server) is/are accessing the root filesystem. During boot nothing is accessing anything in / yet, so it can be set to read-only.
However, once boot-up is complete, some software may want a lock on the filesystem or some files are being changed within. Obviously,...
If you still can not unmount or remount your device after stopping all services and processes with open files, then there may be a swap file or swap partition keeping your device busy. This will not show up with fuser or lsof. Turn off swapping with:
sudo swapoff -a
You could check beforehand and show a summary of any swap partitions or swap files with:
If the pi is working properly, SD card corruption should never happen regardless of whether the card is rw or ro (at least until the card is worn out, which would take quite a long time). The exception would be pulling the plug suddenly on a busy system, in which case a rw filesystem will be more vulnerable. Since you have decided to do that regularly, ...
This could be a problem with your SD card. I've had a Scandisk cards suddenly die. When it died it went into read only mode "to protect your data from loss". It's plausible your SD card has done the same.
If it's an old RPI (using a regular SD card) then double check the read/write switch on the SD card.
Try placing the card into another machine. If ...
Assuming you are no longer talking about logs in particular.
Have a look at /proc/diskstats. If you cat /proc/diskstats you will see statistics for various devices.
Each device has 11 entries as follows.
Name units description
---- ----- -----------
read I/Os requests number of read I/Os processed
I suspect your issue is that you are mounting the vfat filesystem so that it is only accessible to the root user.
The vfat filesystem (being a very simple filesystem dating from the ancient days of DOS) has no concept of users and groups, but all files in UNIX systems must have an owner and group. To work around this, the Linux vfat driver defaults to ...
Assuming we're talking about the hardware UART here, although that is not the default behaviour for the Pi 3 where
the PL011 UART is connected to the BT module, while the mini UART is used for Linux console output..
see here and here for how to fix that.
As for the hardware buffer: a minor problem - no official datasheet is available for the Pi 3's ...
Since it seems that your /etc/fstab is missing, you may want to fill it in with the necessary information. You'll need to manually mount the root and boot partitions first:
sudo mount -o remount,rw /dev/mmcblk0p1 /boot
sudo mount -o remount,rw /dev/mmcblk0p2 /
And then create a new /etc/fstab
sudo echo -e "proc /proc proc ...
Your root filesystem on your SDCard partition #2 (/dev/mmcblk0p2 - device 179,2) is in need of a fsck and the system can't run that automatically.
You'll need a new SDCard, a copy of plain Raspbian and a USB SDCard reader. Or you'll need a laptop running Ubuntu or Mint that has an SDCard reader.
If doing it on a new SDCard, get Raspbian written to the new ...
It looks like you have the mount permissions as read/write for root but only read for anyone else. I think you would need to set the permissions on /media/HDD to be writeable for the walter user or the users group.
sudo chown -R root:users /media/HDD will set the group permissions to users (I presume this exists?) or sudo chown -R walter:users /media/HDD ...
You can certainly read multiple bytes using read.
The comments about FIFO are misleading, even though they are important to ensure high speed troughput, are inaccessable.
The kernel drivers almost certainly provide buffering, but again this is inaccessable. (In the 1970s I wrote my own drivers which used a 256 character circular buffer.)
The following ...
I have also asked this question Why is the green LED (ACT) blinking without SD card activity also at the Raspberry Pi Forum and received this answer:
by rpdom » Wed Feb 22, 2017 8:02 pm
From what I understand, the Pi sends a "status" request to the card every few seconds to check that it is still there and working. That will cause the LED to flash, ...
Thank you @JOAN for clearing things up.
need to send 1st byte as command, and then shift out another 8 bits to get my return data. here are two functions that are working for me
address = 0x80 | regAddr
resp = self.spi.xfer2([address,0x00])
Yes there are logs, most should be under /var/log.
Use the command ls /var/log -lrt to get a reverse time ordered list of files in that directory.
You can tune some logging with the file /etc/rsyslog.conf. If you want to disable as much logging as possible add a line with *.* ~ just after the #### RULES #### comment block.
Not all logging may be ...
Various people have some read/write benchmarks of various SD cards on the pi here. Notice that the read speed maxes out no matter what at around 20 MB/s, and the write speed will not be higher. That's a limitation of the pi's SD card reader. It is worth noting because it means there's no point in very high performance cards; you can get the 20 MB/s read ...
In bare metal programming you are in control of the hardware. You decide how you want memory to work and you decide if you want to program the memory management unit(s) to use virtual addresses.
Terms like kernel space and user space are meaningless for bare metal programming.
The mmap function is only relevant if your program is running in a Linux (or ...
I am not a big fan of SD cards. I have had several go bad on me. I have had success using a USB Flash drive instead. You still need an SD card for the boot partition, but you can write protected it and use the USB for your filesystem. Here is a tutorial and another one here.
Basicly you need to do the following:
Back up your SD card and flash the image ...
I was banging the same wall for a long time, until I found this: https://wiki.debian.org/ReadonlyRoot#Find_processes_blocking_the_remount_readonly
When lsof and fuser do not show any files opened for writing on / (which seems your case), there could still be processes that have opened files that were deleted since, and they are blocking the remount.
On many SD cards, there is a switch prohibiting write access. If it is off, switch it the other way to disable write protection.
If the switch is not to blame, I would advise following the advice here for rescuing.
Is the file in the same directory as app.py? There are a couple of gotchas about running from a file manager.
Consider the following trivial program, living on my desktop:
print "Working directory: ", os.getcwd()
If I run it in the terminal like ./pytest.py (after doing cd Desktop), I get: