noauto option ignored in /etc/fstab?
list at xenhideout.nl
Sat Dec 9 14:20:32 UTC 2017
Josef Wolf schreef op 09-12-2017 13:23:
>> Therefore you probably don't need unattended-upgrades.service and it
>> exists in case you enable that option.
> So this unattended-upgrades package is of no use at all? Why does it
I was only talking about the service. I don't know the exact relation at
this point with the other (packages).
Traditionally unattended-upgrade was run by /etc/cron.daily/apt
So you mustn't assume that the *package* isn't getting used.
I'm just saying that the *service* is not.
> Wouldn't it be better to just wipe the unattended-upgrades package, if
> it is
> of no use at all?
No no, I was just talking about the systemd service that does the
When you look at the code, the default appears to be "false".
>> On the other hand your grub feature might also stop working, it
>> assumes /boot is mounted.
> The feature to record successful boot? Well, I lived about 25 years
> this feature.
> Guess, nowadays there's no
> way anymore to work around boot problems without this feature?
No, it just ensures that next time Grub will show a menu. All my
installations show a menu anyway (I don't know for what reason, I don't
understand grub), it is just a grub feature for different UI behaviour.
I don't think it does much for me, but I'd have to check my .cfg.
> Well. Depends how often you boot. In addition, as I described in my
> post, you don't need this at every boot. In practice, it's about once a
> or something. For me, it's not a big deal to type this once a month.
Oh. So once a month there is a chance that some attacker would have
found your turned-off laptop ;-).
Well I thank you for your lessons.
>> You can still do that because you can install Grub in as many places
>> as you
> What would this buy me?
Multiple places to boot the same system from.
I mean you can install it on some SD card that you take with you.
Then you can *also* boot from the SD card. Note that it will still use
the same /boot, it just means to have the Grub boot.img and core.img
installed somewhere else (concurrently).
>> Update-grub does not actually impact the grub bootsector/core image.
> And I'll have to create a new cd every time grub is updated for EVERY
Generally grub updates do not require reinstallation of Grub. Grub is
only installed once, grub-install is almost never run.
So it is more likely and common that you would need to create one CD per
system during the lifetime of its OS.
Grub-inside-your-bootsector only contains the address (UUID) of your
And any modules you have chosen to incorporate into the image (core.img)
that almost no one does.
So as long as you don't change your boot partition, you don't need to
I boot frequently from SD card. I have no grub on my harddisk.
> Grabbing the next-reachable live-cd (even if it is five years old)
> looks much
> more attractive to me.
Sure I'm not saying you have to do it.
If you only boot once a month it is not much of a deal anyway.
> This is ONE cd for all systems.
Didn't realize you were doing more systems this way.
> And I never need to recreate it.
This is more like TrueCrypts "recovery" disks that are a pain to create
But only because you have them littering around ;-).
On the other hand if you securely lock away an SD-card in your home (or
USB stick) in some kind of vault or hidden place,
then you are also guaranteed to have a boot loader that is not tampered
If you encrypt /boot of course :p.
But I understand you are happy with your situation, so I will leave it
at that (it is a nice and neat system).
> Years ago, hibernate on laptops did not work properly.
These are AM2+ motherboards.
> But nowadays I'm not noticing problems on this topic anymore.
> All my non-laptops are runing 24/7.
I want to shut them down :). Or, standby then.
> Never felt like urgently needing this strange standby-thing. ;-)
Power consumption and silence in the home and inability to use the
I sometimes even take the mains out of my house to get away from
>> I guess it is not theoretically possible to defeat that.
> The only way is to always verify code/data before it is executed/used.
Yes yes, I understand now.
> This is why TPM was invented. But TPM has other flaws, as you surely
I am not fully aware but hardware encryption just seems like a really
It just seems to have the effect of putting control into the arms of the
manufacturers cq. software vendors.
More information about the ubuntu-users