Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

Chunchunmaru_

Member
  • Content Count

    388
  • Joined

  • Last visited


Reputation Activity

  1. Like
    Chunchunmaru_ reacted to Arika S in LGBT community   
    @kaiju_wars you inspired me to do an anime style self portrait.
     
    so if anyone wanted a vague idea of what i look like
     

     
    doing self portraits feels....weird
  2. Agree
    Chunchunmaru_ got a reaction from mrchow19910319 in Not Bourne Again... Apple to replace Bash with ZSH as default shell on MacOS Catalina   
    That's actually an improvement regardless of the license
  3. Agree
    Chunchunmaru_ got a reaction from Sauron in Not Bourne Again... Apple to replace Bash with ZSH as default shell on MacOS Catalina   
    That's actually an improvement regardless of the license
  4. Agree
    Chunchunmaru_ got a reaction from LAwLz in Not Bourne Again... Apple to replace Bash with ZSH as default shell on MacOS Catalina   
    That's actually an improvement regardless of the license
  5. Agree
    Chunchunmaru_ got a reaction from simson0606 in Not Bourne Again... Apple to replace Bash with ZSH as default shell on MacOS Catalina   
    That's actually an improvement regardless of the license
  6. Agree
    Chunchunmaru_ got a reaction from moriel5 in NVIDIA Afterburner on Linux - the only thing stopping me   
    Another similar program is GreenWithEnvy

    https://gitlab.com/leinardi/gwe
  7. Informative
    Chunchunmaru_ got a reaction from Namtabnel in Dualshock 4 on linux (mint 19.1)   
    Wait... What does it mean it doesn't work?

    The DS4 controller had drivers for ages, now what matters here is the way the DS4 controller is grabbed.

    By default, evdev should be natively supported (wine games should be using this, as for native games) but steam big picture and RPCS3 have another method called "hidraw" so you should be installing some udev rules manually or either with the steam-devices package
  8. Agree
    Chunchunmaru_ reacted to Trixanity in AMD RX 5700 Navi New arch   
    There is no confirmation whether this is GCN or not. In all likelihood it's an overhauled GCN with some big improvements (probably some backported stuff from whatever next gen arch they're working on). Considering the Linux kernel still refers to it as GCN it's probably a much improved GCN. Anandtech also says AMD kept quiet about what kind of beast this is and not mentioning the word GCN at all.
  9. Funny
    Chunchunmaru_ got a reaction from SlimyPython in Linux 5.1 kernel hit by SSD TRIM bug which causes massive data loss   
    Summary: Looks like there is a bad commit in the Linux 5.1.2 kernel, which in some circumstances issuing a ATA TRIM causes actual data to be discarded instead of deleted blocks.

    Looks like Windows 10 is not the only one to get data loss after updates.

    So far, it appears the issue happens if:
    LUKS+dm_crypt if:(Linux kernel software encryption) A Samsung SSD is used Linux 5.1.2 is used  

    It should be noted that this happens only when ATA TRIM is issued, so when the "discard" fstab option is used or the weekly "fstrim" service cron/systemd timer is enabled, or a manual fstrim is issued through CLI.

    Ubuntu based distros should not be affected by this as it doesn't use the Linux 5.1 kernel.

    Arch Linux/Manjaro users sadly are affected, on Manjaro the fstrim is enabled automatically, while on Arch it has to be issued or configured manually.
    I do not know if other distros are affected

    Since it's a bug related to the device mapper, this could happen on any filesystem

    Mitigation: The best thing you can do is to shut down the system immediately and use another kernel.
    You can also try disabling the fstrim timer by issuing this command, but it's not very recommended:
    `systemctl disable fstrim.timer` `systemctl stop fstrim.timer` Or if you are an expert, checking in /etc/fstab for the discard parameter (but you are basically screwed up if you have this enabled as it's a continuous trim)
    Remember for your SSD health and optimal performance, to re-enable those options once everything is over by just replacing disable with enable, and stop with start.

    Source:
    https://www.redhat.com/archives/dm-devel/2019-May/msg00084.html
    https://bbs.archlinux.org/viewtopic.php?id=246569
    https://bugs.archlinux.org/task/62693
    https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg87788.html
    https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-FSTRIM-Bug
  10. Like
    Chunchunmaru_ got a reaction from Sauron in Linux 5.1 kernel hit by SSD TRIM bug which causes massive data loss   
    *Runs linux on her PS3*

    Yeah...They are
  11. Like
    Chunchunmaru_ got a reaction from TechyBen in Linux 5.1 kernel hit by SSD TRIM bug which causes massive data loss   
    Summary: Looks like there is a bad commit in the Linux 5.1.2 kernel, which in some circumstances issuing a ATA TRIM causes actual data to be discarded instead of deleted blocks.

    Looks like Windows 10 is not the only one to get data loss after updates.

    So far, it appears the issue happens if:
    LUKS+dm_crypt if:(Linux kernel software encryption) A Samsung SSD is used Linux 5.1.2 is used  

    It should be noted that this happens only when ATA TRIM is issued, so when the "discard" fstab option is used or the weekly "fstrim" service cron/systemd timer is enabled, or a manual fstrim is issued through CLI.

    Ubuntu based distros should not be affected by this as it doesn't use the Linux 5.1 kernel.

    Arch Linux/Manjaro users sadly are affected, on Manjaro the fstrim is enabled automatically, while on Arch it has to be issued or configured manually.
    I do not know if other distros are affected

    Since it's a bug related to the device mapper, this could happen on any filesystem

    Mitigation: The best thing you can do is to shut down the system immediately and use another kernel.
    You can also try disabling the fstrim timer by issuing this command, but it's not very recommended:
    `systemctl disable fstrim.timer` `systemctl stop fstrim.timer` Or if you are an expert, checking in /etc/fstab for the discard parameter (but you are basically screwed up if you have this enabled as it's a continuous trim)
    Remember for your SSD health and optimal performance, to re-enable those options once everything is over by just replacing disable with enable, and stop with start.

    Source:
    https://www.redhat.com/archives/dm-devel/2019-May/msg00084.html
    https://bbs.archlinux.org/viewtopic.php?id=246569
    https://bugs.archlinux.org/task/62693
    https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg87788.html
    https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-FSTRIM-Bug
  12. Agree
    Chunchunmaru_ got a reaction from Brooksie359 in Linux 5.1 kernel hit by SSD TRIM bug which causes massive data loss   
    It's not completely clear at this point, the reporters of those issues look like to have in common only Samsung SSD's + LUKS+LVM encryption, Samsung SSD's are pretty common though...
  13. Funny
    Chunchunmaru_ got a reaction from Bananasplit_00 in Linux 5.1 kernel hit by SSD TRIM bug which causes massive data loss   
    I miss the times where Torvalds himself roasts people with bad kernel commits...
  14. Informative
    Chunchunmaru_ got a reaction from Bananasplit_00 in Linux 5.1 kernel hit by SSD TRIM bug which causes massive data loss   
    Summary: Looks like there is a bad commit in the Linux 5.1.2 kernel, which in some circumstances issuing a ATA TRIM causes actual data to be discarded instead of deleted blocks.

    Looks like Windows 10 is not the only one to get data loss after updates.

    So far, it appears the issue happens if:
    LUKS+dm_crypt if:(Linux kernel software encryption) A Samsung SSD is used Linux 5.1.2 is used  

    It should be noted that this happens only when ATA TRIM is issued, so when the "discard" fstab option is used or the weekly "fstrim" service cron/systemd timer is enabled, or a manual fstrim is issued through CLI.

    Ubuntu based distros should not be affected by this as it doesn't use the Linux 5.1 kernel.

    Arch Linux/Manjaro users sadly are affected, on Manjaro the fstrim is enabled automatically, while on Arch it has to be issued or configured manually.
    I do not know if other distros are affected

    Since it's a bug related to the device mapper, this could happen on any filesystem

    Mitigation: The best thing you can do is to shut down the system immediately and use another kernel.
    You can also try disabling the fstrim timer by issuing this command, but it's not very recommended:
    `systemctl disable fstrim.timer` `systemctl stop fstrim.timer` Or if you are an expert, checking in /etc/fstab for the discard parameter (but you are basically screwed up if you have this enabled as it's a continuous trim)
    Remember for your SSD health and optimal performance, to re-enable those options once everything is over by just replacing disable with enable, and stop with start.

    Source:
    https://www.redhat.com/archives/dm-devel/2019-May/msg00084.html
    https://bbs.archlinux.org/viewtopic.php?id=246569
    https://bugs.archlinux.org/task/62693
    https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg87788.html
    https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-FSTRIM-Bug
  15. Like
    Chunchunmaru_ got a reaction from justpoet in Linux 5.1 kernel hit by SSD TRIM bug which causes massive data loss   
    I miss the times where Torvalds himself roasts people with bad kernel commits...
  16. Informative
    Chunchunmaru_ got a reaction from Ithanul in Linux 5.1 kernel hit by SSD TRIM bug which causes massive data loss   
    Summary: Looks like there is a bad commit in the Linux 5.1.2 kernel, which in some circumstances issuing a ATA TRIM causes actual data to be discarded instead of deleted blocks.

    Looks like Windows 10 is not the only one to get data loss after updates.

    So far, it appears the issue happens if:
    LUKS+dm_crypt if:(Linux kernel software encryption) A Samsung SSD is used Linux 5.1.2 is used  

    It should be noted that this happens only when ATA TRIM is issued, so when the "discard" fstab option is used or the weekly "fstrim" service cron/systemd timer is enabled, or a manual fstrim is issued through CLI.

    Ubuntu based distros should not be affected by this as it doesn't use the Linux 5.1 kernel.

    Arch Linux/Manjaro users sadly are affected, on Manjaro the fstrim is enabled automatically, while on Arch it has to be issued or configured manually.
    I do not know if other distros are affected

    Since it's a bug related to the device mapper, this could happen on any filesystem

    Mitigation: The best thing you can do is to shut down the system immediately and use another kernel.
    You can also try disabling the fstrim timer by issuing this command, but it's not very recommended:
    `systemctl disable fstrim.timer` `systemctl stop fstrim.timer` Or if you are an expert, checking in /etc/fstab for the discard parameter (but you are basically screwed up if you have this enabled as it's a continuous trim)
    Remember for your SSD health and optimal performance, to re-enable those options once everything is over by just replacing disable with enable, and stop with start.

    Source:
    https://www.redhat.com/archives/dm-devel/2019-May/msg00084.html
    https://bbs.archlinux.org/viewtopic.php?id=246569
    https://bugs.archlinux.org/task/62693
    https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg87788.html
    https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-FSTRIM-Bug
  17. Like
    Chunchunmaru_ reacted to Alef in Linux 5.1 kernel hit by SSD TRIM bug which causes massive data loss   
    Using LVM Check, dm-crypt Check, Samsung SSD check, Kernel 5.1 nope, running 4.9. Thanks for the heads up, could of been affected by this if I decided to update to a more recent kernel. 
  18. Agree
    Chunchunmaru_ got a reaction from dfsdfgfkjsefoiqzemnd in Linux 5.1 kernel hit by SSD TRIM bug which causes massive data loss   
    I miss the times where Torvalds himself roasts people with bad kernel commits...
  19. Funny
    Chunchunmaru_ got a reaction from Sauron in Linux 5.1 kernel hit by SSD TRIM bug which causes massive data loss   
    I miss the times where Torvalds himself roasts people with bad kernel commits...
  20. Funny
    Chunchunmaru_ reacted to sazrocks in Linux 5.1 kernel hit by SSD TRIM bug which causes massive data loss   
    Has SSD in system running 5.1.x
    Heart rate increases
    Said system is running 5.1.2
    Heart rate increases further
    Said SSD is a samsung
    Heart rate increases even further
    Doesn’t use LUKS
    Heart rate stabilizes
     
    uh, yeah, still gonna go update the kernel on that machine right now though.
  21. Funny
    Chunchunmaru_ got a reaction from r2724r16 in Linux 5.1 kernel hit by SSD TRIM bug which causes massive data loss   
    Summary: Looks like there is a bad commit in the Linux 5.1.2 kernel, which in some circumstances issuing a ATA TRIM causes actual data to be discarded instead of deleted blocks.

    Looks like Windows 10 is not the only one to get data loss after updates.

    So far, it appears the issue happens if:
    LUKS+dm_crypt if:(Linux kernel software encryption) A Samsung SSD is used Linux 5.1.2 is used  

    It should be noted that this happens only when ATA TRIM is issued, so when the "discard" fstab option is used or the weekly "fstrim" service cron/systemd timer is enabled, or a manual fstrim is issued through CLI.

    Ubuntu based distros should not be affected by this as it doesn't use the Linux 5.1 kernel.

    Arch Linux/Manjaro users sadly are affected, on Manjaro the fstrim is enabled automatically, while on Arch it has to be issued or configured manually.
    I do not know if other distros are affected

    Since it's a bug related to the device mapper, this could happen on any filesystem

    Mitigation: The best thing you can do is to shut down the system immediately and use another kernel.
    You can also try disabling the fstrim timer by issuing this command, but it's not very recommended:
    `systemctl disable fstrim.timer` `systemctl stop fstrim.timer` Or if you are an expert, checking in /etc/fstab for the discard parameter (but you are basically screwed up if you have this enabled as it's a continuous trim)
    Remember for your SSD health and optimal performance, to re-enable those options once everything is over by just replacing disable with enable, and stop with start.

    Source:
    https://www.redhat.com/archives/dm-devel/2019-May/msg00084.html
    https://bbs.archlinux.org/viewtopic.php?id=246569
    https://bugs.archlinux.org/task/62693
    https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg87788.html
    https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-FSTRIM-Bug
  22. Informative
    Chunchunmaru_ got a reaction from Sauron in Linux 5.1 kernel hit by SSD TRIM bug which causes massive data loss   
    Summary: Looks like there is a bad commit in the Linux 5.1.2 kernel, which in some circumstances issuing a ATA TRIM causes actual data to be discarded instead of deleted blocks.

    Looks like Windows 10 is not the only one to get data loss after updates.

    So far, it appears the issue happens if:
    LUKS+dm_crypt if:(Linux kernel software encryption) A Samsung SSD is used Linux 5.1.2 is used  

    It should be noted that this happens only when ATA TRIM is issued, so when the "discard" fstab option is used or the weekly "fstrim" service cron/systemd timer is enabled, or a manual fstrim is issued through CLI.

    Ubuntu based distros should not be affected by this as it doesn't use the Linux 5.1 kernel.

    Arch Linux/Manjaro users sadly are affected, on Manjaro the fstrim is enabled automatically, while on Arch it has to be issued or configured manually.
    I do not know if other distros are affected

    Since it's a bug related to the device mapper, this could happen on any filesystem

    Mitigation: The best thing you can do is to shut down the system immediately and use another kernel.
    You can also try disabling the fstrim timer by issuing this command, but it's not very recommended:
    `systemctl disable fstrim.timer` `systemctl stop fstrim.timer` Or if you are an expert, checking in /etc/fstab for the discard parameter (but you are basically screwed up if you have this enabled as it's a continuous trim)
    Remember for your SSD health and optimal performance, to re-enable those options once everything is over by just replacing disable with enable, and stop with start.

    Source:
    https://www.redhat.com/archives/dm-devel/2019-May/msg00084.html
    https://bbs.archlinux.org/viewtopic.php?id=246569
    https://bugs.archlinux.org/task/62693
    https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg87788.html
    https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-FSTRIM-Bug
  23. Informative
    Chunchunmaru_ got a reaction from sowon in Linux 5.1 kernel hit by SSD TRIM bug which causes massive data loss   
    Summary: Looks like there is a bad commit in the Linux 5.1.2 kernel, which in some circumstances issuing a ATA TRIM causes actual data to be discarded instead of deleted blocks.

    Looks like Windows 10 is not the only one to get data loss after updates.

    So far, it appears the issue happens if:
    LUKS+dm_crypt if:(Linux kernel software encryption) A Samsung SSD is used Linux 5.1.2 is used  

    It should be noted that this happens only when ATA TRIM is issued, so when the "discard" fstab option is used or the weekly "fstrim" service cron/systemd timer is enabled, or a manual fstrim is issued through CLI.

    Ubuntu based distros should not be affected by this as it doesn't use the Linux 5.1 kernel.

    Arch Linux/Manjaro users sadly are affected, on Manjaro the fstrim is enabled automatically, while on Arch it has to be issued or configured manually.
    I do not know if other distros are affected

    Since it's a bug related to the device mapper, this could happen on any filesystem

    Mitigation: The best thing you can do is to shut down the system immediately and use another kernel.
    You can also try disabling the fstrim timer by issuing this command, but it's not very recommended:
    `systemctl disable fstrim.timer` `systemctl stop fstrim.timer` Or if you are an expert, checking in /etc/fstab for the discard parameter (but you are basically screwed up if you have this enabled as it's a continuous trim)
    Remember for your SSD health and optimal performance, to re-enable those options once everything is over by just replacing disable with enable, and stop with start.

    Source:
    https://www.redhat.com/archives/dm-devel/2019-May/msg00084.html
    https://bbs.archlinux.org/viewtopic.php?id=246569
    https://bugs.archlinux.org/task/62693
    https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg87788.html
    https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-FSTRIM-Bug
  24. Informative
    Chunchunmaru_ got a reaction from Cyberspirit in Linux 5.1 kernel hit by SSD TRIM bug which causes massive data loss   
    Summary: Looks like there is a bad commit in the Linux 5.1.2 kernel, which in some circumstances issuing a ATA TRIM causes actual data to be discarded instead of deleted blocks.

    Looks like Windows 10 is not the only one to get data loss after updates.

    So far, it appears the issue happens if:
    LUKS+dm_crypt if:(Linux kernel software encryption) A Samsung SSD is used Linux 5.1.2 is used  

    It should be noted that this happens only when ATA TRIM is issued, so when the "discard" fstab option is used or the weekly "fstrim" service cron/systemd timer is enabled, or a manual fstrim is issued through CLI.

    Ubuntu based distros should not be affected by this as it doesn't use the Linux 5.1 kernel.

    Arch Linux/Manjaro users sadly are affected, on Manjaro the fstrim is enabled automatically, while on Arch it has to be issued or configured manually.
    I do not know if other distros are affected

    Since it's a bug related to the device mapper, this could happen on any filesystem

    Mitigation: The best thing you can do is to shut down the system immediately and use another kernel.
    You can also try disabling the fstrim timer by issuing this command, but it's not very recommended:
    `systemctl disable fstrim.timer` `systemctl stop fstrim.timer` Or if you are an expert, checking in /etc/fstab for the discard parameter (but you are basically screwed up if you have this enabled as it's a continuous trim)
    Remember for your SSD health and optimal performance, to re-enable those options once everything is over by just replacing disable with enable, and stop with start.

    Source:
    https://www.redhat.com/archives/dm-devel/2019-May/msg00084.html
    https://bbs.archlinux.org/viewtopic.php?id=246569
    https://bugs.archlinux.org/task/62693
    https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg87788.html
    https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.1-FSTRIM-Bug
  25. Informative
    Chunchunmaru_ got a reaction from Crunchy Dragon in Linux 5.1 kernel hit by SSD TRIM bug which causes massive data loss   
    It's not completely clear at this point, the reporters of those issues look like to have in common only Samsung SSD's + LUKS+LVM encryption, Samsung SSD's are pretty common though...
×