New answers tagged

1

25 seconds was the difference between the POSIX-compliant tz zones and the "right" tz zones during the interval 2012-07-01 until 2015-07-01. If the tzdata is that old and if default time zone for the shell running this command is a POSIX CET and the "-u" time zone is a "right" version of UTC then the "right" code will assume that the system clock violated ...


0

A few tricks can be used to reduce the size of libraries. I always perform this step before removing executables from the system. Remove library profiling data to save ~56Mb: rm /target/usr/lib/lib*_p.a Strip symbol tables from shared objects: strip /target/usr/lib/lib*.so.* For instance libc.so.86.0 amounts to 3Mb, while only 750kb stripped. This ...


2

By following the strace of the first command (date): open("/etc/localtime", O_RDONLY) It access the timezone file pointed by /etc/localtime which is /usr/share/zoneinfo/europe/Zurich in my case. So everything fine so far. The strace of the second command (date -u) gave me hints why it wasn't working properly: open("/usr/share/zoneinfo/UTC0", ...


0

The cases where you do see resizing are likely telnet or ssh-connections where NAWS (negotiate about window size: RFC-1073) is supported. A serial connection doesn't do that. It is a direct connection. As a workaround, you can run the resize program, like this: resize Further reading: resizable serial console window?


0

I think your issue is network related 99% but, just to consider 1%... Is your OS running on flash memory? I had similar issues when working on usb and sdcard based installations. Sometimes system got unstable, remounted RO and one of first symptoms was unsuccesful ssh connection, with same error output. When i had the luck to keep an alive existing ssh ...


3

If your hardware is not physically secure, nothing you do in software will give you physical security. Don't bother encrypting unless you have a separate, secure location for the key. Full disk encryption on a computer is useful when someone types in the (password to derive the) key at boot time. Full disk encryption can also be done if the key is on a ...


0

Sounds like good news to me. Less code is better code. #!/bin/sh # exit if any command fails set -e CARD_DEV=$1 if [ ! -b "$CARD_DEV" ] ; then echo $CARD_DEV is not a block device exit 1 fi # so hopefully this will abort e.g. if we're about to blow away the root filesystem for mounted in $(findmnt -o source | grep "^$CARD_DEV") ; do umount ...


0

sure, flashrd should be fine for your scenario: flashrd boots within 64MB RAM and 1GB flash hosting a default OpenBSD/i386 or Open BSD/amd64 installation. At least 128MB RAM is recommended for the default flashrd setup. you have to use a up-to-date version of OpenBSD with flashrd (currently at 5.9) which is strongly recommended in any case.


0

I am also facing similar problem with Renesar Rz/A1H. My bootargs are console=ttySC3,115200 console=tty0 ignore_loglevel root=/dev/mtdblock0 earlyprintk when I try to boot, ill get the error message "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,0)"


1

As it turns out, PPP is affecting it's own serial port, and since that's the one that's used to configure the GPS, that's what's causing the problem. By comparing the results of stty -F /dev/ttyUSB3 before and after running PPP, it became apparent that PPP was configuring the serial port in raw mode, which meant I couldn't use it to configure the GPS port. ...


0

I got the same error after I cross-compiled Qt for an iMX6 device. I usually ran a build script from the build directory, and my script assumed that, but this time I forgot, and the build happened in my top level ~/dev directory. Somehow (I have no idea how), this affected my regular desktop build of Qt, so that any project I built with that desktop build ...



Top 50 recent answers are included