Hi all, today we had a small blackout and my SD card is a damaged a bit...
- it boots, I can log in, but I can't install anything, due to this error:
Error: Unable to read file „/var/lib/dpkg/triggers/File“: Input/output error
I believe that I'm not first one with this problem, but can it be solved without reflashing whole SD card with new image?
Any suggestions?
If I posted something helpful, please rate +
If you have another gnu+linux system you can mount the SD card there, and then run fsck on the partitions; sometimes (please don't hold me feet to the fire) the damage can be repaired, even though there might still be some data loss.
Honestly though, the best thing to do is to back-off (back-up) an user data you can, and then reflash the SD card.
marcushh777 
please join us for a chat @ irc.pine64.xyz:6667 or ssl irc.pine64.xyz:6697
( I regret that I am not able to respond to personal messages; let's meet on irc! )
=) Thx, it found smt, but doesn't fixed that problem with installation, so I reflashed from backup... What must be done, to have a /boot and some other partitions read-only to make it resistant to sudden shutdown? Is it possible on Ubuntu?
If I posted something helpful, please rate +
Of course, like in any Linux or unix.
Simply edit the mounting flags in /etc/fstab to mount some partitions in RO.
08-06-2016, 01:05 PM
(This post was last modified: 08-06-2016, 01:07 PM by MarkHaysHarris777.)
Another thing that some of us are experimenting with is building a card (manually of course, which takes a particular set of linux skills) that has multiple partitions for the various parts of the filesystem (current linux images have two, /boot mmcblk0p1 and the rootfs partition mmcblk0p2).
There should actually be about 10 partitions; and the filesystem should be mounted on them like so:
/boot
/
swap
(extended, part 4)
/usr
/opt
/usr/local
/var
/tmp
/home
Usually when corruption occurs it is going to occur in either /var or /tmp (sometimes /home, but not usually). Almost never does /boot, or / get clobbered. /var and /tmp are easily rebuilt without reloading the entire card. The downside of this is that at this time there is no automation to construct these cards, and you have to know what you are doing.
I am toying with providing a service on-line to Pinesters who might like to purchase SD cards at a nominal rate, through paypal, and I would send out a preformed SD card , fully partitioned , and preloaded with the gnu+linux distro of choice; thinking of providing the dbian, ubuntu, and Gentoo images.
We'll see. In the mean time, dive in and give this a try. Partitioning an SD card is no more difficult than partitioning a disk drive.
PS Some of the partitions can be mounted RO; but, the most important of these is the /home part... it can be mounted noexec and nosuid. This gives an additional layer of security. Also, note that I placed /home at the end. That way whatever space is left on the card (after you assign /usr and /opt for software) can be expanded in user space which is of course your home directories.
marcushh777
please join us for a chat @ irc.pine64.xyz:6667 or ssl irc.pine64.xyz:6697
( I regret that I am not able to respond to personal messages; let's meet on irc! )
Ok, if I understand correctly, there is no problem with RO system, but current image is not suitable for it. So if I find some image creator to rebuild existing image to more partitions and than set to most of them RO. I know, that setting RO permission to /home, /usr/local, /tmp is not good idea, but what about rest of them?
And if I add noatime parametr to fstab, it also lower chance of card damage?
If I posted something helpful, please rate +
08-06-2016, 05:02 PM
(This post was last modified: 08-06-2016, 05:04 PM by MarkHaysHarris777.)
(08-06-2016, 03:19 PM)TeaPack Wrote: Ok, if I understand correctly, there is no problem with RO system, but current image is not suitable for it. So if I find some image creator to rebuild existing image to more partitions and than set to most of them RO. I know, that setting RO permission to /home, /usr/local, /tmp is not good idea, but what about rest of them?
And if I add noatime parametr to fstab, it also lower chance of card damage?
No, no, you are going down the wrong road.
... making RO filesystems is only a good idea for embedded systems that just need to control but do not need persistent data... a user system usually always needs persistent data, so RO filesystems don't usually work there.
The correct solution for the corruption problem is "don't allow your system to be removed suddenly from the power supply" <-----
All of my systems are on UPS. In fact, the systems throughout my house are all UPS'd
We have too many storms and the power company here maintains stuff like its 1960... so, I just put UPS in everywhere... I don't have interruption or corruption problems.
My main lab has a UPS on the primary mains circuit for that room...
Those are just some ideas. The other solution which is cheaper, is to backup your SD card frequently. its just the reverse process from building the card in the first place... just use DD and write the card out to your linux PC, and then compress the image with gzip. Then run it through shasum , or md5sum, to get a valid checksum and keep several of those backups ... if you lose your SD card, just write out another one and keep flying...
marcushh777
please join us for a chat @ irc.pine64.xyz:6667 or ssl irc.pine64.xyz:6697
( I regret that I am not able to respond to personal messages; let's meet on irc! )
So If I'll connect battery to Pine, I can use it as "internal" USP =) But what about jumper next to EXP bus? Should I switch it to BAT, or let it be on external DC when BAT will be used only as backup? I can't find that jumper in schematics, but it looks like PMIC is switching source automatically....
If I posted something helpful, please rate +
08-07-2016, 07:35 AM
(This post was last modified: 08-07-2016, 07:39 AM by xalius.)
The jumper is to select if the 5V for the USB ports and headers are generated from the DC-Input or the battery supply. So if you want to use the battery more as a backup supply, probably leave it on BAT so the 5V dont disappear if DC-Input fails (if you have USB devices attached), but that will constantly drain the battery probably, and if the drain is greater than the charge current, it will also empty it maybe...
I was planning to add a small switch circuit on top of my jumper block so it automatically switches over the 5V to BAT if DC-IN is not available, but the schematics for the 2GB board is not released yet, so I'll wait a bit there...
|
