fixed by @skullgiver : it was an entry in /etc/crypttab.

Thanks for all the help everyone. This was an awesome experience.


I don’t know how stupid this was to do but many articles suggested it should be fine.

I resized my mouted root partition. Showed a bunch of warnings on resizing a mounted drive but it worked. Also did a sudo resize2fs /dev/sdaX to complete it.

Went from: winEFI, Win11, EFI, root, swap, data1, data2, win-recovery

To : winEFI, Win11, EFI, root, new-data1, win-recovery

But now every boot takes an additional 60-90 seconds with a blank screen. Pressing ESC shows the above log.

I am unsure of how to fix this or even what caused this. The root partition still starts from the same and only grew to right. Is this because of the deleted swap ?

The operations were performed via GParted but I followed this : https://askubuntu.com/questions/24027/how-can-i-resize-an-ext-root-partition-at-runtime

PS: Pop 22.04 Nvidia. Relatively fresh (~3mo) install but severely miscalculated how much size I needed.

  • Skull giver@popplesburger.hilciferous.nl
    link
    fedilink
    arrow-up
    41
    arrow-down
    1
    ·
    edit-2
    1 year ago

    The error log you posted shows a corrupted disk getting repaired. If you see it every time, you probably need a good offline fsck.

    The hang is probably the missing swap partition. Remove it from /etc/fstab and possible the resume= parameter in your bootloader. The resume parameter tells the system to try to resume a hibernated system from a specific partition, and it may get stuck searching for that.

    • nestEggParrot@lemmy.sdf.orgOP
      link
      fedilink
      arrow-up
      5
      ·
      1 year ago

      Tried checking for systemd-boot config file to look for resume=.

      This is the most relevant config file I found and didn’t find resume on it. Am I looking at the right place ?

      ❯ sudo cat /boot/efi/loader/entries/Pop_OS-current.conf 
      title Pop!_OS
      linux /EFI/Pop_OS-f5a850fb-0b54-49f7-b84c-09d05b7d910e/vmlinuz.efi
      initrd /EFI/Pop_OS-f5a850fb-0b54-49f7-b84c-09d05b7d910e/initrd.img
      options root=UUID=f5a850fb-0b54-49f7-b84c-09d05b7d910e ro quiet loglevel=0 systemd.show_status=false splash
      

      And yes the disk repair was only one off. Didn’t get it subsequent boots.

      • That would be the right place where you would find the resume parameter, yes. Looks like it’s not hibernation after all!

        Something else that may cause the issue: you say you’ve edited fstab, but you may also need to run sudo update-initramfs -u -k all to make the change propagate through the early boot process. That command will run for a while but I think that might fix the issue.

          • Last thing I can think of crypttab. You seem to have encrypted your swap, so you may have an entry in /etc/crypttab that’s causing this issue. Remove it from there and update the initramfs again.

            If that’s not the problem either, I would just run sudo grep -r c0a6e61d /etc and see what files still reference the partition.

            • nestEggParrot@lemmy.sdf.orgOP
              link
              fedilink
              arrow-up
              6
              ·
              1 year ago

              This fixed it. Commented the crypttab entry and no more wait on boot. Thanks for your time and the clear instructions to follow. Much appreciated.

  • regalia@literature.cafe
    link
    fedilink
    arrow-up
    19
    arrow-down
    1
    ·
    1 year ago

    The issue here is that you’re clearly running an orphanage here and keep killing off the children (processes)

  • FrostyPolicy@suppo.fi
    link
    fedilink
    arrow-up
    11
    ·
    1 year ago

    My guess would be it’s looking for the removed swap partition. Comment out or remove the entry for swap from /etc/fstab.

    It looks something like this:

    UUID=b27bc530-5a8f-4160-8814-95679e0f4987 swap swap defaults 0 0

    • nestEggParrot@lemmy.sdf.orgOP
      link
      fedilink
      arrow-up
      4
      ·
      edit-2
      1 year ago

      Have commented out the line in /etc/fstab

      ❯ swapon -a
      ❯ swapon -s
      Filename				Type		Size		Used		Priority
      /dev/zram0                              partition	16777212	0		1000
      

      Though it says /dev/zram0 and not my old swap partition, I believe this is still seeing the old swap ?

    • nestEggParrot@lemmy.sdf.orgOP
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      On reboot, the delay is still present. The line #/dev/mapper/cryptswap none swap defaults 0 0 is commented out in /etc/fstab.

      But it does wait 90s for the partition like you have mentioned. What do I edit to fix this ? That UUID is not in the fstab file.

  • Nsh@lemmy.ca
    link
    fedilink
    arrow-up
    6
    ·
    1 year ago

    I’ve seen another comment about this but I think you should try to check and repair the disk with fsck

  • bahmanm@lemmy.ml
    link
    fedilink
    English
    arrow-up
    6
    ·
    1 year ago

    Have you tried booting into recovery mode and perform a fsck on the drive - using the grub menu? Or you could boot via USB and try the procedure.

    • nestEggParrot@lemmy.sdf.orgOP
      link
      fedilink
      arrow-up
      3
      ·
      1 year ago

      I am a bit apprehensive about messing with the partition any more than I already have. A delay on a weekly boot isn’t so much of an issue but wanted to make sure this wasn’t something thats waiting to fail.

      At least until I backup all my data I’ll try above over the weekend when I would have time to reinstall if I mess it up.

      • bahmanm@lemmy.ml
        link
        fedilink
        English
        arrow-up
        7
        ·
        1 year ago

        messing with the partition any more than I already have

        Running fsck is a harmless and actually pretty useful operation, esp if you boot using a USB stick.

        But yes, never hurts to have backups - easier said than done 😂

  • tal@kbin.social
    link
    fedilink
    arrow-up
    3
    arrow-down
    1
    ·
    1 year ago

    But now every boot takes an additional 60-90 seconds with a blank screen.

    Hmm.

    Maybe whatever changes gparted did altered the root partition UUID; after it doesn’t come up, maybe your distro has some sort of fallback to find the partition?

    In /etc/fstab, you may have a line that looks something like this:

    UUID=3aafadcd-1d21-4c82-97f8-f872f341bbe2 /           ext4    errors=remount=ro        0       1
    
    

    If you run blkid, you can check and make sure that the UUID matches.

    Or, as someone else mentions, maybe it’s waiting for the deleted swap partition. Should be in the same file. Can comment out the reference to said swap partition.

    EDIT: Wait, I’m being silly. The reference to the root partition that you’re gonna care about is gonna be in the grub config file, not /etc/fstab. On my Debian system, that’s at /boot/grub/grub.cfg.

    • nestEggParrot@lemmy.sdf.orgOP
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      1 year ago

      Checked the UUID and it is the same on fstab although I am having trouble finding the config file for systemd-boot on my PopOS. Best match I found was /boot/efi/loader/entries/Pop_OS-current.conf and the UUID in there also matches from blkid.

  • BaroqueInMind@kbin.social
    link
    fedilink
    arrow-up
    5
    arrow-down
    10
    ·
    edit-2
    1 year ago

    PopOS

    There’s your problem. The solution here is to rather remind literally every single human that is capable of sapient thought that you run Arch, then install Arch. The more people you inform that you use Arch, the more stable the OS becomes. /s

    Edit: yes, also I am running Arch.