Uninstall grub, is it possible?

Hi,

I use systemd-boot and it's lightning fast. But grub is still there. Can I uninstall Grub ??? Since it's integrated with snapper / btrfs I'm not sure if I should. I want to keep the possibility to boot from a previous snapshot also ...

Any idea ?

Regards,
Bernard

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

inxi -Faz

System:
Kernel: 5.16.2-zen1-1-zen x86_64 bits: 64 compiler: gcc v: 11.1.0
parameters: initrd=\amd-ucode.img initrd=\initramfs-linux-zen.img
rd.luks.name=86691f1a-15a7-4cc6-823e-08eab8fb14b4=luks-86691f1a-15a7-4cc6-823e-08eab8fb14b4
root=/dev/mapper/luks-86691f1a-15a7-4cc6-823e-08eab8fb14b4
[email protected] rd.luks.options=discard rw
rd.luks.name=1436414a-f251-47a7-bf5f-6ba83c40e119=luks-1436414a-f251-47a7-bf5f-6ba83c40e119
resume=/dev/disk/by-label/swap systemd.unified_cgroup_hierarchy=0
radeon.dpm=1
Console: pty pts/2 wm: kwin_x11 DM: SDDM Distro: Garuda Linux
base: Arch Linux
Machine:
Type: Laptop System: ASUSTeK product: VivoBook_ASUSLaptop X513UA_M513UA
v: 1.0 serial: <filter>
Mobo: ASUSTeK model: X513UA v: 1.0 serial: <filter>
UEFI: American Megatrends LLC. v: X513UA.305 date: 03/12/2021
Battery:
ID-1: BAT0 charge: 39.6 Wh (100.0%) condition: 39.6/42.1 Wh (94.2%)
volts: 11.8 min: 11.8 model: ASUSTeK ASUS Battery type: Li-ion serial: N/A
status: Not charging cycles: 8
Device-1: hidpp_battery_0 model: Logitech Wireless Mouse M325
serial: <filter> charge: 100% (should be ignored) rechargeable: yes
status: Discharging
CPU:
Info: model: AMD Ryzen 7 5700U with Radeon Graphics socket: FP6 bits: 64
type: MT MCP arch: Zen 2 family: 0x17 (23) model-id: 0x68 (104) stepping: 1
microcode: 0x8608103
Topology: cpus: 1x cores: 8 tpc: 2 threads: 16 smt: enabled cache:
L1: 512 KiB desc: d-8x32 KiB; i-8x32 KiB L2: 4 MiB desc: 8x512 KiB
L3: 8 MiB desc: 2x4 MiB
Speed (MHz): avg: 1400 min/max: 1400/4370 boost: enabled
base/boost: 1800/4350 scaling: driver: acpi-cpufreq governor: powersave
volts: 1.2 V ext-clock: 100 MHz cores: 1: 1400 2: 1400 3: 1400 4: 1400
5: 1400 6: 1400 7: 1400 8: 1400 9: 1400 10: 1400 11: 1400 12: 1400
13: 1400 14: 1400 15: 1400 16: 1400 bogomips: 57487
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
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: Full AMD retpoline, IBPB: conditional,
IBRS_FW, STIBP: conditional, RSB filling
Type: srbds status: Not affected
Type: tsx_async_abort status: Not affected
Graphics:
Device-1: AMD Lucienne vendor: ASUSTeK driver: amdgpu v: kernel
bus-ID: 03:00.0 chip-ID: 1002:164c class-ID: 0300
Device-2: Quanta USB2.0 HD UVC WebCam type: USB driver: uvcvideo
bus-ID: 3-3:3 chip-ID: 0408:30d4 class-ID: 0e02 serial: <filter>
Display: server: X.Org 1.21.1.3 compositor: kwin_x11 driver:
loaded: amdgpu,ati unloaded: modesetting alternate: fbdev,vesa
display-ID: :0 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.0x11.2")
s-diag: 582mm (22.9")
Monitor-1: eDP res: 1920x1080 hz: 60 dpi: 142 size: 344x194mm (13.5x7.6")
diag: 395mm (15.5")
OpenGL: renderer: AMD RENOIR (DRM 3.44.0 5.16.2-zen1-1-zen LLVM 13.0.0)
v: 4.6 Mesa 21.3.4 direct render: Yes
Audio:
Device-1: AMD Renoir Radeon High Definition Audio driver: snd_hda_intel
v: kernel bus-ID: 03:00.1 chip-ID: 1002:1637 class-ID: 0403
Device-2: AMD Raven/Raven2/FireFlight/Renoir Audio Processor
vendor: ASUSTeK driver: N/A
alternate: snd_pci_acp3x, snd_rn_pci_acp3x, snd_pci_acp5x, snd_pci_acp6x
bus-ID: 03:00.5 chip-ID: 1022:15e2 class-ID: 0480
Device-3: AMD Family 17h HD Audio vendor: ASUSTeK driver: snd_hda_intel
v: kernel bus-ID: 03:00.6 chip-ID: 1022:15e3 class-ID: 0403
Sound Server-1: ALSA v: k5.16.2-zen1-1-zen running: yes
Sound Server-2: sndio v: N/A running: no
Sound Server-3: PulseAudio v: 15.0 running: no
Sound Server-4: PipeWire v: 0.3.43 running: yes
Network:
Device-1: Intel Wi-Fi 6 AX200 driver: iwlwifi v: kernel bus-ID: 01:00.0
chip-ID: 8086:2723 class-ID: 0280
IF: wlp1s0 state: up mac: <filter>
IF-ID-1: docker0 state: down mac: <filter>
IF-ID-2: virbr0 state: down mac: <filter>
Bluetooth:
Device-1: Intel AX200 Bluetooth type: USB driver: btusb v: 0.8
bus-ID: 3-2:2 chip-ID: 8087:0029 class-ID: e001
Report: bt-adapter ID: hci0 rfk-id: 2 state: up address: <filter>
Drives:
Local Storage: total: 953.87 GiB used: 373.78 GiB (39.2%)
ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Western Digital
model: PC SN530 SDBPNPZ-1T00-1002 size: 953.87 GiB block-size:
physical: 512 B logical: 512 B speed: 31.6 Gb/s lanes: 4 type: SSD
serial: <filter> rev: 21106000 temp: 32.9 C scheme: GPT
SMART: yes health: PASSED on: 41d 6h cycles: 554
read-units: 63,434,896 [32.4 TB] written-units: 14,111,524 [7.22 TB]
Partition:
ID-1: / raw-size: 937.07 GiB size: 937.07 GiB (100.00%)
used: 373.66 GiB (39.9%) fs: btrfs block-size: 4096 B dev: /dev/dm-0
maj-min: 254:0 mapped: luks-86691f1a-15a7-4cc6-823e-08eab8fb14b4
ID-2: /boot raw-size: 260 MiB size: 256 MiB (98.46%)
used: 122.7 MiB (47.9%) fs: vfat block-size: 512 B dev: /dev/nvme0n1p1
maj-min: 259:1
ID-3: /home raw-size: 937.07 GiB size: 937.07 GiB (100.00%)
used: 373.66 GiB (39.9%) fs: btrfs block-size: 4096 B dev: /dev/dm-0
maj-min: 254:0 mapped: luks-86691f1a-15a7-4cc6-823e-08eab8fb14b4
ID-4: /var/log raw-size: 937.07 GiB size: 937.07 GiB (100.00%)
used: 373.66 GiB (39.9%) fs: btrfs block-size: 4096 B dev: /dev/dm-0
maj-min: 254:0 mapped: luks-86691f1a-15a7-4cc6-823e-08eab8fb14b4
ID-5: /var/tmp raw-size: 937.07 GiB size: 937.07 GiB (100.00%)
used: 373.66 GiB (39.9%) fs: btrfs block-size: 4096 B dev: /dev/dm-0
maj-min: 254:0 mapped: luks-86691f1a-15a7-4cc6-823e-08eab8fb14b4
Swap:
Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
ID-1: swap-1 type: partition size: 16.54 GiB used: 0 KiB (0.0%)
priority: -2 dev: /dev/dm-1 maj-min: 254:1
mapped: luks-1436414a-f251-47a7-bf5f-6ba83c40e119
ID-2: swap-2 type: zram size: 15.1 GiB used: 0 KiB (0.0%) priority: 100
dev: /dev/zram0
Sensors:
System Temperatures: cpu: 37.0 C mobo: N/A gpu: amdgpu temp: 37.0 C
Fan Speeds (RPM): cpu: 0
Info:
Processes: 390 Uptime: 25m wakeups: 3 Memory: 15.1 GiB
used: 2.8 GiB (18.6%) Init: systemd v: 250 tool: systemctl Compilers:
gcc: 11.1.0 clang: 13.0.0 Packages: pacman: 1805 lib: 392
Shell: Bash (sudo) v: 5.1.16 running-in: konsole inxi: 3.3.12

In which case, don't remove GRUB. :wink:

5 Likes

It appears to be possible according to this discussion, although I have to admit reading through that made my head spin a bit.

1 Like

I must admit that my initial reaction to reading questions like this (whether it's possible, or not) is:

If you need to ask, should you really be messing with things that could do irreparable damage to your system.

3 Likes

Probably not, if it is a mission-critical machine. But a lot of the fun comes from tinkering (whether wise or foolish).

Every time I break my computer, I tend to learn a lot! :joy:

4 Likes

I agree with you, however most of our users "tinkerings" end up being dumped on our forum support volunteers to fix their mistakes.

Anyone that wants to alter their system should use it as a learning experience and enjoy themselves playing around. Having said that, if you break it you bought it. If you deliberately do something you know is risky and melt down your system, is it really Garuda's responsibility to deal with a disaster of your own making.

We deal with enough support issues on our forum without having to deal with daredevils who've broken everything by their own recklessness. Feel free to change whatever you want on your own system, just don't come crying to the forum to fix everything for you when you inevitably break a perfectly good Garuda install.

Have fun tinkering with your own system, just don't dump your mistakes on others to correct.

4 Likes

Yes: take a 2nd physical HD, install Garuda on it with GRUB and then you can have all the fun trying to remove it and replace it by systemd-boot. :slight_smile: That way you have no chance to affect your primary disk and you will learn a lot more by trying it out yourself. Win-win. :slight_smile:

1 Like

Fair enough! I definitely see where you are coming from and that is a perfectly reasonable stance. I spend enough time in the forum to have seen the online equivalent of people slamming their laptop on the counter shouting"fix it!" like you guys personally messed up their setup. Anyone can see how that would be frustrating.

Hear that @PerfMonk? Don't forget to make a snapper backup before you delete grub. Oh wait... :stuck_out_tongue_winking_eye:

4 Likes

Make a full backup and play all you want.
By the way, I love systemd-boot.

1 Like

Hi,

I not a new to linux and I have tried a lot of things. Sometime it turns bad but anyway It's a great way to learn. The attitude of "not doing anything by fear to mess the machine" is not my cup of tea. But I read and I ask other if they have tried the stuff I want to experiment. I have not seen much on how to correctly use systemd-boot and get rid of grub on Garuda. I'm doing this on my personal laptop, my data is backed up and I can reinstall everything if I do a real big mistake.

Getting rid of grub is a delicate operation, I agree. My laptop is using EFI, btrfs and is LUKS encrypted. Reinstall Garuda is not a big deal even If I'd have redo some customization after.

I get the point that you may have to help people that do bad experiments you would tell them not to try. Believe me I won't be back whining that my laptop is broken and ask for help to reinstall...

Regards,
BT

I already have systemd-boot working OK.

I just don't see the point of keeping grub if I don't use it.

Regards,
BT

1 Like

I will manually take a snapshot. But I'm afraid I have to uninstall snapper since it does not work well with systemd-boot .

Haha, yeah that part was supposed to be a funny joke! :upside_down_face:

2 Likes

I know you are an experienced user, and I believe you personally accept responsibility for the changes you make. However, that does not seem to be the norm these days. Quite to the contrary, many new Linux users seem to have an attitude of entitlement to support no matter what manner of self destruction they've perpetrated on their machine.

Imagine what your car dealership would say if you expected your vehicle to be repaired under warranty when you'd foolishly dissembled your engine and couldn't put it back together properly!!!

1 Like

Well, I'm afraid I don't like to keep stuff I don't use. I shall work with snapshots manually or with a few homemade scripts or goback to timeshift. snapper should have a solution for systemd-boot.
There is someone on github that is working on this snapper_systemd_boot.

Regards,
BT

1 Like

Here is a worksheet of what I would do to remove grub :

Stuff previously done:

install systemd-boot
since EFI /boot is not on btrfs : install AUR (en) - pacman-boot-backup-hook

Stuff to remove :

grub
efibootmgr
garuda-boot-options garuda-hooks grub-btrfs grub-garuda grub-theme-garuda-dr460nized update-grub

snap-pac snapper-support

Need to keep : snapper

Experimental Stuff to evaluate before adding :

integrate snapper with systemd-boot : GitHub - cscutcher/snapper_systemd_boot: The aim of this tool is to automatically create boot entries for systemd-boot from snapshots created by snapper. While I've tried to make this generic enough to be useful for others there are probably places where it's currently specific to my particular environment. If there's anything I can do to help it work for you feel free raise an issue or submit a PR.

we need a way to boot from snashots that would work with snapper
Complication arise from the fact that /boot (efi) is not on btrfs and not snapshotted.

1 Like

I need to read more on systemd-boot to understand better the efi/loader/entries menu.

Why is Snapper a blocker? There exist other solutions for snapshoting, including using your own scripts, maybe one of those solution could replace Snapper and put a check mark besides that to-do on your list?

1 Like

Grub really is infiltrated all over garuda.

There is a depency of garuda-common-settings with garuda-hooks and garuda-hooks needs grub.

I'm afraid grub is soldered on the garuda board ! :dizzy_face:

I need to keep garuda-common-settings for all the other stuff.

It starting to look like an "impossible mission" :skull_and_crossbones:

I'll keep reading on systemd-boot but my chances to be able to get rid of grub are tiny.

Thanks everybody for your suggestions.

        Bernard

Sadly as per my comment above the devs had to "hard wire" (so to speak) many facets of Garuda to prevent all the help requests from inexperienced newbs breaking their systems by trying to change all the defaults of Garuda. It got to the point we even had to put a hard minimum ram requirement in the Garuda installer. We just got sick and tired of all the people with a couple of GB's of ram ignoring our 4 GB minimum ram recommendation. They would come on the forum and demand help to get there dinosaur system working with Garuda, then go off on a complete rant when told their system was inadequate. Then they would leave hateful reviews about Garuda online and spout off about how unhelpful our forum was on every place they could.

So in reality, you have the clueless newbs to thank for preventing the experienced Garuda users from being able to fully customize their system.

2 Likes