This howto is meant to show all or most of the theoretically ideas when creating a system relevant script that needs to be as secure and bug free as possible.
It is also some kind of a way to show a non-programmer or any person who so far did not create a more complex script by her/himself by the way of a documented HOWTO including the programmer's thoughts on the matter, and especially the details and file or program or system components the programmer has to consider when creating a script, especially one that changes such a crucial file as /etc/fstab.
The issue that I already posted somewhere on here in hope of someone of the core developers being able to have a solution to the changing of /etc/fstab bug after resume/thaw it this:
In my Porteus 3.1 XFCe version, when I suspend (hibernate won't work on that machine that is known having a ... weird BIOS, e.g. even with the newest available BIOS update, I sure can install 4GB of RAM in the motherboard, but only 3 1/2 GB are supported. Some RAM checking software [like the one included with Knoppix, and me thinks older versions of Slax and Porteus had that feature of RAM check instead of booting some OS, but for some reason that was removed. [I would like to tweak all my Porteus to have that RAM checking thingy again, but not figured out what exactly that is, I tried but ran into some issues that gave me headache, that I no longer can recall; tl;dr: I was not able to include this RAM checker in recent Porteus, what I recall is that there are 2 kinds of software that share the same name, or 2 different versions of the same software, the older one that has the RAM check, and the other/newer one that changed the software, so that the RAM check is removed and the software part now does something different, but something plausible due to it's name being not a clear indicator that this thingy does a RAM check at boot time... </digress>]
So, that RAM checker of old(er) told me that indeed 4 GB are installed, but even that RAM tester could only test 3 1/2 GB of RAM.
Code: Select all
# grep /dev/zram0 /etc/fstab
Code: Select all
/dev/zram0 none swap sw,pri=1 0 0
Code: Select all
/dev/zram0 none swap sw,pri=1000 0 0
When it's the first variant, some [so far unknown] software that was run at either resume/thaw or the suspend/hibernate stage (most probably during wakeup aka resume/thaw, me presumes) did this change. (The "unknown" software could just be the standard updating /etc/fstab component of Porteus / XFCe Porteus that fails to recall that when booted fresh, the priority of /dev/zram0 is way higher than the standard 1, and is so out of good reason, cause RAM based swap > harddisk based swap.)
When I had to kill X because of system freeze via Alt, SysRq + RE (aka REISUP, see also System request), some background programs are also killed and when starting X anew the system is not that same as the original XFCe, e.g. you have to start dhcpd manually, or the NetworkManager icon displaying the current network state is missing, also Hibernate or Suspend via the GUI menu is no longer available, I have to run as root pm-supend manually.
When I had to kill X cause of the freeze (could be the bug in the well known NVidia 6???
The current machine has a GeForce 6200 LE card, but on another machine I have another GeForce 6??? card that gives the same error after a while, running X and Porteus or days. The freeze error can be circumvented by exiting X and restarting X. When the card has no graphic data and reverts to the text based virtual console, then its almost full graphics card RAM is emptied by itself, and I can again use Porteus for some days or week(s) until the next freeze shows its ugly buggy head.
This 6??? class card driver that causes the RAM of the card to be filled up without removing old unneeded data, at at some time the system freezes cause the graphics card is unable to work due to that bug that sadly never was debugged by Nvidia, as far as I know all cards of that "class" suffer from the very same bug, not due to the card, aka the hardware being faulty but just because of the software driver bug, *facepalm*
Aaaaaanyhow, the need to kill X so brutally sure gives hints of what might cause /etc/fstab to be changed after each boot. Since /etc/fstab is no longer updated after a needed Alt, SysRq + RE and restart of X.
Now, my theory so far for some missing components is that some stuff was not started, cause some scripts in the /etc/rc.d directory are non-executable by default, still at normal boot they are executed by the system, but are not executed cause of missing non-executable attribute after the Alt, SysRq + RE hack...
[That is my theory of why some components malfunction or are missing or need to be run manually]
All I recall of malfunctioning parts are these:
* NetworkManager not running, and it cannot be run manually, seems it missed another component that needs to be started already prior invoking NetworkManager.
* dhcpd needs to be run manually, that is only needed after the first resume/thaw, then dhcpd is the background demon and handles going online or connecting/disconnecting the wired network when I unplug or plug-in the network cable manually...
* Hibernate and Suspend missing from the XFCe menu, but still pm-hibernate itself working like it should.
* Some other parts of XFCe settings manager is either missing or malfunctioning. Since currently I run a non-REISUP'd Porteus I cannot check out what the missing / malfunctioning XFCe settings manager component is; Still I am quite sure I recall it being the PowerManager (or parts of it) that is either missing (aka when clicked, nothing happens, but the icon is still there in XFCe settings manager) or it could be started but some of the most crucial parts are either greyed out or plain missing when run. [Last I tried that is now many months ago, and I just start my dhcpd and so the pm-suspend manually and know that I miss the NetworkManager icon, and have to look at the network cable itself for checking if the missing internet is due to a router or switch or Internet Provider issue, or due to just unplugged network cable.]
...
So, back on topic. When I had to kill X and restarted it, the software part that handles updating /etc/fstab is missing. E.g. I have to create the mount point folder manually and also have to mount a device manually when I plug in some storage, e.g. an external harddisk or an USM stick ("USB Flashdisk").
For now, after manually editing /etc/fstab and changing the /dev/zram0 from 1 to 1000 (the boot default was 100, not 1000, but that's not an issue at all, both are valid parameters, and in this case, both do the same, that is, prioritizing the RAM based swap and putting the harddisk based swap at the tail end of the priority chain.
Here is, as end for now, the info I get after I edited the needed change into /etc/fstab manually:
Code: Select all
root@porteus:/usr/local/bin# free -m|grep Swap;swapon -a;swapon -s;fx
Swap: 0 0 0
Filename Type Size Used Priority
/dev/sda1 partition 2097148 0 1
/dev/zram0 partition 694968 0 1000
23.09.2015 22:44:36 ____________________________________________________________
total used free shared buffers cached
Mem: 3393 3246 146 0 11 221
-/+ buffers/cache: 3013 379
Swap: 2726 0 2726
Code: Select all
root@porteus:/usr/local/bin# type fx
fx is aliased to `echo $(date +%d.%m.%Y\ %H:%M:%S) ____________________________________________________________;free -m'
root@porteus:/usr/local/bin# type dx
dx is a function
dx ()
{
echo $(date +%d.%m.%Y\ %H:%M:%S) ____________________________________________________________;
df -T -Tm $* | grep --color=auto -vE 'devtmpfs|/mnt/live/run'
}
For now, that's all folks.
Now that we have all the background of why an automated tweak /etc/fstab is needed out of the way, we finally can approach the next stage: That, my dear fellow seamen and sailors would be starting to finally ponder about how to implement the edit / diff /etc/fstab via script in a as failsafe manner as we can make it.
If you have any ideas on that, on how you would solve the automated /etc/fstab diff / edit matter, please post a reply. Please do reply especially if you see some error or mistake in this post so far... <B