[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mandrake-cooker
Subject:    Re: [Cooker] rebuild an initrd under rescue cdrom
From:       Pascal Cavy <pascal () vmfacility ! fr>
Date:       2003-04-02 9:37:56
[Download RAW message or body]

Le Mercredi 2 Avril 2003 09:24, Thierry Vignaud a écrit :
> Gary Greene <greeneg@student.gvsu.edu> writes:
> > > > First I was to mount /proc because mkinitrd _does not check_
> > > > that /proc is available and thus we end in a loop at the step it
> > > > scans for /proc/mounts FS.
> > >
> > > I don't consider that to be a bug. Many (all?) of our system
> > > tools rely very much on /proc being available. I'm not even sure
> > > the system will boot without a /proc filesystem mounted.
> >
> > Oh, it WILL boot, but not kindly...
> >
> > Can I suggest that all Mandrake apps (since this test would be
> > almost trivial) with the need to access /proc at least please have a
> > check and warning message included so the n00b that gets his new
> > linux system almost running and the theoretical chance that the
> > mkinitrd util is as broken as it was then won't be pulling their
> > hair out in frustration?
>
> so many apps rely on /proc being mounted (which may even be required
> by fsstnd, fhs or/and lsb) that if we've to choose between altering
> 1000 tools or mounting /proc by default, i would choose the later.
>
> which is what we choose to do.
>
> my 2 cents.
>
>
> there's quite some stuff that one can expect to have. it's good to
> test for stuff in configure and the like places, but testing many
> features[1] availlability in all programs is more bug prone and
> hackward than relying on having these features as defined per
> standards.
>
>
> [1] eg: /proc/ mounted, dynamic loader, ipc, unix domain sockets,
>     ... and whatever you can imagine 99.999% people use and that you
>     do not check about.

ho, I really don't fully agree here. 

First some stuff _has_ to be tested before use. This is the same kind of 
behaviour as people that don't put passwords on their intranet because they 
assume their firewall protect them. The same when people program a backup 
script and 'assume' that their /backup directory is mounted (why won't it be 
? ;) and end up with a full / directory and frozen system...

Second, of course, we don't have to check for trivial stuff or everytime. But 
when someone find a particular condition when the test (trivial) could be 
done and lessen future debug time, then the test _should_ be introduced 

Scripts that are part of an installation process are particularly sensitive to 
the environnement, especially when migrating where you don't exactly know 
where you lay your feet :@ 
A missing test can lead to an incomplete installation without giving the exact 
source of the problem. This, once detected, has to be considered a bug and 
fixed.

In the particular case here, (mkinitrd) should have exited with an error 
message instead of filling the ddebug.log with an error message like "awk: 
cmd. line:2: fatal: cannot open file `/proc/mounts' for reading (No such file 
or directory)" and finally rendering the upgrade impossible.

-- 
Pascal Cavy - VMF
__________________________________________________________________
Running 21:22,  4 users,  load average: 3.56, 3.31, 3.29
(gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk))
Kernel Linux version 2.4.21-0.13mdkenterprise



[prev in list] [next in list] [prev in thread] [next in thread]