public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Tapani Tarvainen <ipfire@tapanitarvainen.fi>
To: development@lists.ipfire.org
Subject: Re: Core126 udevd problem
Date: Wed, 02 Jan 2019 19:39:33 +0200	[thread overview]
Message-ID: <20190102173933.GB23458@tarvainen.info> (raw)
In-Reply-To: <25C0AEF1-41E8-4DB2-AA39-DE30F09B7BD0@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 2128 bytes --]

Indeed, restoring /etc/modprobe.d/framebuffer.conf fixed it - thank you!

(As noted the machine boots off a CF card and I have another machine with
card reader so editing it is easy.)

That leads to a followup question, however: how can I prevent this
from happening again with next upgrade, and with other machines that
are likely to have the same issue? Guess I could add a custom boot
script that runs before udev start and blacklists it again - any
better ideas?

Regards,

-- 
Tapani

On Wed, Jan 02, 2019 at 05:24:01PM +0000, Michael Tremer (michael.tremer(a)ipfire.org) wrote:
> 
> Hello,
> 
> I think you might be running into this:
> 
> https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=4c76d08b2a1ef5ac9ff8b546c0d887e342adec1c
> 
> The framebuffer driver is no longer blacklisted and that causes the kernel to crash on my VIA devices.
> 
> You can mount the hard drive in a different computer and edit the file manually if that is an option for you.
> 
> Best,
> -Michael
> 
> > On 2 Jan 2019, at 17:13, Tapani Tarvainen <ipfire(a)tapanitarvainen.fi> wrote:
> > 
> > Core126 upgrade killed a machine: boot freezes after udevd start.
> > 
> > Experimenting with fresh (flash) installation image (and new CF card)
> > gave same result.
> > 
> > Up to and including core125 it works like charm (also tested with a
> > fresh image).
> > 
> > This is a bit difficult to debug: the last message displayed is
> > 
> > "Starting udev daemon...   [ OK ]"
> > 
> > After that even keyboard is dead (caps lock doesn't work, nor alt-ctrl-del).
> > 
> > And as this happens before disks are mounted, there's no log to read.
> > 
> > This is a rather old machine, VIA C3 CPU, 512MB RAM, booting of CF card,
> > but there's nothing obviously wrong with the hardware, and as noted it
> > worked just fine up to and including core125.
> > 
> > I could leave it running core125, but a firewall that can't be upgraded
> > is not a workable long-term proposition.
> > 
> > Any suggestions as to how I could try to track the problem down?
> > 
> > -- 
> > Tapani Tarvainen

  reply	other threads:[~2019-01-02 17:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-02 17:13 Tapani Tarvainen
2019-01-02 17:24 ` Michael Tremer
2019-01-02 17:39   ` Tapani Tarvainen [this message]
2019-01-02 17:46     ` Michael Tremer
2019-01-02 17:54       ` Tapani Tarvainen

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=20190102173933.GB23458@tarvainen.info \
    --to=ipfire@tapanitarvainen.fi \
    --cc=development@lists.ipfire.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox