El ejército en movimiento.

¿A dónde va el ejército?

Es lo que me imagino que las personas que viajaron por la autopista y los vieron se preguntaron en éstos días durante las vacaciones. Nos encontramos con los primeros convoys entre los límites estatales de Veracruz, Tabasco, Oaxaca y Chiapas.

 El movimiento de tropas no es algo inusual, pero cuando se ve tal cantidad de vehículos se convierte en algo que llama la atención, ¿acaso el Gobierno Federal quiere aprovechar los días para que los ciudadanos veamos que el Ejército se mueve y que nos están cuidando?¿Es una estrategia del Gobierno para amedrentar a los civilies indicando de alguna manera que hay modos de hacer represiones sin mucho aspaviento?

Usted crea y opine lo que guste, al fin y al cabo usted vive en un país libre y soberano, donde sus libertad de expresión se respeta al igual que sus garantías individuales. Lo que recordé es que en días previos habían comentado en las noticias que el Estado de Michoacán tendría refuerzos para incrementar la seguridad (claro, la que empezaron a brindar las "autodefensas" ante la nula acción de las respectivas autoridades locales).

Y casualmente después de rebasar a varias unidades, cuando pasamos la desviación que lleva rumbo a Morelia, ya no encontramos a ninguno.  ¿Cuántos elementos fueron desplazados a Michoacán? ¿Se notará la diferencia cuando el Ejército forme parte de la seguridad? Y lo más importante ¿los ciudadanos de ése Estado se sentiran más seguros con la presencia del Ejército Mexicano?

e2fsck: Cannot continue, aborting.

This was the error message I got from my CentOS 6.5 in previous days but I didn't pay attention, 'cause I was trying to boot to Windows 7. So yesterday that I wanted to boot Centos, I got the notification that /var was having issues and that I need to fix using fsck before mounting it.

I used fsck to clean the filesystem but after pressing "Ctrl+D" a reboot was done and while booting again I got stuck again with a message requesting to use fsck to clean the root filesystem, which was mounted as "ro" (read only).

How it was possible to have it mounted read-only and then a request to run fsck? This was not expected and I started to search for an answer.

After looking around at different forums, I decided to use a live cd, clean all the filesystems using fsck and boot again. Same result.

It wasn't a problem with the filesystems or to use fsck to clean them. I stopped yesterday it was very late. Today in the afternoon I checked an alternative that I discarded yesterday at night: check the initrd file.

I used another kernel to boot and everything was running perfectly, the initrd file for kernel 2.6.32-431.5.1.el6.x86_64 was there and no issues at all, but not the initrd file for kernel 2.6.32-431.11.2.el6.x86_64.

So how to create it?  You can look here directly but to save you time here are the steps:

For CentOS 6:

• Create a backup copy of the current initramfs:

  cp -p /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak
  

• Now create the initramfs for the current kernel:

  dracut -f 
  

• If you need to build it for a specific kernel version (replace the version appropriately):

  dracut -f /boot/initramfs-2.6.32-358.el6.x86_64.img 2.6.32-358.el6.x86_64
  

• One useful option you might want to add is -H (--hostonly). With this option dracut installs only what is needed for booting your system. Otherwise dracut by default adds many drivers to the initramfs making its size larger than necessary. Many other options may be exercised. Please see man dracut, man dracut.conf and the upstream Deployment Guide.

Reboot

cd /
sync
telinit 6

The computer reboots, reports that the "kdump" file doesn't exists and was created at that very moment, finally the boot is completed, clean and no issues.

Now all the files needed are available and no issues after reboots, how did this happened?!  I have no idea. Also I can't blame the system going crazy after installing a new hard drive of 1000 GB and seeing all the devices changing. 

The /dev/sda was assigned to the new hard drive (this should have been /dev/sdc), /dev/sdb was assigned to the hard drive were the operating systems are installed (this should have remain as /dev/sda) and /dev/sdc was assigned to the other drive were I have the rest of my data (this was /dev/sdb).

The order should not matter if you are able to identify your partitions by volume id, uuid or label. I used label and the command "lsblk -f" confirmed what I needed to know.

The good thing is, today talking about this to a friend, he told me to change how the SATA cables are connected to the motherboard, I did and now I see the drives in the order I want, just my personal preference.


Update:

Nothing of this fixed the problem but at least boots and I'm able to work with it again.

It was an incorrect option at /etc/fstab for windows partitions:

As you can see, I had "ntfs" only instead of "ntfs-3g", using that option fixed my problem. I don't know why using "ntfs" only before worked without issues.