From noreply at ubuntu.com Tue Jul 5 03:55:42 2016 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Tue, 05 Jul 2016 03:55:42 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22Debug_Symbol_Packages=22_by_cmil?= =?utf-8?q?ler?= Message-ID: <20160705035542.14698.59206@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "Debug Symbol Packages" page has been changed by cmiller: http://wiki.ubuntu.com/Debug%20Symbol%20Packages?action=diff&rev1=3&rev2=4 Comment: > W: GPG error: http://ddebs.ubuntu.com/ubuntu xenial-updates Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY C8CAB6595FDFF622 1. Import the debug symbol archive [[https://help.ubuntu.com/community/Repositories/Ubuntu#Authentication_Tab|signing key]] from the ubuntu server: {{{#!highlight bash - sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 428D7C01 + sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 428D7C01 C8CAB6595FDFF622 }}} 1. Then run the following to update your package list or click the ''Reload'' button if you used the Synaptic Package Manager. From tsimonq2 at ubuntu.com Fri Jul 15 05:05:57 2016 From: tsimonq2 at ubuntu.com (Simon Quigley) Date: Fri, 15 Jul 2016 00:05:57 -0500 Subject: [ANN] Lubuntu Bug Day Message-ID: <57886F35.6080008@ubuntu.com> Greetings, My name is Simon Quigley and I am a member of the Lubuntu Team. The Lubuntu team is running a bug day on Tuesday, July 26, 2016. It’s a spin of a hug day. We will have an Ubuntu On Air session on Monday, July 25, 2016 from 19 to 20 UTC. I will give a presentation for the first half, then for the second half, I will be joined by Walter Lapchynski and we will answer questions provided to us over IRC. I strongly recommend that you either attend the session or watch the archive, because we might answer a question that you have. To attend, go to http://ubuntuonair.com/ during the date/time I listed above. What’s a Hug day? >From the Ubuntu Bug Day wiki page[1]: "A Hug Day is a special day where the Ubuntu Community comes together with a shared goal of triaging bugs for a specific package or set of packages. Working together allows us to share knowledge and give some much needed assistance to the Ubuntu Developers. The term Hug Day is a spin on Bug Day; every time someone triages a bug, then someone else should hug him/her. Why? This is a very special way for us to tell everyone that we love contributions! And triaging bugs is a really big contribution." What bugs are we targeting? The Lubuntu team has a team called the Lubuntu Packages Team[2]. It was created to help track all the bugs related to Lubuntu, and it is a very useful team for subscribing to all of the Lubuntu-related bugs. We would like to ensure that this team stays up to date with all the Lubuntu bugs, so we can make sure that our development team has an eye on them. To do this, we need to go through the following steps: 1. Find a bug that affects software preinstalled in Lubuntu. 2. Triage[3] the bug accordingly, and if it still exists in a reproducible state, subscribe the Lubuntu packages team. 3. Add the bug to our known bugs list[4]. Where is the communication for this event happening? Join the #lubuntu-devel channel on freenode, this is the Lubuntu team’s IRC channel, and people will be around to help. If you don’t have an IRC client, Kiwi IRC is a decent web client: http://kiwiirc.com/client/irc.freenode.net/#lubuntu-devel If you have any questions, don't hesitate to visit our IRC channel or send me an email. I hope to see you there! [1] https://wiki.ubuntu.com/UbuntuBugDay [2] https://bugs.launchpad.net/~lubuntu-packaging [3] https://wiki.ubuntu.com/Bugs/Triage [4] https://wiki.ubuntu.com/Lubuntu/KnownBugs -- Simon Quigley tsimonq2 at ubuntu.com tsimonq2 on Freenode From webmaster at ubuntu.com Sat Jul 23 19:14:38 2016 From: webmaster at ubuntu.com (Help Ubuntu) Date: Sat, 23 Jul 2016 19:14:38 -0000 Subject: =?utf-8?q?=5BCommunity_Help_Wiki=5D_Update_of_=22ReportingBugs=22_by_pena?= =?utf-8?q?lvch?= Message-ID: <20160723191438.32658.1255@jostaberry.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Community Help Wiki" for change notification. The "ReportingBugs" page has been changed by penalvch: http://help.ubuntu.com/community/ReportingBugs?action=diff&rev1=292&rev2=293 Comment: Migrated BIOS FAQs to BIOSUpdate to tighten up this article. == Hardware bug reports (linux kernel, xorg, sound, etc.) == - * '''Before filing your report, please update your BIOS, and hardware firmware (CF card readers, SSDs, USB 3.0 controllers, DVD/CD drives, external USB drives, etc.) to the newest available from your vendor.''' <
> Outdated and buggy BIOS and firmware is a common cause of a variety of issues. For example, freezing after lightDM login, intermittent wireless, suspend/hibernate not working, intermittent touchpad, certain keys on keyboard not working correctly, card readers not working, and kernel panics after plugging USB drive in (this is by no means an exhaustive list). In addition, BIOS updates are for collateral damage avoidance. Here are some statements that don't justify keeping your BIOS outdated: {{{ + * '''Before filing your report, please update your buggy and outdated BIOS, and hardware firmware (CF card readers, SSDs, USB 3.0 controllers, DVD/CD drives, external USB drives, etc.) to the newest available from your vendor.''' <
> Outdated and buggy BIOS and firmware is a common cause of a variety of issues. For example, freezing after lightDM login, intermittent wireless, suspend/hibernate not working, intermittent touchpad, certain keys on keyboard not working correctly, card readers not working, and kernel panics after plugging USB drive in (this is by no means an exhaustive list). In addition, BIOS updates are for collateral damage avoidance. For more on this, please see [[https://help.ubuntu.com/community/BIOSUpdate|here]]. - "It works in Windows, but doesn't in linux, so this isn't caused by my computer's buggy and outdated BIOS." - }}} Buggy BIOS problems may manifest themselves in linux, but not in Windows, and vice versa. <
><
> {{{ - "It doesn't say anything in the release notes about linux/Ubuntu, so I don't need to upgrade my computer's buggy and outdated BIOS." - }}} BIOS vendors typically test and have release note commentary about Windows only, so it wouldn't ever advise on if a problem in linux is resolved by it. <
><
> {{{ - "I didn't change anything in the BIOS, and this problem started happening after restarting from an update, so this is not due to my computer's buggy and outdated BIOS." - }}} Updates to Ubuntu can cause buggy BIOS problems to manifest that the prior version did not. The solution is to update a buggy and outdated BIOS, not rely on unintentional WORKAROUNDs. <
><
> {{{ - "It's Ubuntu's job to provide me a way to update my computer's buggy and outdated BIOS, so I'm not updating." - }}} The responsibility to keep the BIOS updated lies solely with owner of the hardware. However, as a courtesy to the Ubuntu Community, update methods that may not have been offered by your BIOS vendor are available [[https://help.ubuntu.com/community/BiosUpdate|here]]. <
><
> {{{ - "Updating my computer's buggy and outdated BIOS is risky." - }}} Everything one does with any operating system, application, or hardware has some level of risk, from upgrading software (upgrade breaks functionality or security), to servicing hardware (static electricity, accidentally bend/break the hardware, etc.). However, one simply eliminates or largely minimizes these risks with common sense techniques. In the case of a BIOS update, one ensures the power supply is not interrupted during the upgrade. As well, one may contact their computer vendor for further advice. <
><
> {{{ - "I don't feel like updating my computer's buggy and outdated BIOS." - }}} This is not respecting the additional effort triagers and developers would have to put in to not only look at the code to see if it is correct (which is difficult enough), but to also think of all the ways a non-compliant BIOS could manifest problems given the code change. * '''One report, per person, per hardware combination, per bug'''. <
> Many [[https://launchpad.net/ubuntu/+source/linux|Linux]] package, hardware, and other non-user space bugs are hardware dependent on both the hardware itself, and what other hardware the problematic hardware is connected to. For more on this please see [[https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue|here]], and further below in this article. * '''Please do not post comments to another persons report, claiming you have the same or similar hardware or problem.''' <
> Instead, please file a separate report, and make comments there. This is because no one can verify if you would have the same problem or not, because your hardware can not be analyzed. Also, vendors can have different parts under the hood of the same model line. * ''' Please do not attempt to apport-collect to another persons report.''' <
> Running apport-collect when not specifically asked by a triager or developer creates spammy E-Mail traffic for those subscribed, clutters up the bug report with undesired attachments, and hinders the bug getting addressed quickly. As well, your attachments are subject to immediate deletion at the discretion of developers and triagers. Instead, please open a new report via ubuntu-bug. Please note that attempting to run `apport-collect bug_number` against a [[https://launchpad.net/ubuntu/+source/linux|linux]] package bug report, while booted into a [[https://wiki.ubuntu.com/Kernel/MainlineBuilds|mainline]] linux kernel will not work. This is due to how Ubuntu does not provide support for mainline kernels. For more on this, please see [[https://wiki.ubuntu.com/Kernel/MainlineBuilds#Kernel.2BAC8-FAQ.2BAC8-DebuggingMainlineBuildsSupport.Does_the_kernel_team_support_the_mainline_kernel_builds.3F|here]]. From noreply at ubuntu.com Sun Jul 24 20:41:40 2016 From: noreply at ubuntu.com (Ubuntu Wiki) Date: Sun, 24 Jul 2016 20:41:40 -0000 Subject: =?utf-8?q?=5BUbuntu_Wiki=5D_Update_of_=22DebuggingKernelBoot=22_by_penalv?= =?utf-8?q?ch?= Message-ID: <20160724204140.25022.58643@mangaba.canonical.com> Dear Wiki user, You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification. The "DebuggingKernelBoot" page has been changed by penalvch: http://wiki.ubuntu.com/DebuggingKernelBoot?action=diff&rev1=15&rev2=16 Comment: Due to LP#1568429 & others, clarified need log from failed boot (not a working boot). - Unfortunately it is sometimes the case that your system will fail to boot due to changes within the kernel. It is important that when submitting bug reports about these types of failures that you include the appropriate debugging information that can help the kernel team resolve the issue. The following wiki will document some useful tips to capture any relevant information. + Unfortunately it is sometimes the case that your system will fail to boot due to changes within the kernel. It is important that when submitting bug reports about these types of failures that you include the debugging information from a failed boot (not a working boot). This article will help gather this information to provide in your report. - == Boot Options == + = Boot Options = + - When trying to capture relevant error messages that appear at boot it is often useful to boot with the '''quiet''' and '''splash''' options removed. This will hopefully allow you to see any messages that come across your screen. To edit boot option parameters, do the following: + When trying to capture relevant error messages that appear at boot it is often useful to boot with the '''quiet''' and '''splash''' options removed. This will hopefully allow you to see any messages that come across your screen. To edit boot option parameters, do the following: 1. Boot the machine. 1. During the BIOS screen, press the shift key and hold it down. You should see the GRUB menu after the BIOS loads. 1. Navigate to the kernel entry you want to boot, and press 'e'. - 1. Then remove the '''quiet''' and '''splash''' keywords (found in the line starting with linux) + 1. Then remove the '''quiet''' and '''splash''' keywords (found in the line starting with linux). 1. Starting with Natty (Ubuntu 11.04), also remove the parameter '''vt.handoff=7''', and on the line that reads '''set gfxpayload=$linux_gfx_mode''', replace with '''set gfxpayload=text''' 1. Press 'Ctrl+x' to boot. - It's best if you can attach a log file which may have captured any messages you see. If you are unable to capture a log file, a digital photo will work just as well. As a last resort you can even copy messages down by hand. + It's best if you can attach a log file which may have captured any messages you see. If you are unable to capture a log file, a digital photo will work just as well. As a last resort you can even copy messages down by hand. - Depending on the type of error messages you encounter, there are other boot options you could try. For example, if you notice ACPI errors, try booting with the '''acpi=off''' boot option. For a full description of these options, refer to the [[http://www.kernel.org/doc/Documentation/kernel-parameters.txt|kernel parameters]] document. + Depending on the type of error messages you encounter, there are other boot options you could try. For example, if you notice ACPI errors, try booting with the '''acpi=off''' boot option. For a full description of these options, refer to the [[http://www.kernel.org/doc/Documentation/kernel-parameters.txt|kernel parameters]] document. - == Initramfs == + = Initramfs = - Sometimes you may even be dropped into an initramfs shell. This indicates errors in the boot sequence, for example failing to find your root partition/filesystem. You are put into the initramfs shell in an effort to allow you to recover the system. Hopefully, if you boot with the '''quiet''' and '''splash''' options removed you will notice error messages before being dropped into the shell which will help debug and direct you to a solution. - If you are dropped into an initramfs shell you may want to also try booting with the '''debug''' boot option. It should write a log to /tmp/initramfs.debug. You could also specify some arbitrary argument (for example '''debug=vc''') to have the output written to the console. + Sometimes you may even be dropped into an initramfs shell. This indicates errors in the boot sequence, for example failing to find your root partition/filesystem. You are put into the initramfs shell in an effort to allow you to recover the system. Hopefully, if you boot with the '''quiet''' and '''splash''' options removed you will notice error messages before being dropped into the shell which will help debug and direct you to a solution. - Additionally, being able to extract log files from the system would be helpful. Once dropped into an initramfs shell, you can type '''httpd'''. You should then be able to point a web browser to the IP address of the system and view the contents of /var/log . + If you are dropped into an initramfs shell you may want to also try booting with the '''debug''' boot option. It should write a log to /tmp/initramfs.debug. You could also specify some arbitrary argument (for example '''debug=vc''') to have the output written to the console. - There is another initramfs boot parameter which can purposely drop you into the initramfs shell during different stages of the initial boot sequence. The parameter is '''break=[option]''' where option can be: top, modules, premount, mount, bottom, or init. The default is premount if no options are specified. More information about the break= parameters can be found in "/usr/share/initramfs-tools/init" on your Ubuntu system. + Additionally, being able to extract log files from the system would be helpful. Once dropped into an initramfs shell, you can type '''httpd'''. You should then be able to point a web browser to the IP address of the system and view the contents of the /var/log folder. + There is another initramfs boot parameter which can purposely drop you into the initramfs shell during different stages of the initial boot sequence. The parameter is '''break=[option]''' where option can be: top, modules, premount, mount, bottom, or init. The default is premount if no options are specified. More information about the break= parameters can be found in "/usr/share/initramfs-tools/init" on your Ubuntu system. + - == Links == + = Links = - * [[http://askubuntu.com/questions/32999/what-is-vt-handoff-7-parameter-in-grub-cfg|vt.handoff]] explained + + * [[https://help.ubuntu.com/community/vt.handoff|vt.handoff]] explained + ---- CategoryBugSquad CategoryDebugging