| 1 |
Apparently, though unproven, at 08:49 on Thursday 20 January 2011, Matthias |
| 2 |
Fechner did opine thusly: |
| 3 |
|
| 4 |
> Hi, |
| 5 |
> |
| 6 |
> On 20.01.11 04:35, John Campbell wrote: |
| 7 |
> > I had that problem or something similar some time ago when updating to |
| 8 |
> > the new, at the time, pata drivers. I ended up using a brute force |
| 9 |
> > technique... I booted grub to it's built in shell and used it's limited |
| 10 |
> > tools to figure out which partition/drive was which and editing the |
| 11 |
> > kernel/initrd lines to get the system to boot to init level 1 and then |
| 12 |
> > make the changes permanent in grub and fstab. |
| 13 |
> |
| 14 |
> ok, I found now the problem, it was a combination of a missing driver |
| 15 |
> and a new device name (changed from sdc to sde). |
| 16 |
> |
| 17 |
> But really it cannot be that it is impossible to scroll the kernel |
| 18 |
> messages up? Is there really no way existing to get to the message above? |
| 19 |
> And take a camera is absolutely impossible, from grub to kernel panic it |
| 20 |
> takes around 1 second, that is faster then the display to switch the to |
| 21 |
> the correct output mode. |
| 22 |
|
| 23 |
The whole point of a panic is that the kernel stops executing code. It has to, |
| 24 |
something has gone badly wrong and it's too risky to continue execution of |
| 25 |
anything. |
| 26 |
|
| 27 |
Scrolling up involves running some code. You can't have it both ways. |
| 28 |
|
| 29 |
-- |
| 30 |
alan dot mckinnon at gmail dot com |
Archives