After alot of research I could fix my Problem with usbmount:
Adding ntfs to usbmount
Install usbmount with sudo apt-get install usbmount.
Install NTFS driver package ntfs-3g with sudo apt-get install ntfs-3g.
Configure usbmount to mount specified filesystems by opening the usbmount file with sudo nano /etc/usbmount/usbmount.conf.
In here there is a line ...
First, why it doesn't boot? What do the lights show? Debug it with this wiki
The problem might be in the FAT partition, that can be easily recovered by reformating and put back the files (Using either your image or one downloaded from the web.)
If it's the Linux filesystem, loading it on a Linux (even a liveCD) and running fsck might be enough to recover ...
Both of the other answers are correct and will let you view and study how the file works. However, with the idea of teaching you to fish rather than give you a fish, if you do the following it will help you find any file on your system.
sudo find / -name 'raspi-config'
Breaking it Down:
sudo tells the system to run this command with root privileges - this ...
The Hard Way
Read my other answer on Is it possible to update, upgrade and install software before flashing an image?.
You need to calculate the offset of the filesystem you wish to mount.
The Easy, yet experimental way
Consider using my new utility piimg. Just build and run
$ sudo ./piimg mount archlinuxarm-13-06-2012.img /mnt
NOTE This hasn't been ...
Looks like this is going to be part of the newest updates; Desktop & Lite versions:
When flashing a new Raspbian image, the file system will automatically be expanded to use all the space on the card when it is first booted.
On Ubuntu you can edit the image to stop auto file system expansion.
raspi-config is POSIX shell script and fairly easy to read if you understand shell scripting; on Raspbian it's in /usr/bin, and runs via an init service the first time you boot, but is kept updated thereafter. The version I'm referring to is from a Raspbian jessie system and was last modified August 10/2016.
Can somebody tell [me] what the Expand ...
EXT2 (2 TB limit & non-journaling)
I would go with this since you most probably want a lower power system for logging.
EXT3/EXT4 (disable journal for more writes)
EXT4 has more performance than EXT3 but EXT3 uses less power.
tune2fs -O ^has_journal /dev/sdbX
/dev/sdbX /dir/ ext3 defaults,noatime 0 ...
It's even lower level than what @Milliways describes, the entire card including all partition information is not erased but overwritten. It doesn't matter if the card used to be FAT32 or NTFS or ext4 or just gobbledygook from /dev/random, afterwards it will contain the image data in whatever partition is used.
Any data that is on the card after the size of ...
The system is intended to log data to a FAT32 USB stick, which may be unplugged, replugged or replaced at any time.
The unplugged part of that is problematic. AFAIK, no computer system anywhere promises you the right to yank a USB stick out unannounced at any point without potential problems. So you will have to think about how to get around that.
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 ...
You make a lot of assumptions. The statement about 1 month is just flat-out wrong.
Compact flash cards are actually worse for this kind of operation than SD-cards. I tried to install a server onto one which lasted a whole three weeks before dying. Compare that to the server I have running on an SD card on the pi for over 3 months now 24/7. But no, there ...
It is possible. And I am running my pi with it.
[root@rasp-rodhome ~]# grep jffs2 /proc/mounts
/dev/root / jffs2 rw,noatime 0 0
[root@rasp-rodhome ~]# cat /proc/version
Linux version 3.19.0-rc7.17.rf (email@example.com) (gcc version 4.7.1 20120402 (prerelease) (crosstool-NG 1.15.2) ) #3 Sun Feb 8 21:14:52 BRST 2015
However, first, a big fat red note:
dd command, when used correctly, OVERWRITES all partition information along with the partition formats and everything else you might put on SD card. therefore, it does not matter, how SD card was formatted because it's going to be overwritten anyway.
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 ...
You should take into account on which OS you want to read the data. Then, you have to decide whether you want to support journaling or not. Take into account that with journaling:
lower performance at write time, since there is the extra work of the journal
increased chance of damaging the flash memory due to extra use of the journal causing wearing
Yes. SD cards are volatile, and, as all memory does, will deteriorate over time. Nothing you really can do about it besides not use the device. This is because of the need to be small, the technology isn't quite as long lasting as a Hard Drive or SSD/RAM. Basically, all memory will deteriorate eventually, it just depends on the use it is put through.
People are commonly confused by the difference between three distinct things:
A random access block storage device such as an SD card (or HDD).
A storage partition which is a section of a device; there may only be one which occupies pretty much the whole device.
A filesystem which is something used to organize the data on a partition.
The significance of #...
I doubt that swapping the SD card for another solves the filesystem corruption issue. The following citation from Do journaling filesystems guarantee against corruption after a power failure? pretty much highlights the issue:
There are no guarantees. A Journaling File System is more resilient and is less prone to corruption, but not immune.
There is no point in you formatting the card. The raspbian image contains 2 partitions, one small vfat and one larger ext4. You just follow the instructions and write that image directly onto the card.
To reiterate: DO NOT format the card and then copy the image in as a regular file or something. That is not how it works. The image contains two ...
Yes, the most obvious and straightforward way is to mount them under linux, where ext4 is the native filesystem. Keep in mind that the raspberry pi is not actually the focus of the linux world -- not including android (which uses the kernel), between 1-5% of PCs (desktops, laptops, etc), 30-40% of web servers, and 95% of the world's supercomputers run some ...
In addition to mounting the ext4 partition of the SD card as @goldilocks suggests, you should be able insert the SD card into any Windows machine and edit cmdline.txt in the vfat /boot partition (which should be directly available to Windows) and add the following parameter to the line that is already in that file:
According to this posting, ...
This is because Raspbian uses multiple partitions. Two of those partitions are the BOOT and RECOVERY partition, those are not the ones that contain your files, like your home directory and your desktop. The partition that contains those is formatted in EXT4 which is not readable by macs (by default), so it doesn't show up on your mac, even though it is there....
According to the Debian Wiki:
staff: Allows users to add local modifications to the system (/usr/local) without needing root privileges (note that executables in /usr/local/bin are in the PATH variable of any user, and they may "override" the executables in /bin and /usr/bin with the same name). Compare with group "adm", which is more related to ...
I found what I believe was the cause, and it now appears to be fixed.
Since this machine has a battery-backed RTC on it, fake-hwclock had been uninstalled long ago. When looking at the dump from 'journalctl -xb' I noticed the timestamps were all from several months back (about the time the machine was made, perhaps), and then didn't jump to the present ...