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
next prev parent 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