In an embedded system, space is a very valuable commodity. Sometimes, there are packages that are installed needlessly and they take up space. A quick way to see the largest installed files in sorted order is:
dpkg-query -Wf '${Installed-Size}\t${Package}\n' | sort -n
Source:commandlinefu.com
If you have direct access to the Linux filesystem (like a mounted SD card for example), it’s really easy to clear the password from the system. Simply take a look at the /etc/passwd file. You’ll see a line for every user on the system in a syntax like this:
<username>:<password>:<UID>:<GID>:<user_id_info>:<home_dir>:<command/shell>
To clear the password, simply delete anything in the
For example:
#change this: root:$1$TeCMjrna$1lmHjj.1E9NAAW2am.c7./:0:0:root:/root:/bin/bash #to this: root::0:0:root:/root:/bin/bash
There are also ways to clear/change the password from GRUB or LILO if you don’t have direct access to the filesystem, but I’ll let ya’ll search for that one!
…and that’s what I learned today!
I had a disk that was partitioned in such a way that a large chunk at the end of the disk was unallocated space and the partition before it was where I wanted to tell ‘dd’ to stop copying. This is normally easy when I have the number of bytes I want to copy, but all I had were the the number of heads, sectors, and cylinder start/end values given by the output of “fdisk -l”. I knew that I wanted to end at cylinder 508 since that was where the particular partition ended, but I still didn’t know which byte it ended at. I found an easy way to tell ‘dd’ what I wanted by using the ‘bs=
dd if=/dev/sdb of=sd_image.dd bs=124x508x62b count=1
Where 124=heads, 508=cylinders, and 62b=sectors at 512bytes each. This is really simple math, but it’s simpler just to tell ‘dd’ to calculate it instead (124*508*62*512 = 1999618048bytes).
And that’s what I learned today!
What I’ve Learned Today:
Say that you have a program that you’d like to be able to compile for both ARM and x86 architectures, but you have portions of the code written in assembly language. Obviously, assembly code written for an ARM CPU won’t compile and run on an x86 CPU, so how would you cleanly solve this problem without writing two different programs? One suggestion would be to use #ifndef (see this page for an explanation) and the ‘-D’ flag when invoking the gcc compiler to tell the compiler to ignore a particular block of code. Here is an example snippet of code that you might want to use in a program:
#ifndef X86
// This is ARM assembly code which is preferred architecture
asm(
"mov r0, r0\n\t"
"mov r0, r0\n\t"
"mov r0, r0\n\t"
"mov r0, r0"
);
#else
// This is X86 assembly code
asm(
"movl %eax, %ebx\n\t"
"movl $56, %esi\n\t"
"movl %ecx, $label(%edx,%ebx,$4)\n\t"
"movb %ah, (%ebx)"
);
#endif
This program will be developed mostly for the ARM architecture, but we would like to be able to easily compile it for x86 as well. When we do want to compile for x86, we will use the command:
gcc -D X86 myprogram.c -o myprogram_x86
The -D flag is a preprocessor option which, in my understanding, sets a sort of #define for the program before compiling (see ‘man gcc‘ page). The preprocessor will check for any of the #ifndef or #ifdef lines of the program and then act accordingly. In this example, the lines between “#ifndef X86″ and “#else” containing the ARM assembly code will be discarded and the lines between “#else” and “#endif” containing the x86 assembly code will be used.
What I’ve Learned Today:
I have always known that the Master Book Record (MBR) was a critical part of any computer, but today I actually took a minute to look it up in wikipedia. I now understand it in a little more detail now. I’m not going to repeat the entire article, but the MBR is a 512 byte portion of the disk which contains three things: 1) the disks partition table, 2) the machine code that is executed after the computer BIOS passes called the bootstrap, and 3) a 32-bit checksum for identifying individual disk media.
Sometimes, bad things happen and this area of the disk can be overwritten and render the disk unusable. This generally doesn’t happen if you’re a normal desktop user who could care less about the partitioning table of the harddrive (HDD), but for those of us who are a bit more… geeky, it happens more often than not. So, in order to backup the MBR from within Linux, you must know which drive you’re backing up by using the ‘fdisk -l’ command. For myself, my HDD is located at /dev/sda and I have several partitions at /dev/sda1, /dev/sda2, /dev/sda3, etc… So, in order for me to backup my MBR, I would issue the following command:
dd if=/dev/sda of=mbr.dd bs=512 count=1
Similarly, to restore the MBR, I would issue the following command:
dd if=mbr.dd of=/dev/sda bs=512 count=1
And, that’s it! Not too hard, not too complicated, and saves on a massive headache in case something were to happen while geeking out. ;)
What I’ve Learned Today:
I had always figured that ‘eject‘ and ‘umount‘ were the same thing in that they both unmounted a drive whether USB Thumb Drive or CD-ROM. This isn’t entirely true. ‘umount’ will simply unmount the partitions for the disk, ‘eject’ will unmount the partitions as well as unmount the boot volume. The first example that comes to mind is the CD-ROM drive. If you had simply tried to ‘umount /dev/cdrom0′, the CD-ROM partitions would be unmounted, but the CD would still be stuck in the tray. With the ‘eject’ command, the CD-ROM would be unmounted and the tray would physically eject the media.
There are some devices out there that mount a pseudo (fake) CD-ROM drive, like SanDisk U3, that may need to be ejected depending on your application.