[arch-general] Startup scripts
I was just forced to waste 10 min of my life because of arch-linux-way 'of doing things'. *rant mode on* Let me elaborate, for quite some time now, I've been unappeased by the way arch-linux handles the boot-up process, not so much by how it actually does it (it normally gets the job done) but more the fact that there's little to no obvious way of checking on it when things do go wrong. I've not been able to boot my custom compiled kernels since pathes 32.2 and 32.3, I don't know why, the config is identical to my running 32. I am at a loss. Anyway just now, I rebooted, tested yet another kernel, which failed of course, just to be sat in front of my kms-enabled high-resolution tty1 telling me that my home-partition needed checking after 34 mounts. Nice feature, normally I wouldn't bother, but I was in a hurry, so I hit ctrl-c, and bang 'fsck failed' - well yes it did, because I wanted it to, - dumbass, well I go and hit 'Control-D' to continue, and lo and behold the machine reboots, just to get on my nerves again with the fsck the next round through. I accepted defeat then, and went and made myself a nice hot cup of tee, BUT dear arch community, this is something I hate and find so wrong on so many levels I cannot begin to describe them all, even m$ offered a way to skip these things most of the time...) *rant mode off* Seriously I find the systems behaviour offensive, I should be in control, not some half-baked script. This is exactly the same reason that I had to sit through fsck regulary a while back(2.6.30 or 2.6.31), because of some bug regarding ext4-partitions(the timestamp in future error), not really because of the bug, but because of the inflexibility of arch linux boot up scriptures. Where to go, to file that bug... Tom
On Fri, Jan 15, 2010 at 2:51 PM, Tom <uebershark@googlemail.com> wrote:
I was just forced to waste 10 min of my life because of arch-linux-way 'of doing things'.
*rant mode on* Let me elaborate, for quite some time now, I've been unappeased by the way arch-linux handles the boot-up process, not so much by how it actually does it (it normally gets the job done) but more the fact that there's little to no obvious way of checking on it when things do go wrong.
I've not been able to boot my custom compiled kernels since pathes 32.2 and 32.3, I don't know why, the config is identical to my running 32. I am at a loss.
Anyway just now, I rebooted, tested yet another kernel, which failed of course, just to be sat in front of my kms-enabled high-resolution tty1 telling me that my home-partition needed checking after 34 mounts. Nice feature, normally I wouldn't bother, but I was in a hurry, so I hit ctrl-c, and bang 'fsck failed' - well yes it did, because I wanted it to, - dumbass, well I go and hit 'Control-D' to continue, and lo and behold the machine reboots, just to get on my nerves again with the fsck the next round through. I accepted defeat then, and went and made myself a nice hot cup of tee,
BUT dear arch community, this is something I hate and find so wrong on so many levels I cannot begin to describe them all, even m$ offered a way to skip these things most of the time...) *rant mode off*
Seriously I find the systems behaviour offensive, I should be in control, not some half-baked script. This is exactly the same reason that I had to sit through fsck regulary a while back(2.6.30 or 2.6.31), because of some bug regarding ext4-partitions(the timestamp in future error), not really because of the bug, but because of the inflexibility of arch linux boot up scriptures.
Where to go, to file that bug...
The sulogin message says: Give root password for system maintenance (or type Control-D for normal startup): While it is a hair misleading, entering the root password at this point gets you to your system. Also, to shut off automatic fsck at boot. From `man fsck`: Filesystems with a fs_passno value of 0 are skipped and are not checked at all. If all this is still unsatisfactory to you, send a patch. *rant mode on* Since when did open source become about "do things for me"? You don't like the way something works, so what is your answer? Filing a bug with the hopes that someone ELSE will fix it for you? That is simply not going to happen. You know exactly what the issue is, you know exactly how you would fix it. So fix it and send a patch. That is the only way this stuff will get done. This is collaboration, people. This isn't a hand out.
While it is a hair misleading, entering the root password at this point gets you to your system.
No, it does not. You get dropped to a promt, I don't know which 'init-level' its on, but it generally does not get you to your system like a normal boot.
Also, to shut off automatic fsck at boot. From `man fsck`: Filesystems with a fs_passno value of 0 are skipped and are not checked at all.
I don't want to turn off the automatic check, I just think(among a few other things) that this test should be easily skip-able. The startup-script behaves very 'dumbly ' at said point, IMHO. I neither know enough to 'fix' this kind of thing myself, nor do I really have the time. I know very well that this is a community distro, and that its wrong to rant, but I did put it in '**' ;) Also I don't agree that it is right to be silent (not file bug reports) just for the sake of 'politeness'
On Fri, Jan 15, 2010 at 3:35 PM, Tom <uebershark@googlemail.com> wrote:
While it is a hair misleading, entering the root password at this point gets you to your system.
No, it does not. You get dropped to a promt, I don't know which 'init-level' its on, but it generally does not get you to your system like a normal boot.
Also, to shut off automatic fsck at boot. From `man fsck`: Filesystems with a fs_passno value of 0 are skipped and are not checked at all.
I don't want to turn off the automatic check, I just think(among a few other things) that this test should be easily skip-able. The startup-script behaves very 'dumbly ' at said point, IMHO.
And I disagree. It's about maintaining system integrity. If anything goes wrong with fsck, then your system's integrity cannot be guaranteed. That said, it does appear that fsck returns "canceled by user request" (32) on a Ctrl-C, and it's entirely possible to continue booting after this.
I neither know enough to 'fix' this kind of thing myself, nor do I really have the time. I know very well that this is a community distro, and that its wrong to rant, but I did put it in '**' ;)
Also I don't agree that it is right to be silent (not file bug reports) just for the sake of 'politeness'
If you don't know enough to fix it, then learn. You obviously understand what fsck DOES, how to cancel it, and how to read a man page. That's all you need to know. In fact, that's exactly what I did - looked in rc.sysinit, then the man page for fsck, and discovered how to fix this (see above, return code of 32). The only way to learn is to try. Most important fixes and improvements get done because of miscellaneous people finding itches and scratching them. Look at how long we've been trying to get signed packages in pacman! The people doing the coding don't care about signed packages, and the people who want signed packages aren't doing coding. So it takes _years_. Don't let this take years. Or even months. Or even days. All this aside, rc.sysinit is SUPPOSED to handle user cancellation. Remember fsck returns 32 if the user cancels it. if [ ${fsckret} -gt 1 -a ${fsckret} -ne 32 ]; then So on a return of 32, if skips the sulogin part and carries on. Why didn't that work for you? No idea. Figure it out.
All this aside, rc.sysinit is SUPPOSED to handle user cancellation. Remember fsck returns 32 if the user cancels it.
if [ ${fsckret} -gt 1 -a ${fsckret} -ne 32 ]; then
Could you perhaps post all of the relevant code, because I don't see it skipping the su-login part!?
On 17/01/2010 11:42 μμ, Tom wrote:
All this aside, rc.sysinit is SUPPOSED to handle user cancellation. Remember fsck returns 32 if the user cancels it.
if [ ${fsckret} -gt 1 -a ${fsckret} -ne 32 ]; then
Could you perhaps post all of the relevant code, because I don't see it skipping the su-login part!?
That code is here: http://projects.archlinux.org/initscripts.git/tree/rc.sysinit?id=2009.08-1#n... Looks correct to me.
That code is here: http://projects.archlinux.org/initscripts.git/tree/rc.sysinit?id=2009.08-1#n...
Looks correct to me.
Thanks, but then it doesn't skip fsck when hitting control-c but drops to /sbin/sulogin ?
On 18/01/2010 12:42 πμ, Tom wrote:
That code is here: http://projects.archlinux.org/initscripts.git/tree/rc.sysinit?id=2009.08-1#n...
Looks correct to me.
Thanks,
but then it doesn't skip fsck when hitting control-c but drops to /sbin/sulogin ?
Maybe fsck doesn't return 32 as it's supposed to. You can verify this by adding `echo fsck returned ${fsckret}' inside that code block in /etc/rc.sysinit. Next time you'll encounter this behavior, you'll know the code returned by fsck. From there, you might be able to troubleshoot this issue further.
On Mon, Jan 18, 2010 at 1:01 AM, Evangelos Foutras <foutrelis@gmail.com> wrote:
On 18/01/2010 12:42 πμ, Tom wrote:
That code is here:
http://projects.archlinux.org/initscripts.git/tree/rc.sysinit?id=2009.08-1#n...
Looks correct to me.
Thanks,
but then it doesn't skip fsck when hitting control-c but drops to /sbin/sulogin ?
Maybe fsck doesn't return 32 as it's supposed to. You can verify this by adding `echo fsck returned ${fsckret}' inside that code block in /etc/rc.sysinit. Next time you'll encounter this behavior, you'll know the code returned by fsck. From there, you might be able to troubleshoot this issue further.
Sorry to bother you all! But a bug opened by me (on the subject of fsck at sysinit), http://bugs.archlinux.org/task/16473 is still open what is the status on this one? (A summary of the bug: if /dev/stdout does not exist on the disk at boot-up (as was in case of a fresh install with 2009.08), then the redirection of fsck fails, but with the error code 1, which is treated like a success.) Thanks, Ciprian.
Tom wrote:
While it is a hair misleading, entering the root password at this point gets you to your system.
No, it does not. You get dropped to a promt, I don't know which 'init-level' its on, but it generally does not get you to your system like a normal boot.
Single user is the init level your on
Also, to shut off automatic fsck at boot. From `man fsck`: Filesystems with a fs_passno value of 0 are skipped and are not checked at all.
I don't want to turn off the automatic check, I just think(among a few other things) that this test should be easily skip-able. The startup-script behaves very 'dumbly ' at said point, IMHO.
I neither know enough to 'fix' this kind of thing myself, nor do I really have the time. I know very well that this is a community distro, and that its wrong to rant, but I did put it in '**' ;)
Also I don't agree that it is right to be silent (not file bug reports) just for the sake of 'politeness'
Tom, I just tried Control-C during a regularly scheduled fsck on my system and it stopped the fsck and booted normally, so that should have worked for you.
Am Fri, 15 Jan 2010 20:12:09 -0500 schrieb Alexander Lam <lambchop468@gmail.com>:
I just tried Control-C during a regularly scheduled fsck on my system and it stopped the fsck and booted normally, so that should have worked for you.
And if fsck couldn't be stopped by Ctrl-C this would be an upstream issue and has nothing to do with Arch's initscripts anyway. The only thing /etc/rc.sysinit does is to call fsck. Btw., as far as I know it's not necessary to set fs_passno to >0 for journalling file systems because they have such a feature included so that they detect if a file system wasn't cleanly unmounted and fix it by themselves. At least I hadn't had any problems with ext3 and fs_passno=0 yet. Greetings, Heiko
Tom wrote:
I was just forced to waste 10 min of my life because of arch-linux-way 'of doing things'.
*rant mode on* Let me elaborate, for quite some time now, I've been unappeased by the way arch-linux handles the boot-up process, not so much by how it actually does it (it normally gets the job done) but more the fact that there's little to no obvious way of checking on it when things do go wrong.
I've not been able to boot my custom compiled kernels since pathes 32.2 and 32.3, I don't know why, the config is identical to my running 32. I am at a loss.
Anyway just now, I rebooted, tested yet another kernel, which failed of course, just to be sat in front of my kms-enabled high-resolution tty1 telling me that my home-partition needed checking after 34 mounts. Nice feature, normally I wouldn't bother, but I was in a hurry, so I hit ctrl-c, and bang 'fsck failed' - well yes it did, because I wanted it to, - dumbass, well I go and hit 'Control-D' to continue, and lo and behold the machine reboots, just to get on my nerves again with the fsck the next round through. I accepted defeat then, and went and made myself a nice hot cup of tee,
BUT dear arch community, this is something I hate and find so wrong on so many levels I cannot begin to describe them all, even m$ offered a way to skip these things most of the time...) *rant mode off*
Seriously I find the systems behaviour offensive, I should be in control, not some half-baked script. This is exactly the same reason that I had to sit through fsck regulary a while back(2.6.30 or 2.6.31), because of some bug regarding ext4-partitions(the timestamp in future error), not really because of the bug, but because of the inflexibility of arch linux boot up scriptures.
Where to go, to file that bug...
Tom
I use jfs so a fsck takes very little time. You may want to try it too.
On Fri, Jan 15, 2010 at 1:53 PM, Baho Utot <baho-utot@columbus.rr.com> wrote:
Tom wrote:
and went and made myself a nice hot cup of tee,
I use jfs so a fsck takes very little time. You may want to try it too.
...and ext4 takes about 7 seconds to fsck my 120GB root partition. Hardly an issue IMO.
participants (8)
-
Aaron Griffin
-
Alexander Lam
-
Baho Utot
-
Ciprian Dorin, Craciun
-
Evangelos Foutras
-
Heiko Baums
-
Thayer Williams
-
Tom