Problems updating with limited disk space

Post your terminal/konsole in- and output as text (no pictures) from:

inxi -Faz

[[email protected] old]$ inxi -Faz
System:
  Kernel: 5.15.12-zen1-1-zen x86_64 bits: 64 compiler: gcc v: 11.1.0
    parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
    root=UUID=657229c1-3537-4059-91ed-d7fbf1917eba rw [email protected]
    quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0
    systemd.unified_cgroup_hierarchy=1 loglevel=3
  Desktop: GNOME 41.2 tk: GTK 3.24.31 wm: gnome-shell dm: GDM 41.0
    Distro: Garuda Linux base: Arch Linux
Machine:
  Type: Laptop System: Acer product: Swift SF114-34 v: V1.08
    serial: <superuser required> Chassis: type: 10 serial: <superuser required>
  Mobo: JSL model: Labatt_JL v: V1.08 serial: <superuser required>
    UEFI: Insyde v: 1.08 date: 05/11/2021
Battery:
  ID-1: BAT0 charge: 41.4 Wh (79.8%) condition: 51.9/48.0 Wh (108.1%)
    volts: 12.0 min: 11.2 model: LGC KT0030G020 AP18C8K type: Li-ion
    serial: <filter> status: Discharging cycles: 4
CPU:
  Info: model: Intel Celeron N4500 bits: 64 type: MCP arch: Tremont family: 6
    model-id: 0x9C (156) stepping: 0 microcode: 0x1D
  Topology: cpus: 1x cores: 2 smt: <unsupported> cache: L1: 128 KiB
    desc: d-2x32 KiB; i-2x32 KiB L2: 1.5 MiB desc: 1x1.5 MiB L3: 4 MiB
    desc: 1x4 MiB
  Speed (MHz): avg: 1608 high: 1720 min/max: 800/2800 scaling:
    driver: intel_pstate governor: performance cores: 1: 1720 2: 1496
    bogomips: 4454
  Flags: ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: spec_store_bypass
    mitigation: Speculative Store Bypass disabled via prctl
  Type: spectre_v1
    mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2
    mitigation: Enhanced IBRS, IBPB: conditional, RSB filling
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: Intel JasperLake [UHD Graphics] vendor: Acer Incorporated ALI
    driver: i915 v: kernel bus-ID: 00:02.0 chip-ID: 8086:4e55 class-ID: 0300
  Device-2: Quanta HD User Facing type: USB driver: uvcvideo bus-ID: 1-4:3
    chip-ID: 0408:a094 class-ID: 0e02
  Display: x11 server: X.Org 1.21.1.2 compositor: gnome-shell driver:
    loaded: intel unloaded: modesetting alternate: fbdev,vesa display-ID: :1
    screens: 1
  Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.0x11.2")
    s-diag: 582mm (22.9")
  Monitor-1: eDP1 res: 1920x1080 hz: 60 dpi: 157
    size: 310x170mm (12.2x6.7") diag: 354mm (13.9")
  Message: Unable to show advanced data. Required tool glxinfo missing.
Audio:
  Device-1: Intel vendor: Acer Incorporated ALI driver: snd_hda_intel
    v: kernel alternate: snd_sof_pci_intel_icl bus-ID: 00:1f.3
    chip-ID: 8086:4dc8 class-ID: 0401
  Sound Server-1: ALSA v: k5.15.12-zen1-1-zen running: yes
  Sound Server-2: JACK v: 1.9.19 running: no
  Sound Server-3: PulseAudio v: 15.0 running: no
  Sound Server-4: PipeWire v: 0.3.42 running: yes
Network:
  Device-1: Intel Wi-Fi 6 AX201 160MHz driver: iwlwifi v: kernel
    bus-ID: 00:14.3 chip-ID: 8086:4df0 class-ID: 0280
  IF: wlp0s20f3 state: up mac: <filter>
Bluetooth:
  Device-1: Intel AX201 Bluetooth type: USB driver: btusb v: 0.8
    bus-ID: 1-8:5 chip-ID: 8087:0026 class-ID: e001
  Report: bt-adapter ID: hci0 rfk-id: 1 state: up address: <filter>
Drives:
  Local Storage: total: 88.12 GiB used: 57.3 GiB (65.0%)
  SMART Message: Required tool smartctl not installed. Check --recommends
  ID-1: /dev/mmcblk0 maj-min: 179:0 vendor: Kingston model: TA2964
    size: 58.31 GiB block-size: physical: 512 B logical: 512 B type: SSD
    serial: <filter> rev: 0x8 scheme: GPT
  ID-2: /dev/sda maj-min: 8:0 type: USB vendor: Lexar
    model: USB Flash Drive size: 29.81 GiB block-size: physical: 512 B
    logical: 512 B type: SSD serial: <filter> rev: 1100 scheme: MBR
Partition:
  ID-1: / raw-size: 28.6 GiB size: 28.6 GiB (100.00%) used: 27.9 GiB (97.5%)
    fs: btrfs dev: /dev/mmcblk0p5 maj-min: 179:5
  ID-2: /boot/efi raw-size: 100 MiB size: 96 MiB (96.00%)
    used: 57 MiB (59.4%) fs: vfat dev: /dev/mmcblk0p1 maj-min: 179:1
  ID-3: /home raw-size: 28.6 GiB size: 28.6 GiB (100.00%)
    used: 27.9 GiB (97.5%) fs: btrfs dev: /dev/mmcblk0p5 maj-min: 179:5
  ID-4: /var/log raw-size: 28.6 GiB size: 28.6 GiB (100.00%)
    used: 27.9 GiB (97.5%) fs: btrfs dev: /dev/mmcblk0p5 maj-min: 179:5
  ID-5: /var/tmp raw-size: 28.6 GiB size: 28.6 GiB (100.00%)
    used: 27.9 GiB (97.5%) fs: btrfs dev: /dev/mmcblk0p5 maj-min: 179:5
Swap:
  Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
  ID-1: swap-1 type: zram size: 3.64 GiB used: 321.5 MiB (8.6%)
    priority: 100 dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 43.0 C mobo: N/A
  Fan Speeds (RPM): N/A
Info:
  Processes: 248 Uptime: 21m wakeups: 1 Memory: 3.64 GiB
  used: 1.89 GiB (51.9%) Init: systemd v: 250 tool: systemctl Compilers:
  gcc: 11.1.0 clang: 13.0.0 Packages: pacman: 1506 lib: 377 Shell: Bash
  v: 5.1.12 running-in: gnome-terminal inxi: 3.3.11
[[email protected] old]$ 

Without it, you will not receive any help from the Garuda team or your topic is likely to be closed without notice.

I'm hoping for some advice on how to proceed. Currently I can't update my Garuda installation because there's not enough space.

It's installed in a single 29GB btrfs partition, with most of my user data stored on an external 32GB non-btrfs USB stick. This is just on a cheap laptop I use for working on when away from home.

The problem started last week when I tried a system update (via pacman -Syu).
After an hour downloading about a GB of newer packages it started to install them and I think tried to take a system snapshot. Unfortunately it failed, with timeshift reporting there was not enough space. There was a little under 1GB of free space. So the update did not proceed.

I looked at timeshift to try to see what snapshots had been taken, and indeed it reported there was not enough space (700MB available, less than the minimum needed of 1000MB).
There were four snapshots listed, and I deleted one in the hope of freeing enough space. It had a minuscule effect on disk usage.

Right now it's saying:

2021-11-28 16:04:49, 7.3GB size, 30.7MB unshared
2021-11-28 18:30:53, 7.3GB size, 13.5MB unshared
2022-01-01, 03:01:25, 9.8GB size, 5.1GB unshared

733MB available.

I think the above means that in 7.3GB of files, there's a delta of 30.7MB of changed files, and in a 2nd snapshot 13.5MB of differences. In the 2022 snapshot though there were a lot of changes (5.1GB).

When I ran pacman -Syu today it gave up much faster, not even downloading any updates because of insufficient space:

pacman -Syu

:: Synchronizing package databases...
core 137.5 KiB 37.8 KiB/s 00:04 [------------------------------------] 100%
extra 1564.0 KiB 526 KiB/s 00:03 [------------------------------------] 100%
community 6.0 MiB 621 KiB/s 00:10 [------------------------------------] 100%
multilib 152.1 KiB 332 KiB/s 00:00 [------------------------------------] 100%
chaotic-aur 1706.1 KiB 1204 KiB/s 00:01 [------------------------------------] 100%
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...

Packages (100) alsa-card-profiles-1:0.3.43-1 android-udev-20220102-1 appstream-0.15.1-2 brltty-6.4-8
ca-certificates-mozilla-3.74-1 cht.sh-git-r892.46d1a5f-1 curl-7.81.0-1 e2fsprogs-1.46.5-1
evolution-data-server-3.42.3-1 flameshot-0.10.2-2 garuda-assistant-2.5.1-1
garuda-fish-config-1.4.4-1 garuda-hooks-2.5.4-1 garuda-update-1.6.1-1
garuda-wallpapers-r66.bc0053b-1 gjs-2:1.70.0-2 glslang-11.7.1-3 gnome-autoar-0.4.2-1
gnome-software-41.3-1 gnome-software-packagekit-plugin-41.3-1 google-chrome-97.0.4692.71-1
gst-plugin-pipewire-1:0.3.43-1 gtk-update-icon-cache-1:4.6.0-1 gtk4-1:4.6.0-1
haveged-1.9.16-1 hidapi-0.11.2-1 iso-codes-4.9.0-1 kaccounts-integration-21.12.1-1
kdenlive-21.12.1-1 lib32-curl-7.81.0-1 lib32-e2fsprogs-1.46.5-1
lib32-libva-mesa-driver-21.3.3-1 lib32-mesa-21.3.3-1 lib32-mesa-vdpau-21.3.3-1
lib32-opencl-mesa-21.3.3-1 lib32-vulkan-intel-21.3.3-1 lib32-vulkan-mesa-layers-21.3.3-1
lib32-vulkan-radeon-21.3.3-1 libgphoto2-2.5.28-1 libnumbertext-1.0.8-1 libpipeline-1.5.5-1
libreoffice-fresh-7.2.5-1 libsoup-2.74.2-2 libsoup3-3.0.4-2 libsysprof-capture-3.42.1-2
libtg_owt-0.git10.6708e0d-2 libva-mesa-driver-21.3.3-2 libxnvctrl-495.46-2
linux-lts-5.10.90-1 linux-lts-headers-5.10.90-1 linux-zen-5.15.13.zen1-1
linux-zen-headers-5.15.13.zen1-1 mesa-21.3.3-2 mesa-vdpau-21.3.3-2 mpv-1:0.34.1-1
mutter-41.2-2 nlohmann-json-3.10.5-1 nss-3.74-1 opencl-mesa-21.3.3-2 pipewire-1:0.3.43-1
pipewire-alsa-1:0.3.43-1 pipewire-jack-1:0.3.43-1 pipewire-pulse-1:0.3.43-1
pipewire-v4l2-1:0.3.43-1 pipewire-zeroconf-1:0.3.43-1 pkcs11-helper-1.28.0-1
protobuf-3.19.2-1 python-isodate-0.6.1-1 python-pillow-9.0.0-1 python-psutil-5.9.0-1
python-pygments-2.11.2-1 python-reportlab-3.6.5-1 python-setuptools-1:59.1.0-1
qt5-base-5.15.2+kde+r276-1 qt5-declarative-5.15.2+kde+r42-1
qt5-quickcontrols2-5.15.2+kde+r9-1 qt5-script-5.15.8-2 qt5-svg-5.15.2+kde+r15-1
qt5-webengine-5.15.8-1 qt6-base-6.2.2-4 signon-kwallet-extension-21.12.1-1 sqlite-3.37.1-1
systemd-250.1-1 systemd-libs-250.1-1 systemd-sysvcompat-250.1-1 tealdeer-1.5.0-1
util-linux-2.37.2-5 util-linux-libs-2.37.2-5 vulkan-intel-21.3.3-2
vulkan-mesa-layers-21.3.3-2 vulkan-radeon-21.3.3-2 vulkan-swrast-21.3.3-2 whois-5.5.11-1
wireplumber-0.4.6-1 wxgtk-common-3.0.5.1-3 wxgtk3-3.0.5.1-3 xorg-server-21.1.3-1
xorg-server-common-21.1.3-1 xorg-server-xephyr-21.1.3-1 zita-alsa-pcmi-0.4.0-1

Total Download Size: 593.62 MiB
Total Installed Size: 2378.52 MiB
Net Upgrade Size: -15.60 MiB

:: Proceed with installation? [Y/n] y
error: Partition /var/cache too full: 157113 blocks needed, 156459 blocks free
error: failed to commit transaction (not enough free disk space)
Errors occurred, no packages were upgraded.

What would you advise?

My guess is that I should unmount my external 32GB user files and format a fresh 32GB USB drive as btrfs and change over to using that for timeshift's snapshots via btrfs.

I worry that otherwise, if I deleted the 5.1GB snapshot of 2022/1/1, after the fresh update from the really old snapshot, there wouldn't be space.

It also felt bad to me that the update didn't offer me the chance to proceed without taking a snapshot, on the understanding I'd be taking a risk in that if there was a problem, the system wouldn't be able to roll back to a known good state. (Maybe that's a reasonable safety precaution.)

