this post was submitted on 04 Aug 2024
320 points (87.7% liked)

linuxmemes

21222 readers
86 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.

  • Please report posts and comments that break these rules!

    founded 1 year ago
    MODERATORS
     
    you are viewing a single comment's thread
    view the rest of the comments
    [–] FiskFisk33@startrek.website 46 points 3 months ago (5 children)

    sure, but what os wouldn't break if you did this?

    [–] bjoern_tantau@swg-empire.de 30 points 3 months ago (1 children)

    Just about any Linux I've ever used keeps the previous kernel version and initrd around. And nowadays snapper makes a new snapshot before and after every package installation or update.

    So, I'd think there are a lot.

    [–] axum@lemmy.blahaj.zone 7 points 3 months ago

    So what I'm hearing is install Linux-LTS and pacsnap

    [–] gaylord_fartmaster@lemmy.world 15 points 3 months ago (1 children)

    Plus in Linux you can actually fix this with a live USB, while on Windows you can run startup repair and hope for the best.

    [–] superkret@feddit.org 6 points 3 months ago* (last edited 3 months ago)

    In Windows you can also fix this with a live Windows USB, manually.

    [–] MangoPenguin@lemmy.blahaj.zone 13 points 3 months ago (3 children)

    Windows doesn't in my experience, it's surprisingly robust.

    But also I thought Linux distros normally keep the old Kernel around after an update so stuff like this doesn't cause a boot failure?

    [–] 9point6@lemmy.world 7 points 3 months ago

    Yeah windows "cumulative update" upgrades for the past couple of years basically duplicate the whole system directory and apply the update to that leaving the existing one to roll back to if anything fails

    [–] dan@upvote.au 2 points 3 months ago* (last edited 3 months ago)

    Windows updates (and Windows Installer) are transactional. If the update or installation fails, it knows exactly how to revert back to the previous state.

    Windows Installer supports this across multiple packages too - for example, a game might need some version of DirectX libraries which needs some version of the Visual C++ runtime (probably showing my age because I doubt games come bundled with DirectX any more). If one of the packages fails to install, it can handle rolling everything back. Linux can sometimes leave your system in a broken state when this happens, requiring you to manually resolve the issue - for example, on a Debian-based system if the postinst script for a package fails.

    [–] SpaceCadet@feddit.nl 1 points 3 months ago (1 children)

    But also I thought Linux distros normally keep the old Kernel around after an update so stuff like this doesn’t cause a boot failure?

    Arch has no concept of "previous package", so it doesn't do this.

    You could install linux-lts (or one of the other alternative kernels) side by side with the linux package, so you always have a bootable fallback, but like most things on Arch it's not enforced.

    [–] MangoPenguin@lemmy.blahaj.zone 2 points 3 months ago

    That's pretty wild, I guess arch is not meant to hold your hand at all so it makes sense.

    [–] superkret@feddit.org 11 points 3 months ago (2 children)

    Any immutable distro, Debian, Ubuntu, all their derivatives, Fedora, all its derivatives, OpenSUSE, Slackware, ...
    Basically, 95+% of installed Linux systems would retain the old or a backup kernel during an upgrade.

    [–] FiskFisk33@startrek.website 3 points 3 months ago

    good answer to a bad and uninformed question, thanks.

    [–] rudyharrelson@lemmy.radio 2 points 3 months ago (2 children)

    Any immutable distro, Debian, Ubuntu, all their derivatives

    Debian and Ubuntu are not immutable distributions by default, unless I am mistaken.

    [–] superkret@feddit.org 2 points 3 months ago

    Any immutable distro and Debian and Ubuntu and all their derivatives

    [–] dan@upvote.au 2 points 3 months ago (1 children)

    They weren't saying Debian and Ubuntu are immutable - they were saying "any immutable distro", "Debian", and "Ubuntu" as three separate items in a list.

    [–] rudyharrelson@lemmy.radio 2 points 3 months ago (1 children)
    [–] zea_64@lemmy.blahaj.zone 3 points 3 months ago (2 children)

    If it was on something like BTRFS it'd probably be fine, though I imagine there's still a small window where the FS could flush while the file is being written. renameat2 has the EXCHANGE flag to atomically switch 2 files, so if arch maintainers want to fix it they could do

    1. Write to temporary file
    2. Fsync temporary file
    3. Renameat2 EXCHANGE temporary and target
    4. Fsync directory (optional, since a background flush would still be atomic, just might take some time)
    [–] dan@upvote.au 1 points 3 months ago

    renameat2

    I read this as "rena meat 2" and was very confused

    [–] FQQD@lemmy.ohaa.xyz 0 points 3 months ago (1 children)
    [–] kolorafa@lemmy.world 7 points 3 months ago

    Just having btrfs is not enough, you need to have automatic snapshots (or do them manually) before doing updates and configured grub to allow you to rollback.

    Personally, I'm to lazy to configure stuff like that, I rather just pick my Vetroy USB from backpack, boot into live image and just fix it (while learning something/new interesting) than spend time preventing something that might never happen to me :)