There is a number of updates in the Eeepc fastinit reimplementation that you might be interested in:
- It works, as confirmed by Eeepc users that tested the program.
- Metalshark fixed a bug in the reimplementation that prevented it to load the shutdown splash screen.
- Kept finit.c as an accurate reimplementation of the original Eeepc fastinit, and spawned finit-mod.c as a modified/optimized version intended to be a drop-in replacement for fastinit. A third version, finit-alt.c, contains changes to allow alternative Linux distributions to boot in the Eeepc (currently supports Mandriva 2008).
Read on for details and results of booting Mandriva 2008 on a regular (non-Eeepc) laptop using finit-alt.
Modifications in finit-mod.c include fixes for bugs found in the original fastinit, including the random seed initialization bug, and minor performance improvements by avoiding some forks (removal of more forks prior to X initialization is planned). You can retrieve the code from the git repository as described in the original article, or run “git pull” to get the modifications if you have already cloned it.
It is also interesting to mention that although finit lacks many features existing in normal init(8) (and thus shouldn’t be used as an init replace in general cases) it is able to boot other Linux distributions quite fast, especially if you use a lightweight window manager. In my test system, a low-end Compaq laptop, it was able to boot an unmodified Mandriva 2008 with the Enlightenment or Icewm desktop in 17s, while the standard boot process takes about 1min05s to boot to KDE 3.5. From the 17s needed in the fast boot process, about 7s are taken by Xorg initialization with the Intel driver. SATA initialization and non-essential hardware probing during the kernel boot also takes a significant time during the whole process, so using a custom kernel and faster X setup could make the boot really fast.
Please note that using finit-alt in non-Eeepc systems is for research only, and you shouldn’t use it in a production system. You’ll lose functionality and potentially endanger your data.
Update (20080516): Project page finally published.
Entries (RSS)
February 7th, 2008 at 6:06 am
Suggestions:
*) Add -march=pentium-m if compiling finit or finit-mod (as the target will be an eeepc).
*) Add a -DNO_HCTOSYS make option that omits the first /sbin/hwclock if the user has enabled CONFIG_RTC_HCTOSYS in the kernel.
*) Add a -DDIRECTISA make option to append –directisa to /sbin/hwclock lines if the user has disabled CONFIG_GENRTC and enabled CONFIG_RTC but not enabled CONFIG_HPET_TIMER and CONFIG_HPET_RTC_IRQ.
Otherwise yet another great effort.
February 7th, 2008 at 7:24 pm
How does finit-mod.c compare speedwise booting on the eeepc versus the stock fastinit? And have you had any reports of people getting other distros to boot on the eee using finit-alt? The only thing holding me back from switching to xubuntu is boot time. 30-35 seconds from off is pretty nice, so for now im sticking with default xandros + xfce.
February 7th, 2008 at 7:46 pm
That’s a good question, I don’t have an Eeepc to test it. I believe the difference at this point isn’t very significant, the most important reason to use it would be the bugfix in the random seed initialization. I’ll merge Metalshark’s changes, perhaps skipping the first hwclock could save some time there, but I’d say the biggest point of optimization is in X startup, then in kernel probing.
February 8th, 2008 at 12:08 pm
I don’t think there would be any speed difference in the HCTOSYS option - it’s just not doing it twice and changing the order it does things in (presumably there is a microsecond or two calling a command line option from user space to kernel as opposed to handling it in kernel - but it’ll be splitting hairs territory). No notable speed increases in ftinit-mod alone on an EEE but bug fixes alone make it worth while. Starting dbus early and getting rid of the polling keyboardstatus, minimixer, networkmonitor, powermonitor, usbstorageapplet and wapmonitor with my home brew replacements does however reduce the Powertop ticks per second from ~80 to ~4 and I would lack full control of fastinit without this source code ;-).
February 11th, 2008 at 6:03 pm
Hello y’all.
Claudio, first off, thanks for your work producing this fastinit reimplementation. You’re actually the first person that I know of who’s tried to create a free rewrite of that stellar piece of technology from Asus (although too bad the OS doesn’t match that “stellarness”). :)
To answer Joey’s second question, the EeePCLinuxOS team is VERY interested in implementing some kind of fast boot scheme, so you can be sure we’ll be testing out your fastinit thoroughly. So far my project leader has gotten it to load, albeit with very little changes done to finit-alt (hence why the system doesn’t load HAL, ALSA and such). It currently takes about 45 seconds to load, but this is with the mklivecd initrd file still unmodified (and adding about 30 seconds to boot up time). Cutting the time from that piece of art will be a project in itself, but I’m hoping your fastinit will serve as an excellent template.
Our only drawback is that none of us are really versed in hacking init (or even C for that matter), but we’ll be sure to remedy that sooner rather than later. As we progress, I hope we’ll have the opportunity to share our code with you, and exchange other ideas. :D
February 13th, 2008 at 2:04 pm
[...] of which can be traced back to their fastinit-initd, which has been reverse-engineered, by the way: fastinit reimplementation. A short look at this and “strings /sbin/fastinit” reveals that it only does the [...]
February 14th, 2008 at 9:12 pm
Metalshark patches added, and a tarball with the current git snapshot were published at http://helllabs.org/finit/pkg/.
C-chan, I’m happy to know that finit-alt could be useful for EeePCLinuxOS. In my tests with Mandriva 2008 it worked well (I’ll add my /usr/sbin/services.sh file to the git repository for reference tomorrow), but one problem that remains is to set permissions on /dev files correctly since some devices are created after the user session starts. These must be fixed later, I’m not sure if we can make pam fix that or if we must fix ownership and permissions by hand.
February 15th, 2008 at 6:15 am
Unsure if this really applies - but have been trying out the new CONFIG_ASUS_LAPTOP, CONFIG_RFKILL, etc on the EEE and modifying/reimplementing the status/monitor/osd programs to use /sys/classes instead of /proc/acpi as the kernel’s menuconfig seems to suggest the proc method is going the way of the Dodo.
In shutdown you use “/proc/acpi/sleep”, would it be advisable to use the new sysfs method and use that if available and if not use proc (at runtime) with compile time options to disable proc/sysfs methods?
PS - The snapshots are great for Wiki entries and the like as it reduces the need to explain Git - would it be preferable to host a mirror before documenting guides for others? I do not want to be unkind to your servers and bandwidth limits in case there is a rush.
February 15th, 2008 at 6:30 am
Love the new C calls for directory creation and the like!
Notes:
*) On line 228 of finit-mod.c you use system(”/bin/rm -fr …”) instead of direct C calls.
*) On line 290 of finit-mod.c you still use system(”/usr/bin/touch /tmp/shutdown”) instead of just touch(”/tmp/shutdown”).
February 15th, 2008 at 2:30 pm
Thank you, Claudio,…
Metalshark,… :)
Indeed your fastinit works like a charm in several aspects, but still needs some attention with regard to shutdown/restart, as well as the loading of other services after hardware detection (EeePCLOS uses a compressed file system, akin to a liveusb environment w/ persistence).
I’ll pass along news of the updated snapshot, a look into how permissions can be set up with /dev files, and Metalshark’s suggestions for shutdown to our project leader.
February 16th, 2008 at 5:02 pm
It would be nice to have finit-mod working with recent kernels as well as with the stock Eeepc kernel, so I think having it configurable is a good idea. Probing at runtime should be fast and painless, by the way is there a good way to probe for hctosys and directisa at runtime? (Update: it’s unlikely that anyone would use kernel 2.4 on the Eeepc, so using /sys/power/state instead of /proc/acpi/sleep seems safe.)
About the recursive /tmp cleanup, I think we can just drop it since its tmpfs and was just mounted. Ifconfig and cat system() calls, however, could be moved to C without much effort. Remaining system(”touch”) call was replaced by touch(), thanks!
Regarding the snapshots, feel free to redistribute or hot-link as you wish, the package is really small.
February 17th, 2008 at 3:47 pm
I cannot think of a solution to the hctosys option (unless the sys part has a flag or relative timestamp to say it has been updated/last time of update), however there is something fishy about a select() to /dev/rtc when you call “/sbin/hwclock –show” without the –directisa option, as in it just hangs until the watchdog timer kills the process (provided of course you use a watchdog). So maybe we can look at the hwclock code (in util-linux I believe) find out the ioctl it uses - do a quick “are you supported?” check on /dev/rtc and have adequate detection.
February 17th, 2008 at 3:55 pm
Poking around with the options on an EEE I cannot find an argument against using the –directisa option all the time (no regressions found thus far with any kernel options/revisions) maybe keep the option for finit-alt and just leave it on permanently for finit-mod? PLEASE DON’T TAKE JUST MY ADVISE ON THIS ONE AND RISK ADDING A FLAW TO A BRILLIANT PROGRAM THOUGH ;-) Also wasn’t there an option in the kernel for automatically creating the loopback device?
February 18th, 2008 at 6:18 am
On the ever growing list of features - if you have disabled the full Shared Memory interface (as there is no point implementing swap on the EEE with it’s SSD) tmpfs renames itself ramfs. This then requires a quick modification of your source code to implement. Maybe this could be automatically detected as well?
February 19th, 2008 at 4:38 am
Can line 328 of finit-mod.c (the remounting of root) be performed via C calls?
February 19th, 2008 at 8:41 am
I’ll check the root remounting and report back. I also think it’s a good idea to check if disabling full shmem fs has any impact on POSIX shared memory support since glibc expects tmpfs to be mounted in /dev/shm (just to be sure). The current git head has ifconfig and cat/dd replaced by C calls, if that works I’ll release it as 0.2.
February 19th, 2008 at 9:54 am
I pulled from git last night with the C call version and have been trying it out. It works wonderfully :-D Couldn’t find the way of remounting with the “mount -n” do not touch /etc/mtab in C. I presume it’s just a “remount,ro” as the fifth argument and not to worry as only the mount utility gets friendly with mtab… Can try if you’d like.
RAMFS mounts the partitions but has problems with directories (it can make them, but not files inside of them - could be doing something wrong) so have reverted back to TMPFS. Might of been a step too far ;-).
Tried kernel versions 2.6.22, 2.6.23, 2.6.23.14, 2.6.24, 2.6.24-rt, 2.6.24.2 and 2.6.24.2-rt with and without CONFIG_RTC/CONFIG_GENRTC and still cannot find a regression with using –directisa all the time.
February 19th, 2008 at 10:04 am
Newer versions of unionfs spit out a line (well two as it is called twice) even with the original fastinit binary saying “unionfs: all remount options require an argument”. Will investigate.
February 19th, 2008 at 1:39 pm
I’ve looked into the
system(”/sbin/unionctl.static / –remove / > /dev/null 2>&1″);
line and in effect it does
unsigned long remountdata[3];
remountdata[0] = 0×4A5A4380;
remountdata[1] = _IOW(0×15, 13, int);
remountdata[2] = 2;
mount(”unionfs”, “/”, “unionfs”, (MS_REMOUNT | MS_MGC_VAL), remountdata);
which causes a message in dmesg complain about improper mount() usage when remounting.
February 19th, 2008 at 2:45 pm
After a bit of mucking about I’ve finally got a reaction that doesn’t complain about missing arguments - although it does crash X…
mount (
“unionfs”,
“/”,
“unionfs”,
MS_REMOUNT,
“dirs=/=rw:/=ro”
);
dmesg says:
remount ignoring option “dirs”
new generation number 2
could not unlink whiteout, err = -2
Posts like this (http://lkml.org/lkml/2007/10/21/189) seem to thicken the plot…
February 19th, 2008 at 9:10 pm
Have just tested the 0.3-pre to destruction.
There is an issue with some ACPI/Kernel combinations to do with shutdown.
It isn’t always powering off (tried /proc/acpi and /sys methods) - however removing all the fd > 5 stuff and putting in the simple line “reboot(RB_POWER_OFF);” worked for all thus far. Although semantically incorrect it is a working solution.
February 20th, 2008 at 6:06 am
Hey Claudio, Metalshark,
I’d just want to say a big thanks for your work so far. I love Opensource because of the guys like you. I’m gonna test finit and will report if I found something interesting.
Cheers, Andrei
February 21st, 2008 at 6:45 am
Suggested patch (have tested on 2.6.21 to 2.6.24.2-rt).
diff -durN eeepc/finit-mod.c eeepc-patched/finit-mod.c
— eeepc/finit-mod.c 2008-02-22 08:52:33.000000000 +0000
+++ eeepc-patched/finit-mod.c 2008-02-22 09:18:43.515460279 +0000
@@ -59,10 +59,10 @@
#include “helpers.h”
-#ifdef DIRECTISA
-#define HWCLOCK_DIRECTISA ” –directisa”
-#else
+#ifdef NO_DIRECTISA
#define HWCLOCK_DIRECTISA
+#else
+#define HWCLOCK_DIRECTISA ” –directisa”
#endif
@@ -271,8 +271,6 @@
*/
void shutdown(int sig)
{
- int fd;
-
touch(”/tmp/shutdown”);
kill(-1, SIGTERM);
@@ -283,23 +281,17 @@
system(”/usr/sbin/alsactl store > /dev/null 2>&1″);
system(”/sbin/hwclock –systohc –localtime” HWCLOCK_DIRECTISA);
- system(”/sbin/unionctl.static / –remove / > /dev/null 2>&1″);
kill(-1, SIGKILL);
sync();
sync();
- system(”/bin/mount -n -o remount,ro /”);
-
- system(”/sbin/unionctl.static / –remove / > /dev/null 2>&1″);
+ mount(”unionfs”, “/”, NULL, (MS_REMOUNT | MS_RDONLY), NULL);
if (sig == SIGINT || sig == SIGUSR1)
reboot(RB_AUTOBOOT);
- if ((fd = open(”/sys/power/state”, O_WRONLY)) >= 0) {
- write(fd, “5″, 1);
- close(fd);
- }
+ reboot(RB_POWER_OFF);
}
diff -durN eeepc/Makefile eeepc-patched/Makefile
— eeepc/Makefile 2008-02-22 08:52:33.000000000 +0000
+++ eeepc-patched/Makefile 2008-02-22 09:19:19.043458545 +0000
@@ -49,7 +49,7 @@
$(CC) -c $(CFLAGS) -DDIST_MDV -o $@ finit-alt.c
clean:
- rm -f *.o core *~
+ rm -f *.o core *~ finit finit-mdv finit-mod
finit.o: finit.c Makefile
February 21st, 2008 at 9:35 am
Having –directisa enabled in the general case has a problem: hwclock will always try to use CMOS clock operations first instead of RTC, and there’s a small chance of error in the operation (from the hwclock source, “This function is not totally reliable. It takes a finite and unpredictable amount of time to execute the code below. During that time, the clock may change and we may even read an invalid value in the middle of an update. We do a few checks to minimize this possibility, but only the kernel can actually read the clock properly, since it can execute code in a short and predictable amount of time (by turning of interrupts).”) so it seems that using RTC is the way to go. Is there a case where we would want to actually disable RTC support?
Mount patch applied to finit-mod (but not finit-alt since unionfs usage is optional in other systems), reboot patch applied to both.
February 21st, 2008 at 9:59 am
Just for those playing along at home with an EEE.
No drivers so far are working in the “Real Time Clock” option under “Device Drivers”, not even RTC CMOS - so no /dev/rtcX :-(. So you’ll either need CONFIG_GENRTC or CONFIG_RTC for true /dev/rtc.
If you enable HPET and RTC emulation (as in no RTC or GENRTC) you’ll need to “rm /dev/rtc” and “ln -s /dev/hpet /dev/rtc”. This does cause an issue with “RTC_RD_TIME: Invalid argument” messages from hwclock (at least it doesn’t hang though) so stick in the -DDIRECTISA option. If you’re trying to get aircrack-ng to work out the box look up http://lkml.org/lkml/2007/8/1/479 and apply it.
February 21st, 2008 at 10:08 am
Thanks for the hwclock info Claudio - I’ll see if the RTC_CMOS driver can be patched for the EEE - then a quick userspace hwclock update (think my version is pre /dev/rtcX) and alls well.
February 21st, 2008 at 12:36 pm
Will see if this patch does the job tonight http://lkml.org/lkml/2007/12/20/309.
February 22nd, 2008 at 6:05 am
The patch worked (with a little mudging) and you’re right it’s better to avoid –directisa if possible.
Have created a post (http://forum.eeeuser.com/viewtopic.php?pid=152063) on the EEE forum so I do not clutter up your comments with EEE kernel related stuff.
Am now going to see what else can be brought in to the finit-mod instead of relying on external tools (without causing potential maintainability nightmares). Candidates so far are alsactl (will see how stable the API is - as you presumably don’t want to have to update this with every release) and our old friend hwclock ;-) (for non –directisa only). Yell if you would prefer not to have this stuff in finit-mod or if there are other elements you’d like to see first.
Haven’t found a way to see if hctosys has been called yet…
Also powertop reports that finit-mod is causing wake-ups (one about every 5 seconds methinks as it says 0.2 wake-ups a second) the line says “finit-mod: start_this_handle (commit_timeout)”… Couldn’t find what was causing it though. Maybe the sighandle stuff?
February 22nd, 2008 at 7:34 pm
I’m currently testing finit-alt with a Dreambook IL1 and detected a serious problem in makepath() regarding unterminated strings, that was fixed and pushed. I also added code to mount /var/lock and /var/run as tmpfs, since there’s no point in wearing out flash storing such transient data — it worked for me in the IL1 but please check if it doesn’t do anything unexpected with finit-mod and the Eee.
Regarding instrinsic ALSA support, I think the mixer API is stable enough but I would avoid linking init against libasound if it can be done in some other way. The call to alsactl is in shutdown() and shouldn’t be critical performance-wise. I’m also checking some other issues I found today. I’ll release 0.3 with the critical makepath() bugfix skipping other developments already in course, which will be in line again for 0.4.
I think the cause for the 5s wake-ups could be indeed signals being catched, I’ll keep an eye open for that during the next test rounds, and also check the Eeeuser thread.
February 23rd, 2008 at 7:21 am
finit-mod 0.3 has been thoroughly tested on the EEE (a direct git pull - without edits) everything seems to running fine.
If a static library for alsalib is used then (providing the distribution provides a static library and loads the module if it’s compiled that way) it should work, *crosses fingers*
Do you foresee any issues in threading “Time adjustments”, “Network stuff” and “Set Random Seed” then waiting for all three threads to finish before running “Misc setup”? It might be away to reduce boot times “slightly” on the EEE (if non-cross-dependant stuff gets blocked), but it is aimed more at finit-alt for multi-core machines.
My hunch is the powertop wake-ups are caused by some syscall to X in chld_handler and am digging through posts like this http://www.ussg.iu.edu/hypermail/linux/kernel/0507.1/0755.html to try and find out why.
February 25th, 2008 at 11:26 am
Added /var/tmp (mode=1777,size=128m) to the mount code and it works without regressions on an EEE.
Changed the lines: system(”/bin/mount -n -o remount,ro /”); and system(”/sbin/unionctl.static / –remove / > /dev/null 2>&1″); to just mount(”unionfs”, “/”, NULL (MS_REMOUNT | MS_RDONLY), NULL);. It works without the error message on reboot/shutdown.
Tried to narrow down the PowerTop ticks by removing the SIGCONT and SIGALRM (it was neither of those). Then created a new SETSIG:
#define SETCHLDSIG(sa, sig, fun, flags) \
do { \
sa.sa_handler = fun; \
sa.sa_flags = flags; \
sigemptyset(&sa.sa_mask); \
sigaddset(&sa.sa_mask, CLD_TRAPPED); \
sigaddset(&sa.sa_mask, CLD_STOPPED); \
sigaddset(&sa.sa_mask, CLD_CONTINUED); \
sigaction(sig, &sa, NULL); \
} while(0)
which didn’t work either - put the signals back to normal now and am clueless as to how to remove the wake-ups…
February 25th, 2008 at 11:45 am
The line of code:
for (i = 1; i
February 25th, 2008 at 11:46 am
Ah - your comment system omits < tags - basically the nmask2 for loop uses an i++ instead of a ++i. Although most compilers automatically change this - it’s usually better to assume that they won’t.
February 25th, 2008 at 12:27 pm
Have fixed the wake-ups per second issue by replacing access() which:
“checks whether the process would be allowed to read, write or test for existence of the file (or other file system object) whose name is pathname. If pathname is a symbolic link permissions of the file referred to by this symbolic link are tested”
with an open() to a fd (file descriptor) in the while loop.
Here’s the patch with all the changes:
diff -durN eeepc/finit-mod.c eeepc-patched/finit-mod.c
— eeepc/finit-mod.c 2008-02-23 23:57:34.000000000 +0000
+++ eeepc-patched/finit-mod.c 2008-02-26 15:06:12.533431914 +0000
@@ -40,7 +40,10 @@
- Draw shutdown splash screen using C calls instead of system(”echo;cat”)
- Change poweroff method from writing 5 to /sys/power/state to
reboot(RB_POWER_OFF) (by Metalshark)
– Mount /var/run and /var/lock as tmpfs
+- Mount /var/run, /var/lock and /var/tmp as tmpfs
+- Replace unionctl, mount -o remount with a direct mount() (by Metalshark)
+- Replace access() with open() to stop wake-ups in PowerTop (by Metalshark)
+- Replace post increments with pre increments for speed (By Metalshark)
*/
@@ -109,7 +112,7 @@
/*
* Signal management
*/
- for (i = 1; i /dev/null”);
+ fd = open(”/tmp/shutdown”, (O_RDONLY | O_NONBLOCK));
+ }
+
+ close(fd);
exit(0);
}
@@ -291,8 +301,7 @@
sync();
sync();
- system(”/bin/mount -n -o remount,ro /”);
- system(”/sbin/unionctl.static / –remove / > /dev/null 2>&1″);
+ mount(”unionfs”, “/”, NULL, (MS_REMOUNT | MS_RDONLY), NULL);
if (sig == SIGINT || sig == SIGUSR1)
reboot(RB_AUTOBOOT);
February 25th, 2008 at 2:55 pm
Tried adding threads by adding -lpthread to ${LIB} and -static to ${LDFLAGS}. ldd informs me that it is a static binary, yet if I call pthread_create then pthread_join it hangs. Any ideas - as dry runs of the code on it’s own seems to work (when booted up into X)?
February 27th, 2008 at 7:51 am
Just to say there are mandriva users that are sutck on your comments in order to test fini-mdv ;)
Claudio and metalshark -> very good job. :) mmm… I’ve done some bench on it… boot time is reduce of 30 seconds. (wifi doesn(t work but ather thongs works.)
February 28th, 2008 at 12:34 pm
I am having trouble getting hold of finit-mod.c …. Is there any way other than git? Making git fails on my eee saying
http-push.c:13:19: error: expat.h: No such file or directory
http-push.c:1179: warning: type defaults to ‘int’ in declaration of ‘XML_Char’
http-push.c:1179: error: expected ‘;’, ‘,’ or ‘)’ before ‘*’ token
http-push.c: In function ‘lock_remote’:
…and a ton of other things. Any ideas?
February 28th, 2008 at 5:28 pm
Dear Richard - Claudio has put the snapshots on http://helllabs.org/finit/pkg/ (as per a comment above). You don’t have to make git on your eee (and have a sneaky suspicion our (g)libc-dev is bust which stops things compiling nicely). You are looking to do a “sudo apt-get install git-core” (run “sudo apt-get install git-core –simulate” first to be safe).
Somewhere in the Ultimate EEE guides you can add the required repositories http://www.infinitedesigns.org/archives/147 and http://www.infinitedesigns.org/archives/164 or failing that try http://wiki.eeeuser.com :-D
Good luck!
March 11th, 2008 at 9:08 pm
I like the configurations of finit-alt. Good job. Maybe adding one for sound on/off and the shutdown frame buffer image could help round off the options? When finished with kbdstatus (nearly there - fingers crossed) I’ll try to sort out the pthread priorities for services.sh and add a mutex for uname() calls in the finit-threaded version.
March 20th, 2008 at 11:19 am
The NSIG loops should start at 1 not 0 as there is no signal 0 in bits/signum.h - also if you do an assert or similar SIGKILL, SIGSTOP and signals in the __SIGRTMIN to __SIGRTMAX range fail. Maybe try something like:
void ignore_all_signals (void)
{
struct sigaction act;
act.sa_flags = SA_RESTART;
act.sa_handler = SIG_IGN;
sigemptyset (&act.sa_mask);
for
(
int sig = 1;
sig != NSIG;
++sig
)
{
switch (sig)
{
case SIGKILL:
break;
case SIGSTOP:
break;
default:
if
(
sigaction
(
sig,
&act,
NULL
) != 0
)
{
return;
}
break;
}
}
}
March 23rd, 2008 at 4:59 am
The DEBUG line could read:
printf(”finit: %d: ” x “\n”, __LINE__);
or
printf(”finit: %d: %s\n”, __LINE__, x);
instead of
printf(”finit: %d: “, __LINE__); printf(x); printf(”\n”);
it’ll save a triple call to printf.
March 23rd, 2008 at 4:00 pm
What is the difference in calling the empty signal handler and using SIG_IGN? If I’m right in saying they both do exactly the same thing then surely removing the function would reduce code and increase clarity? However if it arises from the stracing of the original then maybe there is an edge case that hasn’t been accounted for - an if statement in the handler or suchlike? Also the SIGCONT line could change to a SIG_DFL (as I don’t believe that SIG_IGN honours the SA_RESTART mask).
Am doing some more testing on what is really needed and think that setsid() will generate a EPERM errno everytime as the “exec switch_root” means finit will already be the process group leader…
Also shouldn’t close(0); be called everytime regardless of whether quiet is specified - as we do not use stdin and can close the fd (one less resource for the length of time the machine is open). That being true then shouldn’t the forked gui process also honour the quiet line (and not bother to open a pipe to stdin).
Please correct any false assumptions here - as am trying to figure all this out.
April 20th, 2008 at 3:33 pm
Just a little tidying up in the new version - the finit-mod.c changelog can probably drop the “Change /proc/acpi/sleep to /sys/power/state” line.
Would also be curious to know if Madr(ake|iva) fails when you put an assert() around “sigaction(sig, &sa, NULL);” on the signal numbers __SIGRTMIN to __SIGRTMAX (33 and above)?
Good to see you back :-D
April 21st, 2008 at 12:30 pm
Just read through this very interesting thread, and I’m looking forward to trying this on my eee tonight.
I’m currently running xubuntu 8.04 (beta) with root on the SSD and /home on an SDHC, with fvwm-metisse as the WM.
I love my current setup, apart from the 80s boot time…
If I can get this to work, I will be a very happy guy!
One thing I noticed - this can be apt-got? Do I need to set up a specific repository for this in my sources.lst?
If I can get this working, I’d look to write up a guide on the eeeuser wiki for this, I’m sure it would interest a lot of eee owners!
April 21st, 2008 at 1:57 pm
I’ve been so busy in the past few weeks that I hardly touched finit, but now I think I’ll have some time to add some improvements :) Yes, using SIGN_IGN seems to be cleaner than calling an empty handler, so I changed finit-mod/alt to use that. I also added a call to pam_console_apply to handle permissions in distributions using pam_console. I’ll check the signal stuff this week and report back.
About finit in Xubuntu: it’s almost certain that you’ll have to make changes in finit-alt to accomodate xubuntu’s needs. Some distribution-specific quirks are implemented and can be enabled using macros, see how Mandriva is supported in finit-alt.c. Since Ubuntu/Debian are closer to the original Xandros than Mandriva, my guess is that it won’t be hard to implement. Drop a note if you have specific problems.
April 23rd, 2008 at 7:00 am
Hey, thanks for your efforts, and here are some maybe noobish questions/asumtions :D
I asume that this small c tool replaces all /etc/init.d scripts, all scripts i still need should be put in a services.sh which will be called by finit after it has done its job.
i use eeexubuntu with /usr as unionfs/sqashfs and /home as cryptofs luks at a sd card.
i mount /usr with fstab and /home with a init.d script
so must i hack the c code and add my /usr mount or does it load fstab mounts?
April 25th, 2008 at 3:42 am
I’m afraid that yes it does require hacking C - however it isn’t as bad as it sounds :-D
A quick search for mount options in C or sys/mount.h will help.
However as a result of this - and a lack of GNU Autotools or other compile time optioning - it makes it hard to have an aptitude or similar distribution interface. When more distributions are tested as working (without regressions) that may become a possibility.
April 25th, 2008 at 11:58 am
Yea :D
I starting hacking a bit too for eeexubuntu:
My results could be found here:
http://forum.eeeuser.com/viewtopic.php?pid=233009
May 6th, 2008 at 12:38 pm
I am using the eeepc model 900 and its default linux. I have added few lines to finit-mod.c to mount/unmount secondary 16GB SSD and booted without problem.
However the system cannot properly power off by /sbin/fastshutdown.sh. The power light stays there.
I tried to go back to the echo 5 method, but still not work.
There isn’t any message output even I did not specify quiet option.
Rebooting worked however.
Grateful if anyone has idea about the power off. Anything changed in model 900?
May 15th, 2008 at 12:24 am
Well finit-mod can power off gracefully now, as I remove a kernel module before shutting down. Precisely I put this line in a sensible place inside /sbin/fastshutdown.sh
rmmod snd-hda-intel
Not sure what’s happening but this worked for me anyway.
BTW thanks for the finit reimplementation. I learnt how the linux boot up from the source. Pity that Asus do not release their originals.
July 3rd, 2008 at 1:15 am
rmmod snd-hda-intel works all right.
BUT if you try to shutdown while any program that uses audio is running the module can’t be unloaded and full shutdown hangs. I added the following two lines to kill any such programs before rmmoding snd-hda-intel
killall -9 -w `lsof +c 15 /dev/dsp | awk ‘{print $1}’`
killall -9 -w `lsof +c 15 /dev/snd/* | awk ‘{print $1}’`
I used killall procname instead of kill PID because killall has the -w switch, that forces it to wait until all the targetted programs are really dead before moving on. Using kill followed by rmmod failed, as they programs weren’t quite dead yet :) killall -w, rmmod seemed more elegant than kill, wait 5 seconds, rmmod.
the +c 15 on lsof is there because the columns displayed by lsof’s output are by default only 9 characters wide, so you’d end up trying to kill firefox-b (instead of firefox-bin). 15 is the max. Longer named programs will not be killed. You can
fuser -k /dev/snd/*;fuser -k /dev/dsp
first, and hope the killall command takes enough time for such programs to be actually dead by the time you rmmod.
I had been using
killall -9 -w `lsof +c 15 | grep -E ’snd|dsp’ | awk ‘{print $1}’`
but lsof-ing everything and grepping throught it could take a lot of seconds.
Long story short, 900 users add these lines to /sbin/fastinit.sh and you can just shutdown.
killall -9 -w `lsof +c 15 /dev/dsp | awk ‘{print $1}’`
killall -9 -w `lsof +c 15 /dev/snd/* | awk ‘{print $1}’`
rmmod snd_hda_intel
August 5th, 2008 at 2:41 am
Oh, script above needs lsof installed. :-/
get from official xandros repos.