Because the snapshots vary so much in actual size (from 13MB to 5GB), I lso wonder whether the "Not enough disk space" warning in timeshift is reporting the apparent size needed or the actual size the snapshot would need on a btrfs file system.

Anyway, those are just background thoughts. My main hope is to get some advice at what I can do to update my system.

Thanks in advance.

Report everything you have already attempted to solve your problem.

Delete pacman's package cache.

Check how much room your logs and crash dumps are using.

Ya, I don't think that's feasible.

3 Likes

I had this error too once. Fixed it by limiting the timeshift snapshots to one or two. There should also be an option to limit the size of the pacman cache in Pamac.

You're lucky you didn't completely run out of disk pace and crash the system. In that case there is no way to recover unless you can chroot and delete some files.

Wow, that's pretty tight on space.

One option I would consider, depending on how deep your configuration is at this point, would be to do a fresh install. That way everything gets as up-to-date as possible, and you are starting off with the smallest image on the disk possible. Since you already are keeping your files on external storage, your sacrifice would be whatever configuration you have set up and whatever packages you have installed.

Honestly i would just completely disable btrfs snapshots and play the storage as close to the chest as possible, that way you can make sure you have space for the packages you need and updates and such. Again, since your files are not on the drive that's all the less at risk. Plus, as you mentioned it is not your primary machine.

