noauto option ignored in /etc/fstab?
list at xenhideout.nl
Fri Dec 8 21:47:46 UTC 2017
Josef Wolf schreef op 08-12-2017 11:07:
> Ah! Now THAT'S a really useful information:
> "local-fs.target"->"boot.mount" [color="green"];
> "unattended-upgrades.service"->"boot.mount" [color="black"];
> Color legend: black = Requires
> dark blue = Requisite
> dark grey = Wants
> red = Conflicts
> green = After
> root at bu201:/#
> Looks like unattended-upgrades.service and local-fs.target are pulling
"After" does not pull it in. Only the "black" lines pulls it it.
(I could say unattended-upgrades again ;-)).
> So I've executed "systemctl disable unattended-upgrades.service" and
> now /boot
> is no longer mounted after reboot.
> So you were right all the time.
Well that's why I was slightly annoyed ;-).
> Guess, I should file a bug against unattended-upgrades package, since
> /lib/systemd/system/unattended-upgrades.service is part of this
Well the oddest part about it is that this feature is by default turned
By default it is false.
So it doesn't even *do* anything on a default install, it just sits
there being loaded and running and not activating anything in actuality.
So this service has no impact on unattended-upgrades being installed on
a default system.
It purely exists for when you toggle that flag.
In fact the actual normal updates and upgrades get done though the
"apt-daily" service and the apt-daily-upgrade service and their
The "update" service runs at a random time twice a day, and the upgrade
service appears to run within one hour after the update service,
possibly also twice a day.
Therefore you probably don't need unattended-upgrades.service and it
only exists in case you enable that option.
"Just in case".
Is it a bug? It's more systemd's fault for having a crappy design,
You cannot specify that /boot needs to get mounted for ExecStop.
I have no clue how to start a service at shutdown, I'm not even sure it
is "theoretically" possible.
*Maybe* you could create an interim service that runs all the time but
does not pull in /boot, that then executes unattended-upgrades when *it*
gets shut down ;-).
But that's more of a hack than anything supported.
You cannot specify in systemd what you want.
Except by manually mounting /boot.
So you have to remove /boot from the service definition like I said.
And then execute the mount as part of ExecStop, but nobody practically
uses this like I said, it is just a feature that exists.
On the other hand your grub feature might also stop working, it
basically assumes /boot is mounted.
> Now, how would I run unattended-upgrades manually?
You don't need it like I said, if you don't have the shutdown thing
> /lib/systemd/system/unattended-upgrades.service only has an ExecStop
> but no Exec entry.
> Is it OK to run /usr/bin/unattended-upgrade directly from cron?
It probably doesn't do anything on your system. "apt-daily-upgrade" does
> No. It resolves the possibility that someone would mess with your
> laptop when
> it is powered off at home while you're at work.
> Depends how often you boot. Myself usually boots only when some upgrade
> me that a reboot is required.
> Good to know! I always hated those camel-case keywords. How on earth
> someone come up with such braindead camel-case keywords for the command
>> I understand it just seems undoable this way.
For me having to type those commands at every boot would be undoable.
>> Do you realize you could probably burn Grub to a CD and then boot from
> I know.
> But this has two disadvantages:
> 1. I would have to maintain my own boot-cd instead of just using one of
> billions of already existing live-cd.
> 2. I would need the cd on every boot. With the current setup, I can
> skip the verification step when I know for sure that nobody had
> access to the laptop during the power-off. For example for a quick
> or something.
You can still do that because you can install Grub in as many places as
Update-grub does not actually impact the grub bootsector/core image.
> No. I just don't boot that often. Granted, the days when uptimes were
> in years are long gone. But we still don't need to boot on a daily
I shutdown my system because all of my recent motherboards have had
failing standby/hibernate (also in Windows btw) and I do require
standby. So barring that, it goes off more often.
> BIOS protection won't prevent an attacker to take out the disk for a
Yes I know, it just determines the amount of risk you are exposed to.
>> No I meant that I was not considering a high-risk situation in which
>> directly after booting you could get compromised.
> The compromise needs not to take place directly after the boot. The
> can wait until you're at work again.
In that case you would already know your machine had been compromised.
Why would you leave the laptop in an unattended state at that point?
It also means your scripts have plenty of time to undo the damage.
>> Of course it would be extremely hard to immediately trace the location
>> the modified grub would have written its data,
> It could even have been sent over the net.
That's true. At that point you can change your password and the attacker
is void again.
>> You could immediately verify grub while in the initrd and take
>> measures, but
>> it would have to be automated.
> Malicious grub can restore original grub once it has harvested your
I... didn't consider that ;-).
I guess you've beaten me there ;-).
> I don't see how you would get a reliable solution without verifying
> Malicious grub could send your PW over the net and restore the original
> contents that the attacker stored somewhere on the net. Then it
> continues the
> boot as usual. Your verification would not notice any changes.
I guess it is not theoretically possible to defeat that.
Well I can think of a dozen measures but it remains a cat and mouse game
More information about the ubuntu-users