On Thursday 16 June 2011 19:49:13 Ithamar R. Adema wrote:
> Hi,
>
> On Thu, 2011-06-16 at 12:21 +0200, Jo-Philipp Wich wrote:
> > Maybe calling "reboot" at all is not such a great idea as it attempts
> > to run the (former) init scripts to stop them.
>
> Maybe using we should use 'reboot -f' here
On Fri, 2011-06-17 at 22:54 +0100, Aleksandar Radovanovic wrote:
> On 06/17/2011 11:49 AM, D.S. Ljungmark wrote:
> > On Thu, 2011-06-16 at 19:49 +0200, Ithamar R. Adema wrote:
> >> Hi,
> >>
> >> On Thu, 2011-06-16 at 12:21 +0200, Jo-Philipp Wich wrote:
> >>> Maybe calling "reboot" at all is not suc
On Fri, 2011-06-17 at 22:54 +0100, Aleksandar Radovanovic wrote:
>
> The code is quite ugly at the moment, has some bits that are specific
> to my needs, isn't very modular (target-wise) and so needs a lot of
> cleanup. I'm currently up to my eyeballs with my regular job, so can't
> really spare t
Hi,
On Fri, 2011-06-17 at 22:54 +0100, Aleksandar Radovanovic wrote:
> The code is quite ugly at the moment, has some bits that are specific
> to my needs, isn't very modular (target-wise) and so needs a lot of
> cleanup. I'm currently up to my eyeballs with my regular job, so can't
> really spare
On 06/17/2011 10:54 PM, Aleksandar Radovanovic wrote:
On 06/17/2011 11:49 AM, D.S. Ljungmark wrote:
On Thu, 2011-06-16 at 19:49 +0200, Ithamar R. Adema wrote:
Hi,
On Thu, 2011-06-16 at 12:21 +0200, Jo-Philipp Wich wrote:
Maybe calling "reboot" at all is not such a great idea as it
attempts to
On 06/17/2011 11:49 AM, D.S. Ljungmark wrote:
> On Thu, 2011-06-16 at 19:49 +0200, Ithamar R. Adema wrote:
>> Hi,
>>
>> On Thu, 2011-06-16 at 12:21 +0200, Jo-Philipp Wich wrote:
>>> Maybe calling "reboot" at all is not such a great idea as it
>>> attempts to run the (former) init scripts to stop th
On Thu, 2011-06-16 at 19:49 +0200, Ithamar R. Adema wrote:
> Hi,
>
> On Thu, 2011-06-16 at 12:21 +0200, Jo-Philipp Wich wrote:
> > Maybe calling "reboot" at all is not such a great idea as it attempts
> > to run the (former) init scripts to stop them.
>
> Maybe using we should use 'reboot -f' he
Hi,
On Thu, 2011-06-16 at 12:21 +0200, Jo-Philipp Wich wrote:
> Maybe calling "reboot" at all is not such a great idea as it attempts
> to run the (former) init scripts to stop them.
Maybe using we should use 'reboot -f' here, as that will skip all
userland 'shutdown' handling and simply call th
The obvious next step is to find out where it crashes exactly -
"set -x" might help with that. I suppose its when it tries to call into
(former) system resources.
Maybe calling "reboot" at all is not such a great idea as it attempts to
run the (former) init scripts to stop them.
~ Jow
__
On Wed, 2011-06-15 at 20:27 +0200, Jo-Philipp Wich wrote:
> Maybe it already helps to enable SysRq support in your builds.
> Sysupgrade tries to trigger a system reset through it if its still alive
> 10 seconds after calling "reboot".
And now I see that Magic SysRQ was already there, and the syst
On Wed, 2011-06-15 at 20:27 +0200, Jo-Philipp Wich wrote:
> Maybe it already helps to enable SysRq support in your builds.
> Sysupgrade tries to trigger a system reset through it if its still alive
> 10 seconds after calling "reboot".
Okay, good to know, I'll try in todays rebuild and test.
Anyth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Maybe it already helps to enable SysRq support in your builds.
Sysupgrade tries to trigger a system reset through it if its still alive
10 seconds after calling "reboot".
~ Jow
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment:
So,
I'm trying to use sysupgrade on an x86-system with the mtd_block
driver, and intermittently it fails rather spectacularly to reboot the
machine afterwards:
log from ssh shows:
Switching to ramdisk...
mount: mounting mini_fo:/overlay on /mnt failed: Function not
imple
13 matches
Mail list logo