I agree, that isn't going to work. Btrfs snapshots have to do with the btrfs subvolumes, so the only way it can work is with the snapshots going to the same drive as the data.

If you want to keep a backup handy and have a spare flash drive, I would set up a regular old full system back up with rsync and just run an update to it every once in a while.

I don't know whether crash dumps refers to core dumps from crashed programs or kernel crash dumps, and I couldn't find out where they might be stored, so I can't tell you how much space they might be using, sorry.

Assuming for the log files space that this is enough to report:

# du -sh /var/log/ /var/cache
390M	/var/log/
7.9G	/var/cache

Thanks for stopping me from trying to setup timeshift to use an alternate drive. (I considered that because timeshift suggests choosing an alternate location for storing the snapshots when the filesystem is low on space.)

After a pacman -S -c:

# pacman -S -c
Packages to keep:
  All locally installed packages

Cache directory: /var/cache/pacman/pkg/
:: Do you want to remove all other packages from cache? [Y/n] y
removing old packages from cache...

Database directory: /var/lib/pacman/
:: Do you want to remove unused repositories? [Y/n] y
removing unused sync repositories...
[[email protected] luke]# du -sh  /var/cache
4.7G	/var/cache
[[email protected] luke]# df -h
Filesystem      Size  Used Avail Use% Mounted on
dev             1.8G     0  1.8G   0% /dev
run             1.9G  1.9M  1.9G   1% /run
/dev/mmcblk0p5   29G   25G  3.8G  87% /

