Re: Bugs reports should include syslog warnings or not?
On Sat, Mar 17, 2018 at 06:09:25PM +0100, Sebastien Bacher wrote: > Hey there, > > https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1738581 was raised > to my attention in a discussion about apport/e.u.c and I'm wondering if > the change is right Thanks for bringing this up. > The report pointed out that private info have been included in a report > through JournalError.txt, and the solution applied was to change apport > to include errors level messages only and not warning. > > Looking a bit a journalerror on some bugs it seems we have indeed some > components that log too much content as "warning" (gdm in that case), > but changing to "error" has been cutting out useful warnings and doesn't > seem the right fix to me nor a step in the right direction. It doesn't > also protect us of the described issue (if a program logs sensitive info > in its errors messages we are still going to send them). > > I suggest that we change apport back to report warnings as well and look > at how we can better fix the privacy issue. I've modified apport back to include warnings but at the same time to address the privacy issue have also changed apport to only include JournalErrors when the report is a crash report as those reports are private by default. So before making a crash report public be sure to review the JournalErrors attachment for private information. And of course you can always ask the bug reporter to run the same command, 'journalctl -b --priority=warning --lines=1000', and add that to their regular bug reports if necessary. -- Brian Murray -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Supporting LZ4 as initramfs compressor
Last night I was trying to decrypt my laptop remotely. Work well (after some research) and so on, but the point is I put Dropbear SSH server inside initramfs and a faster decompress would be very welcomed. On Mon, Mar 19, 2018 at 2:19 PM, Balint Reczey wrote: > On Mon, Mar 19, 2018 at 3:12 PM, Julian Andres Klode > wrote: >> On Mon, Mar 19, 2018 at 02:59:24PM +, Balint Reczey wrote: >>> Hi, >>> >>> Initramfs-tools uses gzip compression by default which served us well >>> for quite some time but LZ4 offers way faster decompression while >>> making a only slightly bigger initramfs files. >>> >>> On my old laptop the initramfs extraction time decreased from ~1.2s to >>> ~0.24s: >>> (with lz4) >>> kernel: [0.297726] Unpacking initramfs... >>> kernel: [0.535061] Freeing initrd memory: 77940K >>> kernel: [0.301637] Unpacking initramfs... >>> kernel: [0.539109] Freeing initrd memory: 77940K >>> (with gzip) >>> kernel: [0.273748] Unpacking initramfs... >>> kernel: [1.490066] Freeing initrd memory: 57140K >>> kernel: [0.281729] Unpacking initramfs... >>> kernel: [1.498493] Freeing initrd memory: 57140K >>> >>> The increase in the initrd.img size is ~14%: >>> (lz4) >>> -rw-r--r-- 1 root root 66709065 márc 19 14:24 >>> /boot/initrd.img-4.15.0-12-generic >>> (gzip) >>> -rw-r--r-- 1 root root 58510993 márc 19 12:57 >>> /boot/initrd.img-4.15.0-12-generic.bak >>> >>> Initramfs creation speed also improved a bit from ~24s to ~21s wall clock >>> time: >>> (lz4) >>> update-initramfs: Generating /boot/initrd.img-4.15.0-12-generic >>> 14.97user 6.31system 0:20.47elapsed 103%CPU (0avgtext+0avgdata >>> 22368maxresident)k >>> update-initramfs: Generating /boot/initrd.img-4.15.0-12-generic >>> 15.18user 6.49system 0:20.48elapsed 105%CPU (0avgtext+0avgdata >>> 22308maxresident)k >>> (gzip) >>> update-initramfs: Generating /boot/initrd.img-4.15.0-12-generic >>> 18.23user 6.77system 0:23.61elapsed 105%CPU (0avgtext+0avgdata >>> 22396maxresident)k >>> update-initramfs: Generating /boot/initrd.img-4.15.0-12-generic >>> 18.38user 6.83system 0:23.82elapsed 105%CPU (0avgtext+0avgdata >>> 22292maxresident)k >> >> For me it was 16 -> 10 I think. >> >>> >>> Base on the results I plan adding LZ4 compression support to >>> initramfs-tools as requested in LP: #1488620 [1] in the next days >>> without setting it as default >>> >> >> +1 >> >>> and I propose setting LZ4 as default for 18.10. >> >> We might have zstd support by that time (I hope), it might make sense >> to use that then (better space/time tradeoff), but we'll have to see. > > That would also be an option, but I expect zstd to bring little speed > advantage over LZ4 here while LZ4 support could be easily backported > to releases with older kernels. > > The proposed patch enabling lz4 uses lz4 -9. I tried lz4's default > compression, -1, but decompression speed difference was barely > noticeable - most likely due to copying being the bottleneck. > > In fact I just realized that i copied the results created with lz4 -1, > where the compressed initrd size was 77940K. > The correct results for lz4 -9 are the following, taking the same > ~0.24s to decompress: > > kernel: [0.285692] Unpacking initramfs... > kernel: [0.518806] Freeing initrd memory: 65148K > kernel: [0.289731] Unpacking initramfs... > kernel: [0.522823] Freeing initrd memory: 65148K > > Cheers, > Balint > > -- > Balint Reczey > Ubuntu & Debian Developer > > -- > ubuntu-devel mailing list > ubuntu-devel@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Marcos H. Alano Linux System Administrator marcoshal...@gmail.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: zstd compression for packages
On 21 March 2018 at 00:25, Steve Langasek wrote: > On Sat, Mar 17, 2018 at 03:09:55PM +, Dimitri John Ledkov wrote: >> On 16 March 2018 at 22:13, Steve Langasek wrote: >> > In other words: if we want to make this the default, we should quantify >> > Daniel's remark that he would prefer a 6% faster download over a 10% faster >> > unpack. > >> Well, I think it does not make sense to think about this in absolute >> terms. Thinking about user stories is better. > > Sure. > >> A stable series user will be mostly upgrading packages from -security >> and -updates. The download speed and/or size of debs does not matter >> much in this case, as these are scheduled to be done in the background >> over the course of the day, via unattended upgrades download timer. >> Installation speed matters, as that is the window of time when the >> system is actually somewhat in a maintenance mode / degraded >> performance (apt is locked, there are CPU and disk-io loads). > > Does unattended upgrades download both -security and -updates, or does it > only download -security? From what I can see in > /usr/bin/unattended-upgrade, the allowed-origins check applies to both the > downloads and the installation. > > So by default, increases in the download time of non-security SRUs would be > perceivable by the user (though perhaps not of interest). > >> New instance initialization - e.g. spinning up a cloud instance, with >> cloud-init, and installing a bunch of things; deploying juju charm / >> conjure-up spell; configuring things with puppet / ansible / etc => >> these are download & install heavy. However, users that do that >> heavily, will be in a corporate / bussiness / datacentre environment >> and thus it is reasonable to expect them to have either a fat internet >> pipe, and/or a local mirror. Meaning download speed & size, are not >> critical. > > Generally agreed (but the assertion should still be tested, not assumed). > >> Then there are devel series users, developers who do sbuild builds, >> etc. These users are most likely to be on slower home-user connections >> and watch things a lot more closely interactively, who indeed care >> about the total download+install time. These users, are most likely >> very vocal / visible, but are not ultimately the target audience as to >> why we develop Ubuntu in the first place. Thus I would be willing to >> trade personal developer/devel-series user experience, in favor of the >> stable series user. I'm not sure how much it makes sense to >> proxy/cache/local-mirror devel series, if it is only a single machine >> in use. > > I disagree that we don't develop Ubuntu for developers. The developer That's not the use case I brought up. I said users of the devel series, aka ubuntu+1. The compression vs download trade off, is irrelevant on the ubuntu+1 series, since the churn is so high anyway, that the only way to win, is to not update every transition / archive push, and only dist-upgrade weekly. And optimizing for users of ubuntu+1 is very niche, in comparison to the stable series users. I make no distinction among the stable series users - be that "developers" or "not", they are all simply stable series users. -- Regards, Dimitri. -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Bionic Beaver User Interface Freeze and nearing Final Beta reminder
This is a gentle reminder that Bionic Beaver (18.04) is in User Interface Freeze since last week (March 22th). Remember about that when uploading packages into the archive as any freeze-breaking changes per https://wiki.ubuntu.com/UserInterfaceFreeze need to have an ubuntu-release approved exception [1]. Also, since Final Beta is planned for next week already, remember about the nearing Beta Freeze on Monday. If you still have any high impact changes pending for 18.04, now is the time to upload. Thanks! [1] https://wiki.ubuntu.com/FreezeExceptionProcess -- Łukasz 'sil2100' Zemczak Foundations Team lukasz.zemc...@canonical.com www.canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
