blog/tags/bootsystem/bootsystem.rss

   1 <?xml version="1.0" encoding="utf-8"?>
   2 <rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/'>
   3         <channel>
   4                 <title>Petter Reinholdtsen - Entries tagged bootsystem</title>
   5                 <description>Entries tagged bootsystem</description>
   6                 <link>http://people.skolelinux.org/pere/blog/</link>
   7
   8
   9         <item>
  10                 <title>Parallellized boot is now the default in Debian/unstable</title>
  11                 <link>http://people.skolelinux.org/pere/blog/Parallellized_boot_is_now_the_default_in_Debian_unstable.html</link>
  12                 <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Parallellized_boot_is_now_the_default_in_Debian_unstable.html</guid>
  13                 <pubDate>Fri, 14 May 2010 22:40:00 +0200</pubDate>
  14                 <description>
  15 &lt;p&gt;Since this evening, parallel booting is the default in
  16 Debian/unstable for machines using dependency based boot sequencing.
  17 Apparently the testing of concurrent booting has been wider than
  18 expected, if I am to believe the
  19 &lt;a href=&quot;http://lists.debian.org/debian-devel/2010/05/msg00122.html&quot;&gt;input
  20 on debian-devel@&lt;/a&gt;, and I concluded a few days ago to move forward
  21 with the feature this weekend, to give us some time to detect any
  22 remaining problems before Squeeze is frozen.  If serious problems are
  23 detected, it is simple to change the default back to sequential boot.
  24 The upload of the new sysvinit package also activate a new upstream
  25 version.&lt;/p&gt;
  26
  27 More information about
  28 &lt;a href=&quot;http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot&quot;&gt;dependency
  29 based boot sequencing&lt;/a&gt; is available from the Debian wiki.  It is
  30 currently possible to disable parallel booting when one run into
  31 problems caused by it, by adding this line to /etc/default/rcS:&lt;/p&gt;
  32
  33 &lt;blockquote&gt;&lt;pre&gt;
  34 CONCURRENCY=none
  35 &lt;/pre&gt;&lt;/blockquote&gt;
  36
  37 &lt;p&gt;If you report any problems with dependencies in init.d scripts to
  38 the BTS, please usertag the report to get it to show up at
  39 &lt;a href=&quot;http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=initscripts-ng-devel@lists.alioth.debian.org&quot;&gt;the
  40 list of usertagged bugs related to this&lt;/a&gt;.&lt;/p&gt;
  41 </description>
  42         </item>
  43
  44         <item>
  45                 <title>Parallellized boot seem to hold up well in Debian/testing</title>
  46                 <link>http://people.skolelinux.org/pere/blog/Parallellized_boot_seem_to_hold_up_well_in_Debian_testing.html</link>
  47                 <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Parallellized_boot_seem_to_hold_up_well_in_Debian_testing.html</guid>
  48                 <pubDate>Thu, 27 May 2010 23:55:00 +0200</pubDate>
  49                 <description>
  50 &lt;p&gt;A few days ago, parallel booting was enabled in Debian/testing.
  51 The feature seem to hold up pretty well, but three fairly serious
  52 issues are known and should be solved:
  53
  54 &lt;p&gt;&lt;ul&gt;
  55
  56 &lt;li&gt;The wicd package seen to
  57 &lt;a href=&quot;http://bugs.debian.org/508289&quot;&gt;break NFS mounting&lt;/a&gt; and
  58 &lt;a href=&quot;http://bugs.debian.org/581586&quot;&gt;network setup&lt;/a&gt; when
  59 parallel booting is enabled.  No idea why, but the wicd maintainer
  60 seem to be on the case.&lt;/li&gt;
  61
  62 &lt;li&gt;The nvidia X driver seem to
  63 &lt;a href=&quot;http://bugs.debian.org/583312&quot;&gt;have a race condition&lt;/a&gt;
  64 triggered more easily when parallel booting is in effect.  The
  65 maintainer is on the case.&lt;/li&gt;
  66
  67 &lt;li&gt;The sysv-rc package fail to properly enable dependency based boot
  68 sequencing (the shutdown is broken) when old file-rc users
  69 &lt;a href=&quot;http://bugs.debian.org/575080&quot;&gt;try to switch back&lt;/a&gt; to
  70 sysv-rc.  One way to solve it would be for file-rc to create
  71 /etc/init.d/.legacy-bootordering, and another is to try to make
  72 sysv-rc more robust.  Will investigate some more and probably upload a
  73 workaround in sysv-rc to help those trying to move from file-rc to
  74 sysv-rc get a working shutdown.&lt;/li&gt;
  75
  76 &lt;/ul&gt;&lt;/p&gt;
  77
  78 &lt;p&gt;All in all not many surprising issues, and all of them seem
  79 solvable before Squeeze is released.  In addition to these there are
  80 some packages with bugs in their dependencies and run level settings,
  81 which I expect will be fixed in a reasonable time span.&lt;/p&gt;
  82
  83 &lt;p&gt;If you report any problems with dependencies in init.d scripts to
  84 the BTS, please usertag the report to get it to show up at
  85 &lt;a href=&quot;http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=initscripts-ng-devel@lists.alioth.debian.org&quot;&gt;the
  86 list of usertagged bugs related to this&lt;/a&gt;.&lt;/p&gt;
  87
  88 &lt;p&gt;Update: Correct bug number to file-rc issue.&lt;/p&gt;
  89 </description>
  90         </item>
  91
  92         <item>
  93                 <title>KDM fail at boot with NVidia cards - and no one try to fix it?</title>
  94                 <link>http://people.skolelinux.org/pere/blog/KDM_fail_at_boot_with_NVidia_cards___and_no_one_try_to_fix_it_.html</link>
  95                 <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/KDM_fail_at_boot_with_NVidia_cards___and_no_one_try_to_fix_it_.html</guid>
  96                 <pubDate>Tue, 1 Jun 2010 17:05:00 +0200</pubDate>
  97                 <description>
  98 &lt;p&gt;It is strange to watch how a bug in Debian causing KDM to fail to
  99 start at boot when an NVidia video card is used is handled.  The
 100 problem seem to be that the nvidia X.org driver uses a long time to
 101 initialize, and this duration is longer than kdm is configured to
 102 wait.&lt;/p&gt;
 103
 104 &lt;p&gt;I came across two bugs related to this issue,
 105 &lt;a href=&quot;http://bugs.debian.org/583312&quot;&gt;#583312&lt;/a&gt; initially filed
 106 against initscripts and passed on to nvidia-glx when it became obvious
 107 that the nvidia drivers were involved, and
 108 &lt;a href=&quot;http://bugs.debian.org/524751&quot;&gt;#524751&lt;/a&gt; initially filed against
 109 kdm and passed on to src:nvidia-graphics-drivers for unknown reasons.&lt;/p&gt;
 110
 111 &lt;p&gt;To me, it seem that no-one is interested in actually solving the
 112 problem nvidia video card owners experience and make sure the Debian
 113 distribution work out of the box for these users.  The nvidia driver
 114 maintainers expect kdm to be set up to wait longer, while kdm expect
 115 the nvidia driver maintainers to fix the driver to start faster, and
 116 while they wait for each other I guess the users end up switching to a
 117 distribution that work for them.  I have no idea what the solution is,
 118 but I am pretty sure that waiting for each other is not it.&lt;/p&gt;
 119
 120 &lt;p&gt;I wonder why we end up handling bugs this way.&lt;/p&gt;
 121 </description>
 122         </item>
 123
 124         <item>
 125                 <title>Upstart or sysvinit - as init.d scripts see it</title>
 126                 <link>http://people.skolelinux.org/pere/blog/Upstart_or_sysvinit___as_init_d_scripts_see_it.html</link>
 127                 <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Upstart_or_sysvinit___as_init_d_scripts_see_it.html</guid>
 128                 <pubDate>Sun, 6 Jun 2010 23:55:00 +0200</pubDate>
 129                 <description>
 130 &lt;p&gt;If Debian is to migrate to upstart on Linux, I expect some init.d
 131 scripts to migrate (some of) their operations to upstart job while
 132 keeping the init.d for hurd and kfreebsd.  The packages with such
 133 needs will need a way to get their init.d scripts to behave
 134 differently when used with sysvinit and with upstart.  Because of
 135 this, I had a look at the environment variables set when a init.d
 136 script is running under upstart, and when it is not.&lt;/p&gt;
 137
 138 &lt;p&gt;With upstart, I notice these environment variables are set when a
 139 script is started from rcS.d/ (ignoring some irrelevant ones like
 140 COLUMNS):&lt;/p&gt;
 141
 142 &lt;blockquote&gt;&lt;pre&gt;
 143 DEFAULT_RUNLEVEL=2
 144 previous=N
 145 PREVLEVEL=
 146 RUNLEVEL=
 147 runlevel=S
 148 UPSTART_EVENTS=startup
 149 UPSTART_INSTANCE=
 150 UPSTART_JOB=rc-sysinit
 151 &lt;/pre&gt;&lt;/blockquote&gt;
 152
 153 &lt;p&gt;With sysvinit, these environment variables are set for the same
 154 script.&lt;/p&gt;
 155
 156 &lt;blockquote&gt;&lt;pre&gt;
 157 INIT_VERSION=sysvinit-2.88
 158 previous=N
 159 PREVLEVEL=N
 160 RUNLEVEL=S
 161 runlevel=S
 162 &lt;/pre&gt;&lt;/blockquote&gt;
 163
 164 &lt;p&gt;The RUNLEVEL and PREVLEVEL environment variables passed on from
 165 sysvinit are not set by upstart.  Not sure if it is intentional or not
 166 to not be compatible with sysvinit in this regard.&lt;/p&gt;
 167
 168 &lt;p&gt;For scripts needing to behave differently when upstart is used,
 169 looking for the UPSTART_JOB environment variable seem to be a good
 170 choice.&lt;/p&gt;
 171 </description>
 172         </item>
 173
 174         </channel>
 175 </rss>