[Touch-packages] [Bug 1876238] Re: [Dell Inspiron 1525, SigmaTel STAC9228] No sound at all. Internal Speaker Not Detected. Dummy Output. After Upgrading From 19.10 to 20.04 LTS Focal
*** This bug is a duplicate of bug 1876065 *** https://bugs.launchpad.net/bugs/1876065 Have observed what appears to be this same bug, on a Dell Latitude D620 laptop!. E.g. using a live-usb, Speakers do not work (though headphones plugged in 3.5mm headphone-jack do!) until pulseaudio updated from (1:13.99.1-1ubuntu3) -> (1:13.99.1-1ubuntu3.5) and restart session. Hopefully this remains 'sorted out' for now... --Simon -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to alsa-driver in Ubuntu. https://bugs.launchpad.net/bugs/1876238 Title: [Dell Inspiron 1525, SigmaTel STAC9228] No sound at all. Internal Speaker Not Detected. Dummy Output. After Upgrading From 19.10 to 20.04 LTS Focal Status in alsa-driver package in Ubuntu: Confirmed Bug description: Internal speakers were working fine until I upgraded the system from 19.10 LTS to 20.04 LTS on April 23, 2020. Uninstalled and reinstalled alsamixer and pavucontrol, but of no use. Killed pavucontrol and reloaded alsamixer numerous times, but of no use. (`pulseaudio -k && sudo alsa force-reload`) Waited for two kernel updates, but of no use. Presently on 5.4.0-29. Tried upgrading the kernel even up to 5.6, but of no use. The Intel sound card is not getting detected. Tried every trick like adding "options snd-hda-intel dmic_detect=0" in the /etc/modprobe.d/alsa-base.conf, but of no use. Out of the two external audio output sockets for headphone, one is working. So I can either connect a headphone or an external speaker to this jack to tide over the crisis for the time being. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: alsa-base 1.0.25+dfsg-0ubuntu5 ProcVersionSignature: Ubuntu 5.4.0-29.33-generic 5.4.30 Uname: Linux 5.4.0-29-generic x86_64 NonfreeKernelModules: wl ApportVersion: 2.20.11-0ubuntu27 Architecture: amd64 AudioDevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: raj 10952 F pulseaudio CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Fri May 1 09:54:23 2020 InstallationDate: Installed on 2016-12-20 (1227 days ago) InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) PackageArchitecture: all SourcePackage: alsa-driver Symptom: audio Symptom_AlsaPlaybackTest: ALSA playback test through plughw:Intel failed Symptom_Card: Built-in Audio - HDA Intel Symptom_DevicesInUse: USERPID ACCESS COMMAND /dev/snd/controlC0: raj 10952 F pulseaudio Symptom_Jack: Speaker, Internal Symptom_Type: No sound at all Title: [Inspiron 1525, SigmaTel STAC9228, Speaker, Internal] No sound at all UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 06/27/2008 dmi.bios.vendor: Dell Inc. dmi.bios.version: A13 dmi.board.vendor: Dell Inc. dmi.chassis.type: 8 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvrA13:bd06/27/2008:svnDellInc.:pnInspiron1525:pvr:rvnDellInc.:rn:rvr:cvnDellInc.:ct8:cvr: dmi.product.family: Inspiron dmi.product.name: Inspiron 1525 dmi.sys.vendor: Dell Inc. mtime.conffile..etc.modprobe.d.alsa-base.conf: 2020-04-26T17:25:43.583147 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1876238/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1773157] Re: procps outdated network options, old syncookies, new ecn update please.
Right -- systemd have just-now agreed to set the change in their upstream systemd sysctl files :- https://github.com/systemd/systemd/commit/6f130e85c76cfc2c58ba31f90d2ac3800866c1dd I notice, however, that ubuntu's systemd pkg 'strips most those settings out', in 18.04 currently only carrying the 18.04 fq_codel switch-on in their sysctl.d I think, given what has been said, I would like to propose that I :- * Make a suggested text for a 10-network-bufferbloat.conf here in procps in 18.10 (hopefully-onwards, including suitable references/comments about BBR (which should be there but commented/not- enabled yet unless we are sure its' been fixed to respond to ECN notifications.). This text shall explain clearly these are deliberately being tested into 18.10 and where to report bugs. * Look at what ubuntu's systemd package towards 18.10 is importing in sysctl.d -- and likely suggest ubuntu 'taken out' entirely so procps is the 'one' location for these settings (i.e. no duplicate setting of qdisc=fq_codel in 2 different places). Some will want to boot ubuntu with OpenRC or upstart for whatever reasons and consistent-behaviour would be helpful... * Ask in the BBR community about tcp_congestion_control goings-on there, when they are ready for ECN-compatible BBR wider-deployment. * Then, as/when seems appropriate, suggest changes into upstream-debian and upstream-kernel on the defaults. @rbalint -- what do you think on this plan for the interim? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1773157 Title: procps outdated network options, old syncookies, new ecn update please. Status in procps package in Ubuntu: Confirmed Bug description: The ubuntu version of procps carries it's own /etc/sysctl.d/10 -network-security.conf file explicitly that appears not to be part of debian procps version. Firstly, the section about "# Turn on SYN-flood protections." (came from LP #57091 ) is now entirely outdated, upstream kernel has long since turned on syncookies by default, so setting this flag explicitly in 10-network-security.conf is entirely redundant likely since before ubuntu-14.04 . I would like the ubuntu-maintainer to remove that section entirely in cosmic onwards. [I am going to report debian the similarly outdated syncookies comments in sysctl.conf itself]. Secondly, I propose a new 10-network-tuning.conf with:- == # Allow ECN for outgoing connections. Starting with 4.2, there is an adaptive # fallback [enabled by default tcp_ecn_fallback option] preventing connection # loss even with ecn enabled, also ecn-intolerance is increasingly very rare. net.ipv4.tcp_ecn=1 == I know there is a (small) chance of issues/regressions with ECN enabled by default on outgoing but I'm quite sure the issue is very rare, like others notice [ref: 1 and 2 below]. Apple's selective enablements etc. show this works just as much as my own use for years and many similar reports. ECN actually being used for outgoing connections really helps with latency-reduction with modern routers (both core and edge) using queuing disciplines fq_codel or otherwise, able to mark rather than drop packets on ECN-enabled flows [helps latency and realtime applications]. Now we are just past LTS release is in my view the 'right time' to finally enable ECN [and obviously easy to revert!]. If this is disputed, in ANY case I strongly suggest at the very least a commented-out ECN section should be included, but 'defaults matter'!. I was going to suggest a non-default section about net.core.default_qdisc [ LP #1436945 ] but this appears to have been fixed upstream similarly. [1] https://www.ietf.org/proceedings/98/slides/slides-98-maprg-tcp-ecn-experience-with-enabling-ecn-on-the-internet-padma-bhooma-00.pdf [2] http://seclists.org/nanog/2015/Jun/675 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1773157/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1773157] Re: procps outdated network options, old syncookies, new ecn update please.
It would appear that the path-of-least-resistance at present, is systemd, poettering which is what is (for systemd-booters) where fq_codel is getting turned-on in ubuntu. This raises a wider-issue about bringing systemd-provided sysctl- defaults into procps more widely [systemd has introduced many of these in its' own repository, but version in ubuntu-bionic has few, see /usr/lib/sysctl.d/ on a bionic system... ALSO I have discovered there are facts to be checked about "BBR" as default TCP congestion-control, which will also be desirable, but MAY still have immature/issues when ECN is used on a TCP connection as well [one suggestion BBR doesn't react to ECN notifications]... I'm trying to get 'evidence' and 'facts' in that regard, which seem to be sparse and hard-to-find ... I'm going to (try) to get more facts before suggesting patches with reasons/evidence a few places. Agree entirely debian and upstream worth trying to ask, etc. HOWEVER its' often very useful to have had a change introduced in a 'non-lts' or 'testing' distibution like ubuntu-non-LTS releases so you can say how it works and had some testing/exposure somewhere first... It may be I come back to you and suggest a delta in ubuntu "for now" for good reason. We will see. Thankyou for helpful and promising-sounding response!. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1773157 Title: procps outdated network options, old syncookies, new ecn update please. Status in procps package in Ubuntu: Confirmed Bug description: The ubuntu version of procps carries it's own /etc/sysctl.d/10 -network-security.conf file explicitly that appears not to be part of debian procps version. Firstly, the section about "# Turn on SYN-flood protections." (came from LP #57091 ) is now entirely outdated, upstream kernel has long since turned on syncookies by default, so setting this flag explicitly in 10-network-security.conf is entirely redundant likely since before ubuntu-14.04 . I would like the ubuntu-maintainer to remove that section entirely in cosmic onwards. [I am going to report debian the similarly outdated syncookies comments in sysctl.conf itself]. Secondly, I propose a new 10-network-tuning.conf with:- == # Allow ECN for outgoing connections. Starting with 4.2, there is an adaptive # fallback [enabled by default tcp_ecn_fallback option] preventing connection # loss even with ecn enabled, also ecn-intolerance is increasingly very rare. net.ipv4.tcp_ecn=1 == I know there is a (small) chance of issues/regressions with ECN enabled by default on outgoing but I'm quite sure the issue is very rare, like others notice [ref: 1 and 2 below]. Apple's selective enablements etc. show this works just as much as my own use for years and many similar reports. ECN actually being used for outgoing connections really helps with latency-reduction with modern routers (both core and edge) using queuing disciplines fq_codel or otherwise, able to mark rather than drop packets on ECN-enabled flows [helps latency and realtime applications]. Now we are just past LTS release is in my view the 'right time' to finally enable ECN [and obviously easy to revert!]. If this is disputed, in ANY case I strongly suggest at the very least a commented-out ECN section should be included, but 'defaults matter'!. I was going to suggest a non-default section about net.core.default_qdisc [ LP #1436945 ] but this appears to have been fixed upstream similarly. [1] https://www.ietf.org/proceedings/98/slides/slides-98-maprg-tcp-ecn-experience-with-enabling-ecn-on-the-internet-padma-bhooma-00.pdf [2] http://seclists.org/nanog/2015/Jun/675 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1773157/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1601997] Re: Ubuntu 16.10+ installer uses ext4 feature 'metadata_csum' which is incompatible with older (LTS) e2fsprogs
FWIW: e2fsprogs PPA created and discussion of backports/updates should happen on this linked-bug:- https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874 -- if you are interested in xenial/older e2fsprogs compatibility please subscribe to that bug #1365874 . I also spotted e2fsprogs 1.44.2 has fix against crashing from malicious- filesystems, remains to be seen if this and further future fixes may ultimately warrant update to bionic's 1.44.1 . -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1601997 Title: Ubuntu 16.10+ installer uses ext4 feature 'metadata_csum' which is incompatible with older (LTS) e2fsprogs Status in e2fsprogs package in Ubuntu: Won't Fix Bug description: Ubuntu 16.10 installer sets metadata_csum option on ext4 partition which is incompatible with other LTS Ubuntu versions (12.04 LTS, 14.04 LTS, 16.04 LTS). Steps to reproduce: 1. Download Ubuntu 16.10 installation media. 2. Install Ubuntu. 3. Try to do fsck -fy /dev/sdX1 from other supported Ubuntu distro. Expected results: User can check and fix errors on ext4 filesystem, created on Ubuntu 16.10. Actual results: User can not check and fix errors on ext4 filesystem because of lack of 'metadata_csum' option in previous LTS Ubuntu versions. The only one working solution was to scan from 16.10 live install media. Note: it is known, that Dan Watkins disabled metadata_csum when creating ext4 filesystems ( see http://bazaar.launchpad.net/~daniel-thewatkins/maas-images/fix-yakkety-builds/revision/305 ). It is good solution. ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: e2fsprogs 1.43.1-1 ProcVersionSignature: Ubuntu 4.4.0-30.49-generic 4.4.13 Uname: Linux 4.4.0-30-generic i686 ApportVersion: 2.20.2-0ubuntu1 Architecture: i386 CurrentDesktop: Unity Date: Mon Jul 11 23:42:49 2016 SourcePackage: e2fsprogs UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1601997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1365874] Re: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming
Here is the PPA for all architectures, please test :- https://launchpad.net/~ubuntu-iremonger/+archive/ubuntu/e2fsprogs-xenial That is currently a backport of the version in bionic release itself, but maintains the xenial mke2fs.conf defaults [creating filesystems without 64bit,metadata_csum] for compatibility. I notice e2fsprogs in cosmic [1.44.2] introduces an anti-crash-fix [filesystems designed to crash e2fsck!]. Exactly what versions should then be considered for xenial-backports and xenial-updates, and if any updates to bionic should also be considered, is another matter!. Debian already have 1.44.2 backported to stretch (their current LTS release), for example. "-updates" versions might not, for example, want to update the comerr development headers and other potential compatibility regression areas, who knows?. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming Status in e2fsprogs package in Ubuntu: Triaged Bug description: In the Trusty release notes "Metadata checksumming" is listed as one of the tech highlights of kernel 3.13. https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#New_features_in_14.04_LTS However, the userland tools do not support this kernel feature. To the best of my knowledge this will be supported in 1.43, and won't be backported to 1.42. IMHO this is very misleading. It's like a car salesperson sold you a sports car with an V8 engine. After you drove it home, you opened the hood and realized only 6 cylinders are working because 2 of the spark plugs were not included, and you have to buy aftermarket ones. BTW, I've been following the development of e2fsprogs for over a year. 1.43 release has been in limbo for God knows how long :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1365874] Re: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming
Marc, Briefly just to let you know I'm working on a PPA for bionic e2fsprogs backport to xenial, will update when thats' ready. Turns out that:- (a) Ubuntu devs are rather tied-up fixing bionic18.04 bugs, and (b) to do a good SRU would need much regression-testing and somebody to push it forwards. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming Status in e2fsprogs package in Ubuntu: Triaged Bug description: In the Trusty release notes "Metadata checksumming" is listed as one of the tech highlights of kernel 3.13. https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#New_features_in_14.04_LTS However, the userland tools do not support this kernel feature. To the best of my knowledge this will be supported in 1.43, and won't be backported to 1.42. IMHO this is very misleading. It's like a car salesperson sold you a sports car with an V8 engine. After you drove it home, you opened the hood and realized only 6 cylinders are working because 2 of the spark plugs were not included, and you have to buy aftermarket ones. BTW, I've been following the development of e2fsprogs for over a year. 1.43 release has been in limbo for God knows how long :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1773157] Re: procps outdated network options, old syncookies, new ecn update please.
(fwiw, fq_codel queuing is now being turned-on in bionic (at least) by systemd, confusingly!). https://github.com/systemd/systemd/commit/e6c253e363dee77ef7e5c5f44c4ca55cded3fd47 Possibly, turning on ECN might more likely happen there first, but I would like the procps updated for those using upstart or otherwise). This seems to be the last piece of bufferbloat puzzle (see LP bug #1436945 ). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1773157 Title: procps outdated network options, old syncookies, new ecn update please. Status in procps package in Ubuntu: Confirmed Bug description: The ubuntu version of procps carries it's own /etc/sysctl.d/10 -network-security.conf file explicitly that appears not to be part of debian procps version. Firstly, the section about "# Turn on SYN-flood protections." (came from LP #57091 ) is now entirely outdated, upstream kernel has long since turned on syncookies by default, so setting this flag explicitly in 10-network-security.conf is entirely redundant likely since before ubuntu-14.04 . I would like the ubuntu-maintainer to remove that section entirely in cosmic onwards. [I am going to report debian the similarly outdated syncookies comments in sysctl.conf itself]. Secondly, I propose a new 10-network-tuning.conf with:- == # Allow ECN for outgoing connections. Starting with 4.2, there is an adaptive # fallback [enabled by default tcp_ecn_fallback option] preventing connection # loss even with ecn enabled, also ecn-intolerance is increasingly very rare. net.ipv4.tcp_ecn=1 == I know there is a (small) chance of issues/regressions with ECN enabled by default on outgoing but I'm quite sure the issue is very rare, like others notice [ref: 1 and 2 below]. Apple's selective enablements etc. show this works just as much as my own use for years and many similar reports. ECN actually being used for outgoing connections really helps with latency-reduction with modern routers (both core and edge) using queuing disciplines fq_codel or otherwise, able to mark rather than drop packets on ECN-enabled flows [helps latency and realtime applications]. Now we are just past LTS release is in my view the 'right time' to finally enable ECN [and obviously easy to revert!]. If this is disputed, in ANY case I strongly suggest at the very least a commented-out ECN section should be included, but 'defaults matter'!. I was going to suggest a non-default section about net.core.default_qdisc [ LP #1436945 ] but this appears to have been fixed upstream similarly. [1] https://www.ietf.org/proceedings/98/slides/slides-98-maprg-tcp-ecn-experience-with-enabling-ecn-on-the-internet-padma-bhooma-00.pdf [2] http://seclists.org/nanog/2015/Jun/675 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1773157/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 57091] Re: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense...
FWIW Although syncookies has long-since been enabled upstream, the outdated comments in sysctl about syncookies still persist, I have now created new ubuntu bug #1773157 [please comment there]. [This also requests ECN-on-outgoing enablement which has similarly matured etc.]. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/57091 Title: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense... Status in procps package in Ubuntu: Fix Released Bug description: This is intended to be a 'wishlist' wulnerability -- w.r.t. procps and Edgy. In my opinion,the /etc/sysctl.conf should have 'proc/sys/net/ipv4/tcp_syncookies=1' in order to permit the linux SYNcookies syn-flood trivial DoS attack to be mitigated as-necessary, by default. Note that the disadvantages of connections initiated w/ SYNcookies enabled only apply when the system is under attack (SYN queue getting rather full), as the syncookies reply-with-only-one-SYN+ACK behaviour only 'kicks in' when the system has a SYN_RECVD backlog problem. (If SYNcookies were not permitted incoming TCP connections have a very low chance of succeeding at all while under SYN-flood attack). Without this setting enabled, any TCP services on the machine can be DoSed from a dial-up line sending a stream of SYN packets from weird source addresses to open TCP ports like Samba/VNC/http/whatever Does anybody have any legitimate reason tcp_syncookies should be disabled? Some people claimed that SYNcookies break some RFCs once but I have not seen any evidence to this effect, only notes from djb saying that this is not true. Comments wanted please ;-) Thankyou in advance, -- enyc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/57091/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1773157] [NEW] procps outdated network options, old syncookies, new ecn update please.
Public bug reported: The ubuntu version of procps carries it's own /etc/sysctl.d/10-network- security.conf file explicitly that appears not to be part of debian procps version. Firstly, the section about "# Turn on SYN-flood protections." (came from LP #57091 ) is now entirely outdated, upstream kernel has long since turned on syncookies by default, so setting this flag explicitly in 10-network-security.conf is entirely redundant likely since before ubuntu-14.04 . I would like the ubuntu-maintainer to remove that section entirely in cosmic onwards. [I am going to report debian the similarly outdated syncookies comments in sysctl.conf itself]. Secondly, I propose a new 10-network-tuning.conf with:- == # Allow ECN for outgoing connections. Starting with 4.2, there is an adaptive # fallback [enabled by default tcp_ecn_fallback option] preventing connection # loss even with ecn enabled, also ecn-intolerance is increasingly very rare. net.ipv4.tcp_ecn=1 == I know there is a (small) chance of issues/regressions with ECN enabled by default on outgoing but I'm quite sure the issue is very rare, like others notice [ref: 1 and 2 below]. Apple's selective enablements etc. show this works just as much as my own use for years and many similar reports. ECN actually being used for outgoing connections really helps with latency-reduction with modern routers (both core and edge) using queuing disciplines fq_codel or otherwise, able to mark rather than drop packets on ECN-enabled flows [helps latency and realtime applications]. Now we are just past LTS release is in my view the 'right time' to finally enable ECN [and obviously easy to revert!]. If this is disputed, in ANY case I strongly suggest at the very least a commented-out ECN section should be included, but 'defaults matter'!. I was going to suggest a non-default section about net.core.default_qdisc [ LP #1436945 ] but this appears to have been fixed upstream similarly. [1] https://www.ietf.org/proceedings/98/slides/slides-98-maprg-tcp-ecn-experience-with-enabling-ecn-on-the-internet-padma-bhooma-00.pdf [2] http://seclists.org/nanog/2015/Jun/675 ** Affects: procps (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/1773157 Title: procps outdated network options, old syncookies, new ecn update please. Status in procps package in Ubuntu: New Bug description: The ubuntu version of procps carries it's own /etc/sysctl.d/10 -network-security.conf file explicitly that appears not to be part of debian procps version. Firstly, the section about "# Turn on SYN-flood protections." (came from LP #57091 ) is now entirely outdated, upstream kernel has long since turned on syncookies by default, so setting this flag explicitly in 10-network-security.conf is entirely redundant likely since before ubuntu-14.04 . I would like the ubuntu-maintainer to remove that section entirely in cosmic onwards. [I am going to report debian the similarly outdated syncookies comments in sysctl.conf itself]. Secondly, I propose a new 10-network-tuning.conf with:- == # Allow ECN for outgoing connections. Starting with 4.2, there is an adaptive # fallback [enabled by default tcp_ecn_fallback option] preventing connection # loss even with ecn enabled, also ecn-intolerance is increasingly very rare. net.ipv4.tcp_ecn=1 == I know there is a (small) chance of issues/regressions with ECN enabled by default on outgoing but I'm quite sure the issue is very rare, like others notice [ref: 1 and 2 below]. Apple's selective enablements etc. show this works just as much as my own use for years and many similar reports. ECN actually being used for outgoing connections really helps with latency-reduction with modern routers (both core and edge) using queuing disciplines fq_codel or otherwise, able to mark rather than drop packets on ECN-enabled flows [helps latency and realtime applications]. Now we are just past LTS release is in my view the 'right time' to finally enable ECN [and obviously easy to revert!]. If this is disputed, in ANY case I strongly suggest at the very least a commented-out ECN section should be included, but 'defaults matter'!. I was going to suggest a non-default section about net.core.default_qdisc [ LP #1436945 ] but this appears to have been fixed upstream similarly. [1] https://www.ietf.org/proceedings/98/slides/slides-98-maprg-tcp-ecn-experience-with-enabling-ecn-on-the-internet-padma-bhooma-00.pdf
[Touch-packages] [Bug 1365874] Re: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming
HOWEVER, Trusty e2fsprogs backporting situation actually seems to be that, some change between 1.43.3-1~bpo8+1 and 1.43.4-2 is where the trusty-incompatibility has accrued, 1.43.9-2 does NOT build on trusty! :- https://www.iremonger.me.uk/noidx/e2fs/e2fsprogs-1.43.9_trusty_build-fail.log A simple patch to the 'debian/control' file adding the explicit '-dbg' package entries on the end *APPEARS* to solve all the problems, and allows 1.43.9 [or 1.44.0 for that matter!] to SEEMINGLY build fine, pass all tests, and work fine on trusty without any issues I can find so-far!:- https://www.iremonger.me.uk/noidx/e2fs/e2fsprogs-1.43.9_trusty_debian-control.patch https://www.iremonger.me.uk/noidx/e2fs/e2fsprogs-1.44.0_trusty_debian-control.patch This all SEEMS to work fine, but I'd like tytso to comment on this, is this really a safe workaround or just 'fixing the symptom'. From what I can see all the right programs are generated and work fine. AGAIN, I'd highly recommend installing byte-for-byte the 'original' mke2fs.conf in any trusty-backport version of e2fsprogs, so as to avoid any unwanted behavioural-changes or configuration-file-update-prompts :-. https://www.iremonger.me.uk/noidx/e2fs/mke2fs.conf.trusty >From what I can SEE, if doing a significant backport to trusty, I can't see why not to just go straight to 1.44.0 in this case [again, hopefully tytso can comment!]. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming Status in e2fsprogs package in Ubuntu: Triaged Bug description: In the Trusty release notes "Metadata checksumming" is listed as one of the tech highlights of kernel 3.13. https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#New_features_in_14.04_LTS However, the userland tools do not support this kernel feature. To the best of my knowledge this will be supported in 1.43, and won't be backported to 1.42. IMHO this is very misleading. It's like a car salesperson sold you a sports car with an V8 engine. After you drove it home, you opened the hood and realized only 6 cylinders are working because 2 of the spark plugs were not included, and you have to buy aftermarket ones. BTW, I've been following the development of e2fsprogs for over a year. 1.43 release has been in limbo for God knows how long :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1365874] Re: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming
OK On further investigation, I have confirmed a lot of key-facts (1 of 2 linked comments). e2fsprogs 1.44.0-1 backports to xenial with no difficulty whatsoever, passes "make fullcheck" and works in every way I can tell, lots of resizing and checking and use within gparted, etc, all (apparently) behaving... HOWEVER, for an official xenial-backport (and especially xenial-SRU), to minimize possible problems, I would highly recommend making single change of restoring the 'default' mke2fs.conf EXACTLY (byte-for-byte) as that which came with xenial e2fsprogs 1.42.13-1ubuntu1 :- https://www.iremonger.me.uk/noidx/e2fs/mke2fs.conf.xenial This (a) avoids prompting users who've customized their mke2fs.conf about merging-changes, and (b) avoids functional-change for those with automated-deployment-scripts etc. based upon ext4 creation. I presume, a 'xenial-backport' -or- SRU "proposed" update can be started straight-away? xenial-SRU should DEFINITELY be considered for fsck compatibility with bionic-created FS. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming Status in e2fsprogs package in Ubuntu: Triaged Bug description: In the Trusty release notes "Metadata checksumming" is listed as one of the tech highlights of kernel 3.13. https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#New_features_in_14.04_LTS However, the userland tools do not support this kernel feature. To the best of my knowledge this will be supported in 1.43, and won't be backported to 1.42. IMHO this is very misleading. It's like a car salesperson sold you a sports car with an V8 engine. After you drove it home, you opened the hood and realized only 6 cylinders are working because 2 of the spark plugs were not included, and you have to buy aftermarket ones. BTW, I've been following the development of e2fsprogs for over a year. 1.43 release has been in limbo for God knows how long :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1756177] Re: FFe: e2fsprogs 1.44, support for largedir and ea_inode
FWIW 'this seems to WORK in bionic, including "make fullcheck" on the source, system able to check itself on boot, resizing other system disks, no issues so far as I can. Thankyou for agreeing//doing this so quickly. Backporting related matters to be discussed separately in:- https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1756177 Title: FFe: e2fsprogs 1.44, support for largedir and ea_inode Status in e2fsprogs package in Ubuntu: Fix Released Bug description: e2fsprogs 1.44 landed in Debian unstable on March 8, missing feature freeze / Debian import freeze by about a week. Per upstream (https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/comments/17), 1.44 includes two new not-enabled-by-default features which would be good to have available in the 18.04 userspace: largedir, and ea_inode. This is a rather stable and well-maintained codebase with stable interfaces, so I believe the risks are small to taking this post-FF. The one known change in behavior relative to Ubuntu 16.04 is the enablement of metadata checksums by default, which is a change we already have via the 1.43.9 package, so shouldn't count against an FFe. The main (but still small) risk to the release from taking this change would be disruption to image builds / installation as a result of broken tools. This would be detected fairly quickly through our automated image testing, and if any regressions are introduced we should roll back the e2fsprogs update immediately. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1756177/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1365874] Re: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming
e2fsprogs 1.44.0 for bionic18.04 has apparently been agreed:- https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1756177 [launchpad build-logs suggest its' been built for PROPOSED but not yet seen it 'come through' as a package or appear on 'packages.ubuntu.com' ...]. Hopefully that will go through. Is the first-step thereafter, to then "xenial-backports" 1.44.0 and "trusty-backports" 1.43.9 ? -- I believe devs spoke of accepting an SRU (full stable-release-update) for xenial e2fsprogs, but I suspect backporting in first instance may be a good approach [?]. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming Status in e2fsprogs package in Ubuntu: Triaged Bug description: In the Trusty release notes "Metadata checksumming" is listed as one of the tech highlights of kernel 3.13. https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#New_features_in_14.04_LTS However, the userland tools do not support this kernel feature. To the best of my knowledge this will be supported in 1.43, and won't be backported to 1.42. IMHO this is very misleading. It's like a car salesperson sold you a sports car with an V8 engine. After you drove it home, you opened the hood and realized only 6 cylinders are working because 2 of the spark plugs were not included, and you have to buy aftermarket ones. BTW, I've been following the development of e2fsprogs for over a year. 1.43 release has been in limbo for God knows how long :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1365874] Re: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming
See linked bug 1601997, response seems to be to accept your 'new' defaults for ext4 in 18.04. I note, particularly -- your request about 1.44.0 inclusion doesn't yet seem to be addressed [maybe it requires a separate bug//issue] ;-(. Do expand on that point if you can. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming Status in e2fsprogs package in Ubuntu: Triaged Bug description: In the Trusty release notes "Metadata checksumming" is listed as one of the tech highlights of kernel 3.13. https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#New_features_in_14.04_LTS However, the userland tools do not support this kernel feature. To the best of my knowledge this will be supported in 1.43, and won't be backported to 1.42. IMHO this is very misleading. It's like a car salesperson sold you a sports car with an V8 engine. After you drove it home, you opened the hood and realized only 6 cylinders are working because 2 of the spark plugs were not included, and you have to buy aftermarket ones. BTW, I've been following the development of e2fsprogs for over a year. 1.43 release has been in limbo for God knows how long :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1601997] Re: Ubuntu 16.10+ installer uses ext4 feature 'metadata_csum' which is incompatible with older (LTS) e2fsprogs
Steve: Given what you say, can you consider Tytso's request to put 1.44.0 e2fsprogs into Bionic. This allows for not-enabled-by-default for support of 2 extra ext4 flags in e2fsprogs, thereby avoiding this situation happening again for 20.04 with respect to THOSE flags... As TJ- said, be good to get it in for LTS release from the off. https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/comments/17 [maybe that should be handled in the other bug as above]. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1601997 Title: Ubuntu 16.10+ installer uses ext4 feature 'metadata_csum' which is incompatible with older (LTS) e2fsprogs Status in e2fsprogs package in Ubuntu: Won't Fix Bug description: Ubuntu 16.10 installer sets metadata_csum option on ext4 partition which is incompatible with other LTS Ubuntu versions (12.04 LTS, 14.04 LTS, 16.04 LTS). Steps to reproduce: 1. Download Ubuntu 16.10 installation media. 2. Install Ubuntu. 3. Try to do fsck -fy /dev/sdX1 from other supported Ubuntu distro. Expected results: User can check and fix errors on ext4 filesystem, created on Ubuntu 16.10. Actual results: User can not check and fix errors on ext4 filesystem because of lack of 'metadata_csum' option in previous LTS Ubuntu versions. The only one working solution was to scan from 16.10 live install media. Note: it is known, that Dan Watkins disabled metadata_csum when creating ext4 filesystems ( see http://bazaar.launchpad.net/~daniel-thewatkins/maas-images/fix-yakkety-builds/revision/305 ). It is good solution. ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: e2fsprogs 1.43.1-1 ProcVersionSignature: Ubuntu 4.4.0-30.49-generic 4.4.13 Uname: Linux 4.4.0-30-generic i686 ApportVersion: 2.20.2-0ubuntu1 Architecture: i386 CurrentDesktop: Unity Date: Mon Jul 11 23:42:49 2016 SourcePackage: e2fsprogs UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1601997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1601997] Re: Ubuntu 16.10+ installer uses ext4 feature 'metadata_csum' which is incompatible with older (LTS) e2fsprogs
Initial comments from the email:- a) There is some confusion over "metadata_csum" with/without "64bit". -- Those who have 'reverted' are usually reverting BOTH flags [as I've done some places], not just metadata_csum. My understanding is 64bit is of no benefit except support >16TB fs and to strengthen metadata_csum's [if used, which help notice dodgy disks in theory.]. b) The business of including e2fsprogs-1.44.0 in 18.04 at tytso's request [NON-default extra feature support may benefit Samba users etc. later] is not addressed. c) Its' worth pointing-out explicitly e2fsprogs only enabled 64bit,metadata_csum 'by default' for 'everybody' within last few weeks, Debian change was as-you-rightly-quote. d) Considering the above, also think outside the ubuntu-box! What do canonical's customers/partners expect compatibility-wise with other non- ubuntu systems, virtualizers/ISCSI-hosts/etc (e2fsprogs 1.42 still very common!), let alone "backports to ubuntu LTS versions" only?. e) My understanding from TJ in IRC is he's started doing some tests on some datacentre cases, there are particular issues with things like ISCSI hosts, the host system needs to fsck guest-FS and break otherwise!. HOPEFULLY this will appear soon and can be added to the mail-discussion. I can try to join email/post directly to mail if appropriate/helpful. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1601997 Title: Ubuntu 16.10+ installer uses ext4 feature 'metadata_csum' which is incompatible with older (LTS) e2fsprogs Status in e2fsprogs package in Ubuntu: Triaged Bug description: Ubuntu 16.10 installer sets metadata_csum option on ext4 partition which is incompatible with other LTS Ubuntu versions (12.04 LTS, 14.04 LTS, 16.04 LTS). Steps to reproduce: 1. Download Ubuntu 16.10 installation media. 2. Install Ubuntu. 3. Try to do fsck -fy /dev/sdX1 from other supported Ubuntu distro. Expected results: User can check and fix errors on ext4 filesystem, created on Ubuntu 16.10. Actual results: User can not check and fix errors on ext4 filesystem because of lack of 'metadata_csum' option in previous LTS Ubuntu versions. The only one working solution was to scan from 16.10 live install media. Note: it is known, that Dan Watkins disabled metadata_csum when creating ext4 filesystems ( see http://bazaar.launchpad.net/~daniel-thewatkins/maas-images/fix-yakkety-builds/revision/305 ). It is good solution. ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: e2fsprogs 1.43.1-1 ProcVersionSignature: Ubuntu 4.4.0-30.49-generic 4.4.13 Uname: Linux 4.4.0-30-generic i686 ApportVersion: 2.20.2-0ubuntu1 Architecture: i386 CurrentDesktop: Unity Date: Mon Jul 11 23:42:49 2016 SourcePackage: e2fsprogs UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1601997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1365874] Re: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming
FWIW, As was discussed, I checked into Grub2 and os-prober in older supported ubuntu (which may have similar incompatibility to e2fsprogs, thereby creating a multibooting issue with 18.04). After experimenting carefully with a 14.04+16.04+18.04 (GA kernels, no HWE specifically) BIOS-style triple boot, can confirm the grub ext4 support is all cross-compatible (14.04 can autodetect and boot 64bit,metadata_csum 18.04 from its' own grub2). However, e2fsprogs is DEFINITELY an issue as above, definitely worth sorting-out whatever-happens to the 18.04 default filesystem options, in my view. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming Status in e2fsprogs package in Ubuntu: Triaged Bug description: In the Trusty release notes "Metadata checksumming" is listed as one of the tech highlights of kernel 3.13. https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#New_features_in_14.04_LTS However, the userland tools do not support this kernel feature. To the best of my knowledge this will be supported in 1.43, and won't be backported to 1.42. IMHO this is very misleading. It's like a car salesperson sold you a sports car with an V8 engine. After you drove it home, you opened the hood and realized only 6 cylinders are working because 2 of the spark plugs were not included, and you have to buy aftermarket ones. BTW, I've been following the development of e2fsprogs for over a year. 1.43 release has been in limbo for God knows how long :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1601997] Re: Ubuntu 16.10+ installer uses ext4 feature 'metadata_csum' which is incompatible with older (LTS) e2fsprogs
Can we pay-attention, to this thread (now) being about considering the feature-flags 'used by default' in mke2fs.conf, in consideration to 18.04 -- [linked bug for e2fsprogs]. We know massive 'compatibility'/portability benefit of formatting the same as previous-LTS by default, as the required e2fsprogs was only introduced 16.10, and the needed kernel was only in 16.04 (and 14.04 -HWE-kernel-update.). NB: Looks like there is a similar issue with GRUB2 which affects dual-booters, grub2 2.02beta3 may be needed to support 64bit FS. If so, again Xenial isn't compatible to detect an 18.04 in multi-boot-menu. I'd like tytso to comment on the downsides of formatting without 64bit,metadata_csum, more specifically. From what I can (see) this only loses a little extra checksumming-integrity (against bad disks, which we've never needed before??), and the 64bit feature appears only to be needed to strengthen these checksums or support >16TB disks (bearing in mind auto_64bit_support can still be used). NB: Is this correct, -OR- is there likely going to be future annoyances with 'other' ext4 features-to-come which will ALSO expect 64bit formatting?. My suggestion is, this hasn't been sorted-out enough in the ubuntu- world, and 64bit,metadata_csum should be disabled-by-default for 18.04 and backporting grub/e2fsprogs/etc where relevant should happen as well [see other thread, possibly another may be created for grub2]. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1601997 Title: Ubuntu 16.10+ installer uses ext4 feature 'metadata_csum' which is incompatible with older (LTS) e2fsprogs Status in e2fsprogs package in Ubuntu: Triaged Bug description: Ubuntu 16.10 installer sets metadata_csum option on ext4 partition which is incompatible with other LTS Ubuntu versions (12.04 LTS, 14.04 LTS, 16.04 LTS). Steps to reproduce: 1. Download Ubuntu 16.10 installation media. 2. Install Ubuntu. 3. Try to do fsck -fy /dev/sdX1 from other supported Ubuntu distro. Expected results: User can check and fix errors on ext4 filesystem, created on Ubuntu 16.10. Actual results: User can not check and fix errors on ext4 filesystem because of lack of 'metadata_csum' option in previous LTS Ubuntu versions. The only one working solution was to scan from 16.10 live install media. Note: it is known, that Dan Watkins disabled metadata_csum when creating ext4 filesystems ( see http://bazaar.launchpad.net/~daniel-thewatkins/maas-images/fix-yakkety-builds/revision/305 ). It is good solution. ProblemType: Bug DistroRelease: Ubuntu 16.10 Package: e2fsprogs 1.43.1-1 ProcVersionSignature: Ubuntu 4.4.0-30.49-generic 4.4.13 Uname: Linux 4.4.0-30-generic i686 ApportVersion: 2.20.2-0ubuntu1 Architecture: i386 CurrentDesktop: Unity Date: Mon Jul 11 23:42:49 2016 SourcePackage: e2fsprogs UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1601997/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1365874] Re: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming
Given your other comment (which I think may have been posted to the wrong thread):- [E2fsprogs 1.44.0 now depends on dpkg build-profiles, which means that getting it backported to 14.04 LTS would require adjusting debian/control and debian/rules a bit. For 14.04 LTS, I'd urge consideration of going to e2fsprogs 1.43.9. This will get you most of the latest bug fixes, including some that could cause massive file system corruption and data loss (relative to e2fsprogs 1.42.x) in the right (wrong) circumstances.] --are you saying that 1.39.9/1.44.0 ought to not only go to trusty-backports and xenial-backports, but also then into 'updates' to be 'pushed to all users' -- that needs some fiddly SRU process ? I note Debian haven't pushed such an update back to jessie/wheezy either. I (suspect) Canonical will require significant 'evidence'/'bug-reports' for backports to become 'updates' in this circumstance... HOPEFULLY 1.44.0 into bionic will be easier. Hope that helps, -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming Status in e2fsprogs package in Ubuntu: Triaged Bug description: In the Trusty release notes "Metadata checksumming" is listed as one of the tech highlights of kernel 3.13. https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#New_features_in_14.04_LTS However, the userland tools do not support this kernel feature. To the best of my knowledge this will be supported in 1.43, and won't be backported to 1.42. IMHO this is very misleading. It's like a car salesperson sold you a sports car with an V8 engine. After you drove it home, you opened the hood and realized only 6 cylinders are working because 2 of the spark plugs were not included, and you have to buy aftermarket ones. BTW, I've been following the development of e2fsprogs for over a year. 1.43 release has been in limbo for God knows how long :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1601997] Re: Ubuntu 16.10 installer sets metadata_csum option on ext4 partition which is incompatible with other LTS Ubuntu versions
Canonical please read Theodore Tso's Comment #4 above, and consider for
Ubuntu 18.04 LTS!
This "64bit,metadata_csum" creates compatibility-issues even with 16.04
LTS, and does not seem to provide a huge benefit [>16TB fs support,
slightly stronger metadata checksumming].
This creates all sorts of problems for compatibility/portability of
filesystems, e.g.:-
* dual-booting 18.04, even previous LTS version cannot fsck the filesystem.
* "ext4 portable disks" created by 18.04 similarly same problem.
* Also consider how wide is the 64bit,metadata_csum support anyway, users may
want disks to work with many distros/drivers? Canonical's
commercial-supporters may have views herein?. -- the linked bugreport also
mentions another issue with hwe-edge and LVM.
Also note, turning off the 64bit,metadata_csum when required is a total
PAIN, needing filesystem offline, fsck and tune2fs in careful
concert.
In my view, the 16.04 LTS mke2fs.conf [ ext4{} stanza with
"auto_64-bit_support = 1" and NO "64bit,metadata_csum" in "features" ]
should be seriously-considered for 18.04 "LTS" (even if 18.10 onwards follow
Debian).
As tytso says, this 'change' has been "Decision-by-Default" due to
importing a Debian upstream package, I would like Canonical to make an
'informed and considered decision' about this please!.
Hope that helps!
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1601997
Title:
Ubuntu 16.10 installer sets metadata_csum option on ext4 partition
which is incompatible with other LTS Ubuntu versions
Status in e2fsprogs package in Ubuntu:
Triaged
Bug description:
Ubuntu 16.10 installer sets metadata_csum option on ext4 partition
which is incompatible with other LTS Ubuntu versions (12.04 LTS, 14.04
LTS, 16.04 LTS).
Steps to reproduce:
1. Download Ubuntu 16.10 installation media.
2. Install Ubuntu.
3. Try to do fsck -fy /dev/sdX1 from other supported Ubuntu distro.
Expected results:
User can check and fix errors on ext4 filesystem, created on Ubuntu 16.10.
Actual results:
User can not check and fix errors on ext4 filesystem because of lack of
'metadata_csum' option in previous LTS Ubuntu versions.
The only one working solution was to scan from 16.10 live install media.
Note:
it is known, that Dan Watkins disabled metadata_csum when creating ext4
filesystems ( see
http://bazaar.launchpad.net/~daniel-thewatkins/maas-images/fix-yakkety-builds/revision/305
). It is good solution.
ProblemType: Bug
DistroRelease: Ubuntu 16.10
Package: e2fsprogs 1.43.1-1
ProcVersionSignature: Ubuntu 4.4.0-30.49-generic 4.4.13
Uname: Linux 4.4.0-30-generic i686
ApportVersion: 2.20.2-0ubuntu1
Architecture: i386
CurrentDesktop: Unity
Date: Mon Jul 11 23:42:49 2016
SourcePackage: e2fsprogs
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1601997/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1365874] Re: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming
Ubuntu 18.04 may well enable (under review) 64bit,metadata_csum by default, thereby creating ext4 filesystems that are not compatible with e2fsck on Ubuntu-16.04 LTS (or 14.04)? This creates all sorts of problems for compatibility/portability of filesystems, for e.g.:- * dual-booting 18.04 and older LTS versions * "ext4 portable disks" do not work. * (notice also Ken's hwe-edge/lvm issue above too). I strongly support that Xenial gets a backport of e2fsprogs-1.43 (as requested) so that this compatibility-annoyance is ameliorated, at least. Debian have already done this, created a "jessie-backports" e2fsprogs=1.43.3-1~bpo8+1 Hopefully tytso can advise us on the best version of e2fsprogs to backport (18.04 currently has 1.43.9-2). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1365874 Title: Ubuntu 12.04 LTS, 14.04 LTS, 16.04 LTS do not support ext4 metadata checksumming Status in e2fsprogs package in Ubuntu: Triaged Bug description: In the Trusty release notes "Metadata checksumming" is listed as one of the tech highlights of kernel 3.13. https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#New_features_in_14.04_LTS However, the userland tools do not support this kernel feature. To the best of my knowledge this will be supported in 1.43, and won't be backported to 1.42. IMHO this is very misleading. It's like a car salesperson sold you a sports car with an V8 engine. After you drove it home, you opened the hood and realized only 6 cylinders are working because 2 of the spark plugs were not included, and you have to buy aftermarket ones. BTW, I've been following the development of e2fsprogs for over a year. 1.43 release has been in limbo for God knows how long :( To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1365874/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 57091] Re: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > Bog standard 16.04 has it turned on (from the above referenced 10 > -network-security.conf). > But, if you then enabled ufw, it gets disabled, due to the default > setting in /etc/ufw/sysctl.conf. > There seems to be serious debate as to whether or not enabling it is > correct. I haven't seen why not to enable use of adaptive syncookies, aiui this creates no _disadvantage_ if not being triggered... I CAN understand that for some scenarios the 'right thing to do' is Increase the tcp_max_syn_backlog as cookies are triggering too easily, even then it won't stop connections being accepted albeit with less tcp options possible, but then without syncookies the connections would be dropped as the syn queue fills... > What I know is that I just spent two hours trying to figure out why SANE > took forever to detect my network scanner, and this syslog entry clued > me in: > Oct 6 22:54:26 hiro kernel: [48562.817258] TCP: request_sock_TCP: > Possible SYN flooding on port 34029. Dropping request. Check SNMP > The dropped request was responsible for the delay. If I enable syn > cookies, I get: > Oct 6 22:57:28 hiro kernel: [48744.796029] TCP: request_sock_TCP: > Possible SYN flooding on port 42041. Sending cookies. Check SNMP > capture it, there's ONE SYN request and the kernel thinks it's a > "flood".. which makes no sense. Weird :). I can't say I'm familiar with uwf, but I wonder if it is somehow oversensitive in its' own ip(6)tables or they are fiddling with:- /proc/sys/net/ipv4/tcp_max_syn_backlog Do raise bug in the ufw // ufw sysctl.conf Also email me separately the relevant bug numbers etc., be curious to see!! - --Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Topal (http://freshmeat.net/projects/topal) iF4EAREIAAYFAlf3SqEACgkQA62i3HuJ2aHNCwEAnK4NvLNm/tKHzFNSEK+KRNMB 6hZOZ6tcnbecljP1+dAA/3C0bmEHFXEzeLF3xYNSco+py2TbD2bNPzXbG0NKsupb =Fh0+ -END PGP SIGNATURE- -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/57091 Title: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense... Status in procps package in Ubuntu: Fix Released Bug description: This is intended to be a 'wishlist' wulnerability -- w.r.t. procps and Edgy. In my opinion,the /etc/sysctl.conf should have 'proc/sys/net/ipv4/tcp_syncookies=1' in order to permit the linux SYNcookies syn-flood trivial DoS attack to be mitigated as-necessary, by default. Note that the disadvantages of connections initiated w/ SYNcookies enabled only apply when the system is under attack (SYN queue getting rather full), as the syncookies reply-with-only-one-SYN+ACK behaviour only 'kicks in' when the system has a SYN_RECVD backlog problem. (If SYNcookies were not permitted incoming TCP connections have a very low chance of succeeding at all while under SYN-flood attack). Without this setting enabled, any TCP services on the machine can be DoSed from a dial-up line sending a stream of SYN packets from weird source addresses to open TCP ports like Samba/VNC/http/whatever Does anybody have any legitimate reason tcp_syncookies should be disabled? Some people claimed that SYNcookies break some RFCs once but I have not seen any evidence to this effect, only notes from djb saying that this is not true. Comments wanted please ;-) Thankyou in advance, -- enyc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/57091/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 57091] Re: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense...
Upstream kernel have decided to enable syncookies by default (according to that debian bug, since Linux 2.6.37!). This makes sense, as the main downsides have already been resolved (especially window scaling even under syncookies-activation), and this feature only kicks-in if the SYN-queue is overloaded. We might now consider taking out this (now superfluous) tcp_syncookies entry from /etc/sysctl.d/10-network-security.conf ... I think, a similar situation has now arisen with respect to the "tcp_ecn" setting, where the (conservative) (enabled by default) fallback mechanism in the kernel, along with the rarity of ecn- intolerance, along with the wide ECN-adoption in practice in Apple ios / MAC OS X now, along with the importance of ECN for smooth responsive internet in the face of congestion, means that this tcp_ecn setting should similarly be seriously considered. This should be the subject of new bug report right-soon-now =). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/57091 Title: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense... Status in procps package in Ubuntu: Fix Released Bug description: This is intended to be a 'wishlist' wulnerability -- w.r.t. procps and Edgy. In my opinion,the /etc/sysctl.conf should have 'proc/sys/net/ipv4/tcp_syncookies=1' in order to permit the linux SYNcookies syn-flood trivial DoS attack to be mitigated as-necessary, by default. Note that the disadvantages of connections initiated w/ SYNcookies enabled only apply when the system is under attack (SYN queue getting rather full), as the syncookies reply-with-only-one-SYN+ACK behaviour only 'kicks in' when the system has a SYN_RECVD backlog problem. (If SYNcookies were not permitted incoming TCP connections have a very low chance of succeeding at all while under SYN-flood attack). Without this setting enabled, any TCP services on the machine can be DoSed from a dial-up line sending a stream of SYN packets from weird source addresses to open TCP ports like Samba/VNC/http/whatever Does anybody have any legitimate reason tcp_syncookies should be disabled? Some people claimed that SYNcookies break some RFCs once but I have not seen any evidence to this effect, only notes from djb saying that this is not true. Comments wanted please ;-) Thankyou in advance, -- enyc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/57091/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
