All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jurij Smakov <jurij@wooyd.org>
To: sparclinux@vger.kernel.org
Subject: Re: silo trouble with ext3
Date: Tue, 21 Feb 2012 22:51:08 +0000	[thread overview]
Message-ID: <20120221225108.GA4293@wooyd.org> (raw)
In-Reply-To: <alpine.SOC.1.00.1202211523260.24120@math.ut.ee>

On Tue, Feb 21, 2012 at 02:36:40PM -0500, David Miller wrote:
> From: Meelis Roos <mroos@linux.ee>
> Date: Tue, 21 Feb 2012 15:43:07 +0200 (EET)
> 
> > Short summary: silo can not find any files from my ext3. Was this 
> > the problem recently discussed here about silo?
> > 
> > Debian unstable's silo 1.4.14+git20120127-1 and 110G ext3 filesystem. 
> > The same machine worked fine for years, running all the kernels and 
> > Debian unstable. Last successful reboot was less than a week ago, and 
> > Debian was updated after that (probably updating silo package).
> > Today I compiled 3.3-rc4+git and rebooted to try it, and silo can not 
> > find anything. silo itself loads but can not open neither /etc/silo.conf 
> > nor any kernel image by direct name:
> 
> I really wish they hadn't pushed this new SILO into debian without a
> couple months more testing of the new ext{2,3,4} code I wrote.

That would be my handywork :-).

> I knew there would be regressions like this and it's not ready at all
> for mass consumption.

To clarify, the new SILO has only appeared in Debian testing (wheezy) 
and unstable (sid) distributions and not in the released version 
(squeeze), to which it will never propagate. I've announced new SILO 
availability for early testing a few days before uploading it to 
unstable [0] and then it spent the usual 10 days in unstable before 
propagating to testing [1] (any bug reported against the new version 
during that time would have blocked this propagation). 

If needed, the version can be rolled back pretty easily in 
testing/unstable (will take just a couple of days), but that will 
minimize the chances of the new version getting any mileage. Given 
that the next Debian release is something like 6 months to a year away 
and the fixes will be forthcoming sooner than that :-), I don't really 
see a reason to do such a rollback, especially considering that vast 
majority of the Debian sparc users, who followed the default 
installation procedure, will not be affected by it. Default install 
still creates a small ext2 partition at the beginning of the disk for 
kernels and initrds (legacy of the sparc32 days, when kernel would 
refuse to boot if it was further than 1GB away from the beginning of 
the disk, or something like that). That was the reason why I did not 
get any problem reports and have not seen any problems on my machine. 

Meelis, sorry for the trouble. You can restore your machine's ability 
to boot by installing the stable SILO version [2]. Please let me know 
off-list if you would like more detailed recovery instructions.

[0] http://lists.debian.org/debian-sparc/2012/01/msg00038.html
[1] http://packages.qa.debian.org/s/silo.html
[2] http://ftp.ie.debian.org/debian/pool/main/s/silo/silo_1.4.14+git20100228-1+b1_sparc.deb

Best regards,
-- 
Jurij Smakov                                           jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC

  parent reply	other threads:[~2012-02-21 22:51 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-21 13:43 silo trouble with ext3 Meelis Roos
2012-02-21 18:03 ` crn
2012-02-21 19:36 ` David Miller
2012-02-21 19:50 ` David Miller
2012-02-21 22:40 ` David Miller
2012-02-21 22:51 ` Jurij Smakov [this message]
2012-02-21 23:10 ` David Miller
2012-02-21 23:33 ` David Miller
2012-02-22  1:27 ` David Miller
2012-02-22  7:22 ` Meelis Roos
2012-02-22  7:26 ` David Miller
2012-02-22  7:32 ` Meelis Roos
2012-02-22  7:45 ` David Miller
2012-02-22 21:47 ` Jurij Smakov
2012-02-23  6:05 ` mroos
2012-02-23  6:52 ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120221225108.GA4293@wooyd.org \
    --to=jurij@wooyd.org \
    --cc=sparclinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.