I'm trying the update again now that I have some more space...

Total Download Size:    786.55 MiB
Total Installed Size:  2378.52 MiB
Net Upgrade Size:       -15.60 MiB

:: Proceed with installation? [Y/n] y

I'll report back shortly...

Sorry for mu ignorance, I'm too new to archlinux and garuda.

I couldn't find way to limit timeshift snapshots: when I run the GUI it shows that scheduled snapshots are disabled, even though there were four snapshots (three now after I deleted one).

I also couldn't work out how to use pamac to limit the size of the pacman cache. :frowning:

Unless... man 5 pacman.conf mentions a KeepNumPackages, so I guess I could reduce that from 3 to 1, is that what you meant?

The idea of disabling btrfs snapshots sounds okay to me, for this laptop and usage.

But I didn't see how to do that just by reading the man pages for btrfs and timeshift, and reading How do I turn off automatic backup in Garuda Linux? - #2 by SGS didn't say where the timeshift documentation is, to read, to learn how to do it.

Sorry for being such a garuda noob.

The idea of a complete reinstall might be okay. Though I think it makes garuda less appealing than other linux distros that don't default to automated snapshots.

If I can learn how to turn them off, that may be okay though.

Thanks for your patience.

I had timeshift running in the background as I re-ran pacman -Syu, so it failed to take the snapshot at the end and told me to exit from it and try again.

