These last weeks, I have been busy understanding how our boot process work and mainly how it could be repaired, hence the following question: How could we monitor the directory of /boot so as to be advised of any change?
On other systems, I heard about Inotifywait.
On Arch based systems, I know there are monit and monitorix. I had a look at them but I am not competent enough to set them up so that one of them could inform me of any change involving this sensitive directory. Maybe there are other programs which would be better for this purpose.
Except kernel images and initramfs, if you use Grub for examples bootloader, it keeps its file under /boot and /boot/efi if EFI partition is mounted at that location.
Yes I use grub with UEFI and does not plan to change. I wish to know about every change that happens in the /boot directory, if only the name of the file(s).
Only in grub directory under home, I have around 370 files. Using inotifywait to monitor that directory recursively and notify about every single change to every single file will practically spam-jam my desktop with notification.
To be honest, I don’t see any practical usefulness of such an objective.
The only processes I know of to make changes to that directory are:
install/update of the package grub
grub-install for installing the bootloader into the boot path
grub-mkconfig for updating grub.cfg
install/update/removal of kernels and generation of initramfs (mkinitcpio or dracut)
All these can be “monitored” when you perform your updates, install or remove kernels and when there is a need for reinstalling the bootloader and updating grub.conf. If something goes wrong, you would know when and how.
But everyone has different requirements for their use case so I won’t be arguing against that.
To monitor changes in the /boot directory on Arch Linux (which is important for GRUB2-related updates), you can use one of the following methods:
1. Using inotifywait (from inotify-tools)
Install inotify-tools:
bash
Copy
sudo pacman -S inotify-tools
Run a script to monitor /boot:
bash
Copy
inotifywait -m -r /boot --format '%w%f %e' -e create,delete,modify,move
This will show real-time changes (new files, deletions, modifications, moves).
Press Ctrl+C to stop.
Persistent Monitoring (via Systemd Service)
If you want this to run in the background and log changes:
Create a script (/usr/local/bin/monitor_boot.sh):
bash
Copy
#!/bin/bash
inotifywait -m -r /boot --format '%w%f %e %T' --timefmt '%F %T' -e create,delete,modify,move >> /var/log/boot_changes.log
Make it executable:
bash
Copy
sudo chmod +x /usr/local/bin/monitor_boot.sh
Create a systemd service (/etc/systemd/system/monitor_boot.service):
ini
Copy
[Unit]
Description=Monitor /boot directory for changes
[Service]
ExecStart=/usr/local/bin/monitor_boot.sh
Restart=always
[Install]
WantedBy=multi-user.target
Enable and start it:
bash
Copy
sudo systemctl enable --now monitor_boot.service
Check logs:
bash
Copy
tail -f /var/log/boot_changes.log
2. Using auditd (Advanced)
Install audit:
bash
Copy
sudo pacman -S audit
Add a rule to monitor /boot:
bash
Copy
sudo auditctl -w /boot -p wa -k boot_monitor
Check logs:
bash
Copy
sudo ausearch -k boot_monitor | less
To make it persistent, add the rule to /etc/audit/rules.d/audit.rules.
3. Manual Checks (Cron Job)
Create a script (/usr/local/bin/check_boot.sh):
bash
Copy
#!/bin/bash
find /boot -type f -exec ls -la {} \; > /tmp/boot_snapshot.new
if ! cmp -s /tmp/boot_snapshot.old /tmp/boot_snapshot.new; then
echo "Changes detected in /boot on $(date)" >> /var/log/boot_changes.log
diff -u /tmp/boot_snapshot.old /tmp/boot_snapshot.new >> /var/log/boot_changes.log
fi
mv /tmp/boot_snapshot.new /tmp/boot_snapshot.old
Make it executable:
bash
Copy
sudo chmod +x /usr/local/bin/check_boot.sh
Add to cron (run every hour):
bash
Copy
(crontab -l ; echo "0 * * * * /usr/local/bin/check_boot.sh") | crontab -
Which One to Choose?
For real-time monitoring: inotifywait (easiest) or auditd (more detailed).
For periodic checks: Cron job.
Since you're using GRUB, monitoring /boot helps detect kernel updates (vmlinuz-*, initramfs-*) and GRUB config changes (grub.cfg).
Would you like help setting up automatic GRUB updates when /boot changes? (e.g., via a hook or systemd path unit).
I know which “regular” commands provoke a change in some /boot files.
However, at the end of February, after a Windows update, I was suddenly left only with a Windows boot and grub entries had all disappeared. This explains why I am currently a little paranoid…
If you want, you could create a new ESP only for your Linux.
It is easily done and since you are using Grub, it doesn’t have to be very big. You can add the UUID for this new ESP to your /etc/fstab. Unmount the current one, mount the new one to the right location, I guess /boo/efi and reinstall the bootloader using grub-install with appropriate parameters and update grub.cfg.
You don’t need to set any boot or esp flag on this one. Windows will Ignore it and will do whatever it wants to its own ESP.
Thanks but I have two linux on this windows disk and it would make things more complicated for me. I shall follow on sharing the ESP with W10 but, trust me, I am fully prepared (and trained, really) to arch-chroot my way back in case of another W10 misbehavior.
I had thought that monitoring /boot could provide a supplementary help, but you are right it’s probably not a good idea for the reasons you gave me.
When sharing ESP with Windows, and when mounting it on /boot/efi, the only directory from your Linux installation on that shared partition will be EFI/Arch (Arch as an example) containing grub’s efi bootlader binary grubx86.efi
What gets overwritten in some unfortunate cases, is this directory and probably also the boot entry in the BIOS. Something you can easily fix as you mentioned.
Anything else under /boot is not on that shared partition.
So monitoring the entire /boot directory is a bit of overkill.
May be I’m missing something here but a monitoring tool that reports changes to you will be just that and nothing more it is not like a watchdog is it ? And a monitoring tool installed on a EOS system will only work on EOS. If windows will change something the monitoring tool will do nothing in Windows to report that change , only back in EOS the change will be reported, and in the case of overwriting GRUB it will be to late already. Again but I maybe missing something.
This was a bit of XY problem. The reason why they wanted to monitor /boot was not given at the outset. So the objective was not clear before further down the thread and therefore unclear what is the problem that a solution is sought for.
Well I know that is true but I was more refering to the fact what the expectations of the OP where concerning that monitoring tool was not very clear to me.
Sometimes Windows will do this for what ever reason. It’s an easy fix to just arch-chroot and reinstall grub and run the grub update command. Not even sure it’s necessary to re-install grub as you may only need to run the grub update command. Having something monitor for changes isn’t going to change the fact that you’ll have to do this to fix it anyway.
It’s an easy fix to just arch-chroot and reinstall grub and run the grub update command. Not even sure it’s necessary to re-install grub as you may only need to run the grub update command. 
Having something monitor for changes isn’t going to change the fact that you’ll have to do this to fix it anyway.