noauto option ignored in /etc/fstab?
list at xenhideout.nl
Tue Dec 12 00:36:13 UTC 2017
Josef Wolf schreef op 11-12-2017 23:29:
> I'm talking only about REAL hardware.
Well I just answered your question as to why I considered myself having
The answer to that question lies in the fact that some people also
encrypt remote systems.
> The install CD?
> I have grown a rake script that
> 1. downloads the server-install-cd
> 2. adds a menu entry to use my preseed file
> 3. deletes some packages which I don't feel like needing
> 4. installs a late-command, which will install a systemd service that
> executed when the freshly installed system is booted for the first
Oh I thought you would have added the stuff (new packages etc) in the
But I guess you want the latest versions immediately.
> 5. this "postinstall" script starts a screen session on tty6 and starts
> initial windows:
> - window 0: top
> - window 1: watch 'hostname -f; echo; route -n; echo; ifconfig'
> - window 2: watch 'ps fax | grep -v grep | grep -B 5 -A 24
> - window 3: runs the real postinstall script.
What if you wouldn't have network?
> The postinstall script:
> 1. makes sure network is available
> 2. removes cdrom from apt.conf
This thing seems to be bugged...the CD. You have to add it back to the
index each time if you want to use it :-/.
>> Also I think in my life the risks are different.
> If I can eliminate a risk without any effort, I go for it.
It's not without cost.
But for you it works.
I hide the boot partition because I want the adversary to have as little
information as possible.
The adversary knows it's a Linux system but does not even know the
kernel version or the distribution.
This just reduces the room for asking questions. Someone who is faced
with a blank wall cannot inquire into that wall, or less so.
For instance your boot system probably displays the name of the
partition that you are about to unlock, including the LUKS name.
The Grub boot prompt is nondescript, ugly (unfortunately) and more like
There is no clue about partition layout (because there is only one) and
after I'm done patching LUKS (one day, ever :p) there won't even be a
It will be a Grub bootsector, a LUKS header, some room... and then
Or even differently, LUKS headers are not encrypted, TrueCrypt's are.
TrueCrypt encrypts the partition table.
Linux doesn't even need no partition table.
But I dunno.
But anyway I want the adversary to see the least amount of interesting
No clue what to find, no desire to find out.
And I think it has served me well in the past :p.
> If there'd be a noticeable effort, I'd step back and think whether it's
> actually worth to do.
Sure but that's only true because you rarely reboot your machines or
power them off.
Which might mean you don't turn them off because it would incur
additional effort etc.
> You mean doing this automatically by a preseeded install-cd?
> I once had set up my install-cd for automatic disk partitioning.
No I never install "simple" systems so I also wouldn't use that same
feature (repartition or use empty space) for something automatic...
I am basically also still experimenting and every install I try
something new... This is my first dmraid system :p.
It's the *only* dmraid system you can boot from with Grub ( I think )
--- nVidia raid :p.
Not sure about that though.
Could be entirely wrong here.
I'm on dmraid and my root partition is cached too :p.
So I have a RAID 0 HDD system cached by SSD :p.
Using embedded LVM :p.
(I mean one partition contains 2 logical volumes that are actually
physical volumes for another volume group, and the SSD does the same,
Both the HDD (raid) and the SSD have a volume group called "coll".
The part that's on the HDDs contains msata-pv and raid-pv and the part
that's on the SSD contains msata-pv-cache and raid-pv-cache. msata-pv
and msata-pv-cache combine to form in this case a cached root.
And raid-pv and raid-pv-cache do the same for something else.
So I have a cached logical volume spawned from physical volumes that are
logical volumes that are part on raid 0 dmraid and part on SSD.
Now isn't that hilarious. And it all works :p.
> That was a really bad idea: It's way too easy to wipe all data by
Particularly if you can't even select the harddisk.
And even then...
>> Well, you know, I was only responding because you said encrypted boot
>> _not possible_.
> Oh! Then, I correct myself:
> It is not possible to have _everything_ encrypted. And this unencrypted
> of code/data is the achilles' heel.
Yes I see this now.
> You're STILL vulnerable as
> long as grub can be modified.
Depends on the form of adversary and in what way will they take your
Certain classes of adversaries will not wait around until you've typed
They take your stuff and then find out it's encrypted.
At that point, if they were to give back your stuff, you'd have plenty
of time to verify Grub (or reinstall it) and even if you didn't, they
wouldn't be there to steal your password.
And if this risk existed, yeah I guess you would watch your step.
> Right. But automation is not a prerequisite. Those scripts are really
Right. I know.
> Probably none. But since there's no effort, why not do it? Much better
> feeling safe just because /boot is encrypted...
Again depends on your goal ;-).
You might even choose not to encrypt anything because you want to show
the other person that you have nothing to hide.
Encrypting then, would feel very unsafe.
Because sometimes being secretive only raises suspicions.
_Some results may have been removed under data protection law in
More information about the ubuntu-users