noauto option ignored in /etc/fstab?

Xen list at xenhideout.nl
Mon Dec 11 14:26:54 UTC 2017


Josef Wolf schreef op 11-12-2017 0:13:

> But I still don't understand how the service got enabled. I've never 
> enabled
> it explicitly. And I can tell for sure, since I do all my system 
> configuration
> with an automatic system (similar to cfengine, but also invented by 
> myself).

Neither did I.

> I'm pretty much confused. When updats/upgrades are done by
> apt-daily[-upgrades] anyway, what ist this unattended-upgrades good 
> for?

They might execute the unattended-upgrade binary.

The package contains more than just the service.

> Now, THAT's the time I suspect somebody could have messed with the
> system. That's the time I reach for the live-cd.
> 
>> Well I thank you for your lessons.
> 
> Hmmm.. Feels like ironical? :-)

Well no I realized there is really no protection when you have an 
encrypted system on the internet.

I mean through a hosting provider.

There is no way to protect a system you either have to log in through 
some webpage, or, if you don't need that, through SSH when the initrd 
would be modifiable.

> Ummm... Been there about 15 years ago. Found SD-cards and USB-sticks to 
> be
> very unreliable. Are they more reliable nowadays?

Dunno.

> So that's about a dozen CDs for me.

:).

Haha.

> In fact, I also create my own preseeded installation CDs.

Can I ask what method you are using?

> Generating individual boot-{CD|SD|Sticks} would be much more effort for
> me.

Well like I said, not everyone is the same, this works for you, I don't 
have a dozen machines ;-).

Also I think in my life the risks are different.

So different situation different solutions.

> Same holds for going through the hell to get encrypted /boot. There's
> simple too much manual and error prone fiddling involved.

Of course, unless you have an automatic configuration script.

;-).

Now granted it means you cannot use default installs.

But let me see what is actually needed...

a) creating the LUKS container at the start
b) creating LVM
c) creating volumes and filesystems
d) selecting those in the installer (slow process)
e) creating a key
f) adding it to the container
g) initramfs-tools hook
h) crypttab line
i) patch to /etc/default/grub

Variables required:

- luks container name
- volume group name
- size of boot

That's about it, and your password.

If you can insert (g), (h) and (i) before the installer installs grub, 
most of it could be automated (or all of it).

I have been doing this for some time and I never had issues with it.

I can't say the same thing about:

- dm-cache
- dmraid
- nested LVM volumes

;-).

So no, it's not error prone. The above three things are error prone 
(because support is lacking).

There are really only 3/4 changes on your main system.

- the hook and grub config and crypttab can be automatically generated
- I only like to generate the key myself (I don't like to use entropy in 
an automated fashion).

So the real setup cost is not your running system (which works 
flawlessly) but the intial container setup, that's all.

It's really quite limited this thing.

More so it is easy to transform a DEFAULT installed system into this 
pretty quickly, but I have never done it yet.

In fact it only requires 3 changes to your system + the key, and the 
creating of a container on /dev/sda1, and recreating /boot there, 
followed by restoring its backup.

In ... 14 commands I could have this done to a default installed system, 
provided /boot was mounted ;-).

Fully automated except that you need to type in a password for 
/dev/sda1.

So in effectively 14 commands you could have an encrypted boot after 
starting out with a default installation using encrypted LVM.

> Yes. But that's a lot of additional effort without any additional 
> benefit.
> I prefer to have the benefit without additional cost.

Well, you know, I was only responding because you said encrypted boot 
was _not possible_.

Now you say it is not worth your time, but that's something different.

Not everyone has a dozen systems running with identical preconfigured 
Ubuntu or Debian installations using a self-written automation tool that 
is executed from within the installer, either.

I also don't know what risks you are running.

Typically in the home environment stuff getting _stolen_ (or taken by 
whatever) is a much higher risk than anyone being after your files but 
having the time to play games with you basically.

That category of person would be a corporate manager or important one.

In that case, yes.

Although I would first be looking at sealing the laptop case with a 
sticker that cannot easily be replaced or has to be broken.

Then, after disabling USB boot in the BIOS, there is no way that someone 
could modify your system.

But hey, I'm not you, I am sure you have good reasons for this.

Like I say, everyone is in a different life situation.


>> These are AM2+ motherboards.
> 
> Ah. Myself had only one amd MB. Around Y2000. Was not exactly
> reliable. Therefore all my systems are intel (although I sympathize 
> much more
> with AMD).

Me too. For some reason... all motherboards I have had recently... which 
comes down to about 4 or 5... had one issue or the other.

Asus M2N-SLI... overheated immensely in Linux and no standby (could be 
due to graphics card)
Asus M2N-E... usb issues and no standby (could potentially be the 
graphics card (nouveau) but I cannot get nvidia installed)

Abit AX78 -- not really any issues except cool 'n quiet being disabled 
while overclocking, and a really annoying way to access the boot menu 
(ESC) -- who thinks of that? THAT was not mentioned in the manual, and 
not mentioned in the BIOS, and took me 6 months to find out.

I mean wtf.

And no reliable standby (Windows required a hack, Linux never worked 
reliably or at all).

(Maybe my issue is the graphics cards and not the motherboards, but 
these are recent cards with support by kernels)

Asus M3N couldn't boot Grub while firmware RAID was enabled in the BIOS 
-- okay maybe I'm dumb I just wanted to try it out. Now I learn that 
syslinux would probably have booted it... maybe.

(Grub couldn't see any harddisks whatsoever).

I had another Asrock board that broke down so can't comment.

Yeah I'm not so very clever...


> Not a big deal with modern hardware. At least as long as you don't want 
> a
> gamer-√úC.

The short answer is that I'm an idiot I think.

The inability to use standby (...) has probably doubled my entire energy 
consumption for this home in the last 2 years because .... yeah....

(... 95W cpu also )

Honestly. I have had a DOUBLING of my electricity consumption over 2016 
and 2017 from ONE system.

This current system is not overclocked and idling and consuming 95W... I 
mean...

I did NOT expect that I needed to install this manually under UBUNTU.


:(.


Maybe it's not much, but it's down to 85W now.

That's 10W * 24 * 365 / 1000 * 0,20 = 17,50 euro per year just because 
this feature is turned off ;-).

I can't read the pstate of my graphics card using nouveau. I guess I can 
get the power consumption down there too...


>> I sometimes even take the mains out of my house to get away from 
>> computers.
> 
> Umm. Now THAT'S a nightmare! ;-)

It's actually bliss :p.

You should try it for an hour :p.

> That's exactly the problem.



More information about the ubuntu-users mailing list