It looked good, until:

( 71/100) upgrading linux-lts-headers                              [------------------------------------] 100%
error: could not extract /usr/lib/modules/5.10.90-1-lts/build/include/vdso/clocksource.h (Can't create '/usr/lib/modules/5.10.90-1-lts/build/include/vdso/clocksource.h')
error: could not extract /usr/lib/modules/5.10.90-1-lts/build/include/video/cirrus.h (Can't create '/usr/lib/modules/5.10.90-1-lts/build/include/video/cirrus.h')

...

error: could not extract /usr/lib/modules/5.10.90-1-lts/build/virt/lib/Kconfig (Can't create '/usr/lib/modules/5.10.90-1-lts/build/virt/lib/Kconfig')
error: could not extract /usr/lib/modules/5.10.90-1-lts/build/vmlinux (Write failed)
error: problem occurred while upgrading linux-lts-headers
error: could not open file /var/lib/pacman/local/linux-lts-headers-5.10.90-1/files: No space left on device
error: could not update database entry linux-lts-headers-5.10.90-1
error: could not commit transaction
error: failed to commit transaction (transaction aborted)
Errors occurred, no packages were upgraded.
# df -h
Filesystem      Size  Used Avail Use% Mounted on
dev             1.8G     0  1.8G   0% /dev
run             1.9G  1.9M  1.9G   1% /run
/dev/mmcblk0p5   29G   27G     0 100% /

and

du -sh  /var/cache
5.4G	/var/cache

Looks like it almost succeeded, but did not have the space it needed.

Oh, and running timeshift again now shows I have no snapshots any more, even though I had not deleted them. (I did change the schedule to only have 1 snapshot for the monthly and weekly though, even though scheduling is turned off it said.)

Running pacman -S -c again hasn't recovered any space, unsurprisingly.

I'll see what I can uninstall so the system has a smidgin of space...

Just try running the update again.

It is possible to relocate your pacman cache to another drive (unlike snapshots). See the pacman documentation on the Arch Wiki if you're interested in doing this.

I tried uninstalling wps-office to recover 1.1GB of space. I tried via the add/remove software GUI but it failed.
I removed it via pacman -R wps-office which seemed to work, but didn't recover any space. Filesystem remained 100% used. Running add/remove software then couldn't remove anything as it complained wps-office was missing.
Then chrome browser crashed.

I think I tried pacman -Syu again but it didn't work.

Tried rebooting and it failed, saying the kernel was missing.

So I think I'll give up on Garuda. Too many things went wrong.

Thanks for your help. When I return home I'll see if I can install some other Linux distro to revive the laptop.

I'm very disappointed that just updating the system through the recommended means can lead to an unbootable machine. That seems the exact opposite of Garuda's supposed key benefit.

Anyway, good luck for your future development.

The issue was not that Garuda is unreliable, the problem was that your drive space was too limited. By removing your snapshots you took away your roll back capabilities, so you couldn't make use of Garuda's prime asset. Perhaps another distro designed for more modest hardware would be a good move for you.

BTRFS needs more space than a comparable ext4 based install. That's just the nature of the beast. Garuda is really designed for higher spec hardware with ample storage space and ram. Sadly, if you have lower end hardware Garuda isn't really going to shine on your machine.

Better luck with your next distro.

4 Likes

I only removed one intermediate small snapshot, and I did it through the UI provided by timeshift.

Garuda itself decided to remove the other three snapshots.

Garuda installed a partial system that wouldn't boot, despite its checks that it had enough space. Clearly it didn't.

Garuda gave no indication that it wouldn't work in limited space, and indeed failed when it tried to, after a few months of use.

Timeshift gave conflicting information about its snapshots.

In my view those are all problems in the Garuda distribution. All seem fixable and preventable if taken into account.

That's my assessment. I've been using various Linux distros since 1993 Yggdrasil, and working in IT R&D for longer than that, but feel free to ignore my feedback.

Best wishes!

1 Like

Feedback is fine, and it is definitely not ignored. However, what you are reporting, is far from common. I would go so far as to say this is very clearly an edge case.

Which timeshift snapshot did you remove? because they are all sequential and dependent on another. Generally when I want to clean out snapshots I wipe all of them and then perform a btrfs balance. After the balancing is complete, I then create a new snapshot.

I appreciate you are an experienced Linux user, but both Arch and Garuda are birds of a different feather and learning to master them both takes a fair bit of time.

3 Likes

Not for nothing, but you didn't exactly give Garuda a fair shake setting it up on a system that doesn't have the proper resources to run it. That's like taking a Ferrari body and dropping in an engine from a Ford Pinto, then saying "Turns out Ferrari isn't that great, I had problems with it."

If you are not specifically interested in running Garuda on that small partition, I would maybe pick a more basic distro and run a nice small DE on it with not too many extra features. Maybe Manjaro/XFCE, Fedora/Mate, or Linux Mint is nice.

5 Likes

I think @lukejkendall it is quiet useful with his knowledge that he has tested how little you can run garuda on?
I am glad he has worked out that with the warning on the website the minimum requirements have be tested ?
But the question i think i am more worried about is?
WHY?
I have a laptop that run linux mint well!! why would i put garuda on it? It would run like a bag of cr#p!
So the point i am making is?
I fit the distro to the hardware :smiley:

3 Likes

It's just that ol' fallacy that's been running 'round the 'net forever, "Linux FLIES on old machines."
Another "they say" that has no patient-zero. Somebody suggests they can resurrect that machine that barely met system specs. when it ran Windows by installing Linux, so beginners pick the flashiest distribution they can find. And, oh boy, is Garuda a flashy Ferrari! They don't suspect that power and flash comes at cost. :wink:

So they do as @tbg suggests and when they can't run it on that old Crapmobile, Linux gets another bad mark. Personally, I am not opposed to that, since we (Linux lovers) shouldn't have to shovel them dogfood their entire lives.
:rofl:

3 Likes

I chose it because I didn't notice any warning about running it on a small machine, but the main reason was that I was interested in trying it and with Garuda the wifi worked out of the box. Wifi didn't work in the laptop with a couple of other distros I tried.
Though this week I discovered Garuda didn't allow the mic to work.

I don't think you need to get upset or defensive that I didn't give it a fair try: personally I'd use my feedback to improve Garuda, to work around or warn of those problems.

Minimum requirements

  • 30 GB storage space
  • 4 GB RAM
  • Video card with OpenGL 3.3 or better
  • 64-bit system

I find this more than unfair. You are the admin.
If you bring your hard drive, no matter how big, to its limit, should you be told about it?
Apart from that, we experience it all the time, no matter where and how often we communicate something, it is hardly read.

4 Likes

I don't consider asking a question being upset or defensive. You were the one who ignored what I was asking when I was merely trying to ascertain why this may have happened.

As you're leaving Garuda anyways, and you really don't seem interested in finding out what happened to cause your issue, I guess we're about done here. There's not much point in continuing a purposeless discussion, so I'll close this out now.

Again, good luck with your next distro.

4 Likes