Thread: Kernel panic during upgrade, and ensuing unpleasantness

my new starling arrived today, looking ever cute. played around bit, , seemed working fine. noticing package definitions month out of date, told update notifier check updates , upgrade hundred-some-odd eligible packages. downloading them went fine, halfway through installation, machine froze solid. screen went black blinking white cursor , caps lock light flashed slowly. couldn't switch vt, nor reboot magic sysrq commands. therefore, i'm guessing kernel panic.

hit power button reboot. os seemed come okay, keyboard , trackpad inoperative @ login screen. managed vt first setting keyboard raw mode (alt-sysrq-r) , switching tty1 (ctrl-alt-f1). there, completed update `sudo dpkg --configure -a`. worked, except needed download complete installation of new kernel. (i'm puzzled this, since seemed have been downloaded before upgrade started.) plugged in ethernet cord , re-ran dpkg command.

reboot later , login screen still locked up. luckily, solution this post thomasaaron worked me. (i ran commands sudo vt instead of using recovery mode.)

reboot , log in. wireless wasn't working. network connections icon wasn't showing wireless device @ all, , `ifconfig` wasn't listing wlan0. this thread suggested new kernel blame, tried rebooting older kernel. didn't improve (other network connections icon listed wireless device, informed me wasn't configured). after few dead ends (including reinstalling system76 drivers), recalled problems had upgrading kernel, thought reinstall packages. decided reinstall recent linux-headers , linux-image packages (linux-headers-2.6.31-19, linux-headers-2.6.31-19-generic, , linux-image-2.6.31-19-generic, in case) through synaptic (right click , select "mark reinstallation"). 1 final reboot, , seems working again.

why posting story, if everything's working?

1. i wanted check if update notifier right way go updating them machine. there system76-specific way should know about?
2. i wanted post solutions in case save else these headaches.
3. i wanted alert system76 these problems, in case can prevent them in future.
4. finally, have few suggestions mitigating these problems. don't know if they're @ feasible, here are:
   
   • system76 perform dist-upgrade before shipping machine. both give them chance see these problems, decrease likelihood of users running them later (as users not have upgrade).
   • installing system76 driver trigger reinstallation of current kernel packages. notice there seems additional actions hooked onto kernel installation seem related drivers; might ensure gets run when drivers updated.
   • perhaps system76 host own versions of kernel have these additional drivers built in, there doesn't have additional, unexpectedly late download during upgrade process.

hope of use someone.

1. wanted check if update notifier right way go updating them machine. there system76-specific way should know about?

update manager fine.

2. wanted post solutions in case save else these headaches.

always great idea.

3. wanted alert system76 these problems, in case can prevent them in future.

we're aware of issue. a) doesn't seem happen across board, , b) we've not yet been able isolate it.

4. finally, have few suggestions mitigating these problems. don't know if they're @ feasible, here are:
* system76 perform dist-upgrade before shipping machine. both give them chance see these problems, decrease likelihood of users running them later (as users not have upgrade).

we update our imaging server whenever new *kernel* update comes down pike. however, there naturally lag between update becoming available, testing (and solving problems), , server image being updated.

updating image every time *general* update comes down pike, though, prohibitively time consuming, running updates individually on every machine. believe *did* in days, when one-at-a-timing machines. producing on larger scale, , streamlining has become important... , somewhere along line running individual updates on every machine fell out of fashion.

said, bring managers. idea isn't bad 1 @ all.

in case, there seems have been problems -19 kernel. , since customers updating, it's inevitable if there bug, customers experience before we've finished testing... see updates same time do.

* installing system76 driver trigger reinstallation of current kernel packages. notice there seems additional actions hooked onto kernel installation seem related drivers; might ensure gets run when drivers updated.

that's excellent point. here's you're seeing. we're doing experiment (and trying refine it): under 9.04, kernel updates break wireless driver (which compiled against kernel). want fix. it's ridiculous customers' wireless die every time there's update, hooked in re-compilation of wireless driver after kernel updates. has largely been successful, *may* playing other problems. we're still working on it. if have insight or suggestions, please direct them support...at...system76...dot...com , i'll fwd them driver guys.

* perhaps system76 host own versions of kernel have these additional drivers built in, there doesn't have additional, unexpectedly late download during upgrade process.

that 1 has been mentioned before, has been categorically ruled out. our goal feed our fixes upstream ubuntu that, day, systems need no system76 driver. feel hosting our own kernels counter purpose. (albeit, provide short-term solution issues... yet create heavier workload us.)

Forum The Ubuntu Forum Community Ubuntu Specialised Support System76 Support Kernel panic during upgrade, and ensuing unpleasantness

Ubuntu