[opensuse] Tumbleweed setup...Not enough room on 500GB HD? I don't think so...ignore?
I setup: /dev/sda1: boot@64MB /dev/sda2: swap (8G) /dev/sda3: / (root) 512GB /dev/sd4: LVM (1.5TB) /home-pool (thin pool; 750GB) /home (thin disk 500GB) --- Then it told me insufficent space for a server (text mode) setup. ??? Went to go back to partition table -- apparently went 1 too far... it then wiped all my changes. Back to drawing board... Um... so when it comes up and says not enough space, everyone knows that it full of doodoo....right? :~! (*grimace*) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-18 21:27, L A Walsh wrote:
I setup: /dev/sda1: boot@64MB
That one is too little for defaults. I use 500 MB.
/dev/sda2: swap (8G) /dev/sda3: / (root) 512GB
That one is big. I have installed in 8. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
L A Walsh composed on 2017-04-18 12:27 (UTC-0700):
I setup: /dev/sda1: boot@64MB
Is 64MB a typo? I remember that was a recommended size something like 15 years ago, when kernels were very much smaller. On TW host gx62b I have 4 kernels installed. du -h /boot shows 235M consumed by /boot, or about 59MB (!?) per kernel not counting anything for bootloader files. Seems like even one installed kernel could conceivably not fit in a 64M boot filesystem given the larger size of initrds created at installation time. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/18/2017 01:45 PM, Felix Miata wrote:
L A Walsh composed on 2017-04-18 12:27 (UTC-0700):
I setup: /dev/sda1: boot@64MB
Is 64MB a typo? I remember that was a recommended size something like 15 years ago, when kernels were very much smaller.
On TW host gx62b I have 4 kernels installed. du -h /boot shows 235M consumed by /boot, or about 59MB
I have no actual /boot partition, just a directory called /boot so it might not be the same thing. But in /boot it all fits in 63M, including two kernels, 4.4.57 and 4.4.49.
jsa@poulsbo:~> du -h /boot 4.0K /boot/grub2/backgrounds 1.4M /boot/grub2/fonts 200K /boot/grub2/themes/openSUSE/old-icons 836K /boot/grub2/themes/openSUSE 840K /boot/grub2/themes 2.0M /boot/grub2/locale 2.4M /boot/grub2/i386-pc 6.6M /boot/grub2 63M /boot
Why bother with a /boot partition any more? Is there any advantage these days? -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-19 00:31, John Andersen wrote:
Why bother with a /boot partition any more? Is there any advantage these days?
Some times there is need, yes. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On April 18, 2017 6:37:17 PM PDT, "Carlos E. R." <robin.listas@telefonica.net> wrote:
Why bother with a /boot partition any more? Is there any advantage
On 2017-04-19 00:31, John Andersen wrote: these days?
Some times there is need, yes.
Name one. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen wrote:
On April 18, 2017 6:37:17 PM PDT, "Carlos E. R." <robin.listas@telefonica.net> wrote:
Why bother with a /boot partition any more? Is there any advantage
On 2017-04-19 00:31, John Andersen wrote: these days?
Some times there is need, yes.
Name one.
I don't use a boot partition either, but maybe when the root filesystem is on LVM or encrypted or something like that? -- Per Jessen, Zürich (2.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-19 09:25, Per Jessen wrote:
John Andersen wrote:
On April 18, 2017 6:37:17 PM PDT, "Carlos E. R." <robin.listas@telefonica.net> wrote:
Why bother with a /boot partition any more? Is there any advantage
On 2017-04-19 00:31, John Andersen wrote: these days?
Some times there is need, yes.
Name one.
I don't use a boot partition either, but maybe when the root filesystem is on LVM or encrypted or something like that?
Correct. May also be needed with some RAID modes. Also I tried not too long ago to install Leap on XFS root without /boot, and I couldn't, grub failed. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
19.04.2017 12:47, Carlos E. R. пишет:
On 2017-04-19 09:25, Per Jessen wrote:
John Andersen wrote:
On April 18, 2017 6:37:17 PM PDT, "Carlos E. R." <robin.listas@telefonica.net> wrote:
Why bother with a /boot partition any more? Is there any advantage
On 2017-04-19 00:31, John Andersen wrote: these days?
Some times there is need, yes.
Name one.
I don't use a boot partition either, but maybe when the root filesystem is on LVM or encrypted or something like that?
Correct.
Wrong.
May also be needed with some RAID modes.
Wrong again.
Also I tried not too long ago to install Leap on XFS root without /boot, and I couldn't, grub failed.
That's correct, you cannot *install* GRUB on partition with XFS because XFS does not reserve the first sector for partition boot record. It does not mean you cannot install GRUB somewhere else (MBR, extended partition) and use it with /boot on XFS.
On 2017-04-19 19:17, Andrei Borzenkov wrote:
19.04.2017 12:47, Carlos E. R. пишет:
On 2017-04-19 09:25, Per Jessen wrote:
John Andersen wrote:
On April 18, 2017 6:37:17 PM PDT, "Carlos E. R." <robin.listas@telefonica.net> wrote:
Why bother with a /boot partition any more? Is there any advantage
On 2017-04-19 00:31, John Andersen wrote: these days?
Some times there is need, yes.
Name one.
I don't use a boot partition either, but maybe when the root filesystem is on LVM or encrypted or something like that?
Correct.
Wrong.
May also be needed with some RAID modes.
Wrong again.
Must be new feature in grub. How can you boot from raid 5, if the kernel is distributed on 3 disks, can not be found as a contiguous block anywhere? Similarly for LVM. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
19.04.2017 21:25, Carlos E. R. пишет:
On 2017-04-19 19:17, Andrei Borzenkov wrote:
19.04.2017 12:47, Carlos E. R. пишет:
On 2017-04-19 09:25, Per Jessen wrote:
John Andersen wrote:
On April 18, 2017 6:37:17 PM PDT, "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2017-04-19 00:31, John Andersen wrote: > Why bother with a /boot partition any more? Is there any advantage these days?
Some times there is need, yes.
Name one.
I don't use a boot partition either, but maybe when the root filesystem is on LVM or encrypted or something like that?
Correct.
Wrong.
May also be needed with some RAID modes.
Wrong again.
Must be new feature in grub.
How can you boot from raid 5, if the kernel is distributed on 3 disks, can not be found as a contiguous block anywhere?
You install stage1.5 (a.k.a core.img) on every disk.
Similarly for LVM.
Ditto.
On 2017-04-19 20:44, Andrei Borzenkov wrote:
19.04.2017 21:25, Carlos E. R. пишет:
On 2017-04-19 19:17, Andrei Borzenkov wrote:
19.04.2017 12:47, Carlos E. R. пишет:
On 2017-04-19 09:25, Per Jessen wrote:
John Andersen wrote:
On April 18, 2017 6:37:17 PM PDT, "Carlos E. R." <robin.listas@telefonica.net> wrote: > On 2017-04-19 00:31, John Andersen wrote: >> Why bother with a /boot partition any more? Is there any advantage > these days? > > Some times there is need, yes.
Name one.
I don't use a boot partition either, but maybe when the root filesystem is on LVM or encrypted or something like that?
Correct.
Wrong.
May also be needed with some RAID modes.
Wrong again.
Must be new feature in grub.
How can you boot from raid 5, if the kernel is distributed on 3 disks, can not be found as a contiguous block anywhere?
You install stage1.5 (a.k.a core.img) on every disk.
Similarly for LVM.
Ditto.
And YaST does this automatically? That's nice. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
19.04.2017 23:03, Carlos E. R. пишет:
On 2017-04-19 20:44, Andrei Borzenkov wrote:
19.04.2017 21:25, Carlos E. R. пишет:
On 2017-04-19 19:17, Andrei Borzenkov wrote:
19.04.2017 12:47, Carlos E. R. пишет:
On 2017-04-19 09:25, Per Jessen wrote:
John Andersen wrote:
> On April 18, 2017 6:37:17 PM PDT, "Carlos E. R." > <robin.listas@telefonica.net> wrote: >> On 2017-04-19 00:31, John Andersen wrote: >>> Why bother with a /boot partition any more? Is there any advantage >> these days? >> >> Some times there is need, yes. > > Name one.
I don't use a boot partition either, but maybe when the root filesystem is on LVM or encrypted or something like that?
Correct.
Wrong.
May also be needed with some RAID modes.
Wrong again.
Must be new feature in grub.
How can you boot from raid 5, if the kernel is distributed on 3 disks, can not be found as a contiguous block anywhere?
You install stage1.5 (a.k.a core.img) on every disk.
Similarly for LVM.
Ditto.
And YaST does this automatically?
It does it in some cases; I do not know if it does it in every configuration. But this is also orthogonal to whether we need separate /boot or not.
On 2017-04-20 05:15, Andrei Borzenkov wrote:
19.04.2017 23:03, Carlos E. R. пишет:
You install stage1.5 (a.k.a core.img) on every disk.
Similarly for LVM.
Ditto.
And YaST does this automatically?
It does it in some cases; I do not know if it does it in every configuration. But this is also orthogonal to whether we need separate /boot or not.
Well, if I'm going to install a new system with raid 5 or 6, my traditional knowhow says I have to install a separate /boot replicated on each disk, and run grub 3 or 4 times manually to install grub on all. Instead, if I can go with no separate /boot and YaST handles it all correctly so that system will always boot regardless of what disk is missing, that's something very interesting to know ;-) I don't mention LVM because I have never installed it. The other configuration I want is encrypted full disk without LVM. YaST does not support it, the procedure is manual. To avoid separate /boot, grub has to understand encryption and ask for the password early enough. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Thu, Apr 20, 2017 at 2:10 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2017-04-20 05:15, Andrei Borzenkov wrote:
19.04.2017 23:03, Carlos E. R. пишет:
You install stage1.5 (a.k.a core.img) on every disk.
Similarly for LVM.
Ditto.
And YaST does this automatically?
It does it in some cases; I do not know if it does it in every configuration. But this is also orthogonal to whether we need separate /boot or not.
Well, if I'm going to install a new system with raid 5 or 6, my traditional knowhow says I have to install a separate /boot replicated on each disk, and run grub 3 or 4 times manually to install grub on all.
Instead, if I can go with no separate /boot and YaST handles it all correctly so that system will always boot regardless of what disk is missing, that's something very interesting to know ;-)
It does it at least for RAID1 (also multiple disks) and somebody recently reported that YaST did it also for RAID5; so yes, it works.
I don't mention LVM because I have never installed it.
That I do not know, but I do not remember seeing any code to handle LVM explicitly, so suspect YaST will not do it.
The other configuration I want is encrypted full disk without LVM. YaST does not support it, the procedure is manual. To avoid separate /boot, grub has to understand encryption and ask for the password early enough.
It understands it. I lost count of how many times I told you so. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-20 15:33, Andrei Borzenkov wrote:
On Thu, Apr 20, 2017 at 2:10 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
The other configuration I want is encrypted full disk without LVM. YaST does not support it, the procedure is manual. To avoid separate /boot, grub has to understand encryption and ask for the password early enough.
It understands it. I lost count of how many times I told you so.
Yes, I know that Grub understands it. I said that YaST doesn't. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 20/04/17 07:10 AM, Carlos E. R. wrote:
The other configuration I want is encrypted full disk without LVM. YaST does not support it, the procedure is manual. To avoid separate /boot, grub has to understand encryption and ask for the password early enough.
When you're doing RESCUE stuff, depending on what it was that necessitated the RESCUE, a separate /boot partition that may or may not be outside the LVM and/or may or may not be on a single drive of an array may or may not be useful. My life, my experience, my sysadmin-paranoia, the itching between my shoulder-blades and my cynicism about the economics of the technology of hard drives, as explained to me by the manager at the company tat I once took a drive in for 'recovery' all leads me to having a /boot on a REAL partition (that is, outside the LVM) on each drive or *ANY* kind of a RAID array. Even if I have to update them independently manually. Even if this is beyond anything YAST can assist with. One day I'll write up the gripe that manager explained to me, how it ties in with the the manufacturing process and the supposed handling of bad blocks, but crates a set of unnecessary failure modes of its own, why he saw it as impacting his business and why he saw it as causing unnecessary grief to consumers and small businesses alike. To be fair, SSDs probably cripple his business, but that's another matter. Given my druthers, I'd go for just about any form of encryption except the user-unfriendly double mounting modes of FUSE. Various ones have their own advantages and disadvantages. What you need to think about is whether the idea of an encryption system that works only when your machine is shut down is enough. I wonder about EncFS sometimes, the idea of having the encrypted files on a live system accessed via NFS but only decoded locally. Has anyone used this? By comparison, I use a Aegis Secure USB key from Apricorn. It's a 30G device and has admin as well as user level keys. Encryption is done by hardware and is !FAST! 30G is _just_ large enough to put a bootable Linux on, along with all the X stuff, fonts, man pages, drivers. However, as I've discussed before, what is it you want to focus on when encrypting, code or data? In a perfect world you'd have unlimited (portable) storage that doesn't degrade in speed with decryption. In reality ... what? Maybe you think that LUKS/FUSE is enough. As it happens, most of the machines I have access to have two USB ports accessible from the front. They are not always USB3 :-( Some machines don't have USB3 at all :-( :-( But two ports means that I can use on for my "system" USB (which for various systems might be 8G, 16G or 32G) and the other for my SecureKey, the latter being all DATA. YMMV The Apricorn devices aren't cheap. But if you need that kind of security, really need it in a way that most home users rarely do, then from a Corporate POV is not merely part of the cost of doing business, its cheaper than the risks associated with conventional USB sticks. Or even some forms of cloud storage. Apricorn have USB sticks from 4G (around $60) to 480G (around $400) in the same format. Of course they have portable drives, portable SSD and internal drives. https://www.apricorn.com/ I'm not associated with Apricorn in any way other than being a satisfied user. Maybe you think that LUKS is all you need, but maybe your corporate auditors don't. Something like an Aegis device with proper certification can address that. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-20 15:44, Anton Aylward wrote:
However, as I've discussed before, what is it you want to focus on when encrypting, code or data? In a perfect world you'd have unlimited (portable) storage that doesn't degrade in speed with decryption. In reality ... what? Maybe you think that LUKS/FUSE is enough.
Data, but there is sensitive data spread on several directories. WiFi passwords somewhere on /etc, logs on /var, temporary files in /tmp, and others I forget. So the answer, for a laptop, is "all". I don't care if it can be broken. The average burglar will not know how. If they want read the disk, they will have to sweat. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 20/04/17 01:40 PM, Carlos E. R. wrote:
On 2017-04-20 15:44, Anton Aylward wrote:
However, as I've discussed before, what is it you want to focus on when encrypting, code or data? In a perfect world you'd have unlimited (portable) storage that doesn't degrade in speed with decryption. In reality ... what? Maybe you think that LUKS/FUSE is enough.
Data, but there is sensitive data spread on several directories. WiFi passwords somewhere on /etc, logs on /var, temporary files in /tmp, and others I forget. So the answer, for a laptop, is "all".
Don't forget SWAP! This is why I don't think simply encrypting partitions or files or directories is enough in this sort of context. You need an encrypted DISK. You need a HARDWARE ENCRYPTED DISK !!!
I don't care if it can be broken. The average burglar will not know how. If they want read the disk, they will have to sweat.
Once again I refer to the story about the the data thief that stole the laptop while it was active, while the owner was logged in and the encrypted volumes visible in the clear. Potable devices are not secure, or perhaps that should be phrased "they are not securable enough". -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-20 23:20, Anton Aylward wrote:
On 20/04/17 01:40 PM, Carlos E. R. wrote:
On 2017-04-20 15:44, Anton Aylward wrote:
However, as I've discussed before, what is it you want to focus on when encrypting, code or data? In a perfect world you'd have unlimited (portable) storage that doesn't degrade in speed with decryption. In reality ... what? Maybe you think that LUKS/FUSE is enough.
Data, but there is sensitive data spread on several directories. WiFi passwords somewhere on /etc, logs on /var, temporary files in /tmp, and others I forget. So the answer, for a laptop, is "all".
Don't forget SWAP!
This is why I don't think simply encrypting partitions or files or directories is enough in this sort of context. You need an encrypted DISK.
It doesn't matter, you can encrypt all partitions.
You need a HARDWARE ENCRYPTED DISK !!!
Well, it does exist. It is a standard. But I have no idea how to enter the password when powering the laptop before the hard disk can be read at all. See "man hdparm", then seek the word "security". First hit: "ATA Security Feature Set" And that's about all I know about the thing. Most important, I have not found information about how secure it is. I mean, is it breakable? Is it an access password, or is it true encryption?
I don't care if it can be broken. The average burglar will not know how. If they want read the disk, they will have to sweat.
Once again I refer to the story about the the data thief that stole the laptop while it was active, while the owner was logged in and the encrypted volumes visible in the clear.
I know about that. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Am Samstag, 22. April 2017, 00:41:21 CEST schrieb Carlos E. R.:
On 2017-04-20 23:20, Anton Aylward wrote: [...]
You need a HARDWARE ENCRYPTED DISK !!!
Well, it does exist. It is a standard. But I have no idea how to enter the password when powering the laptop before the hard disk can be read at all.
It is done by the "BIOS". And there is no standard how the "BIOS" translates your key presses into the password that you can use with hdparm. So, if your computer dies and you have to move your disk to another computer, you will not be able to unlock it and all your data will be lost. This is unacceptable. Besides the "BIOS" may reduce your password strength and might even store it: https://jbeekman.nl/blog/2015/03/lenovo-thinkpad-hdd-password/ Luckily I was curious enough to check this before I activated the hardware encryption on my new SSD... Gruß Jan -- Colorless green ideas sleep furiously. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-22 12:45, Jan Ritzerfeld wrote:
Am Samstag, 22. April 2017, 00:41:21 CEST schrieb Carlos E. R.:
On 2017-04-20 23:20, Anton Aylward wrote: [...]
You need a HARDWARE ENCRYPTED DISK !!!
Well, it does exist. It is a standard. But I have no idea how to enter the password when powering the laptop before the hard disk can be read at all.
It is done by the "BIOS".
How? I have not seen any option in the BIOS mentioning this feature, on several computers. Where to enable it? [Reading the blog later, it appears that some BIOSES do have this feature]
And there is no standard how the "BIOS" translates your key presses into the password that you can use with hdparm.
To use with hdparm it is the Linux keyboard drivers and maps, not the bios. To activate the disk before booting with the bios would be the bios, the same keyboard native to the computer, which is used on the several bios screens. It is even better with UEFI, it seems.
So, if your computer dies and you have to move your disk to another computer, you will not be able to unlock it and all your data will be lost. This is unacceptable.
You can boot with another disk, then enable the encrypted disk using hdparm in Linux.
Besides the "BIOS" may reduce your password strength and might even store it: https://jbeekman.nl/blog/2015/03/lenovo-thinkpad-hdd-password/ Luckily I was curious enough to check this before I activated the hardware encryption on my new SSD...
Ah. The inability to access the disk refers to Lenovo and SSDs, not necessarily to all implementations. Ant the blog author has written a tool to open the disk with hdparm. The problem is (reading the blog) that the BIOS changes the password before sending it to the disk in a bios specific way for that computer. And the second problem is that, the blog says, all SSD drives use encryption already without the user knowing. When the user enables it, what it does is place a password on top of the password (or something similar, read the article for correct details). Nasty. You can use encryption safely only if you manage to, after setting it up in the bios, you can manage to access it using hdparm. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Am Samstag, 22. April 2017, 13:29:03 CEST schrieb Carlos E. R.:
On 2017-04-22 12:45, Jan Ritzerfeld wrote: [...]
It is done by the "BIOS".
How?
For Lenovo: http://monitor.espec.ws/files/lewnovo_password_399.pdf
I have not seen any option in the BIOS mentioning this feature, on several computers. Where to enable it?
[Reading the blog later, it appears that some BIOSES do have this feature]
IIRC I've seen that on Lenovos, Dells and HPs. Maybe only business or rugged models.
And there is no standard how the "BIOS" translates your key presses into the password that you can use with hdparm.
To use with hdparm it is the Linux keyboard drivers and maps, not the bios.
And then you can't use the BIOS to unlock the disk.
To activate the disk before booting with the bios would be the bios, the same keyboard native to the computer, which is used on the several bios screens. It is even better with UEFI, it seems.
It could but often it does not use the keyboard layout but scancodes.
So, if your computer dies and you have to move your disk to another computer, you will not be able to unlock it and all your data will be lost. This is unacceptable. You can boot with another disk, then enable the encrypted disk using hdparm in Linux.
If you know the algorithm and all other key used by the BIOS.
Besides the "BIOS" may reduce your password strength and might even store it: https://jbeekman.nl/blog/2015/03/lenovo-thinkpad-hdd-password/ Luckily I was curious enough to check this before I activated the hardware encryption on my new SSD...
Ah. The inability to access the disk refers to Lenovo and SSDs, not necessarily to all implementations.
It is not that specific to Lenovo and SSDs. HDDs use the same encryption standard and other manufactures also use scancodes: http://www.tomshardware.co.uk/forum/290824-32-password-dead-computer
Ant the blog author has written a tool to open the disk with hdparm.
According to the comments, the tool works only for some models.
The problem is (reading the blog) that the BIOS changes the password before sending it to the disk in a bios specific way for that computer.
Exactly.
And the second problem is that, the blog says, all SSD drives use encryption already without the user knowing. When the user enables it, what it does is place a password on top of the password (or something similar, read the article for correct details).
Well, I don't think that this a big problem.
Nasty.
You can use encryption safely only if you manage to, after setting it up in the bios, you can manage to access it using hdparm.
Yes. Gruß Jan -- Any system that depends on human reliability is unreliable. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/20/2017 06:44 AM, Anton Aylward wrote:
What you need to think about is whether the idea of an encryption system that works only when your machine is shut down is enough.
Exactly. And usually that means its only worth while for a laptop that travels and may get lost/stolen, or media that can "walk away". You are going to give up that encryption key like a blubbering school boy when they come with warrants and guns, so why pretend encryption protects anything on always-running spinning storage in your home or office server room? I've used encryption (LUKS) on 13.2 on my traveling laptop for years and it never caused me any problem. I abandoned it when I did a fresh 42.2 install on SSD. The old disk is in a caddy, and I've occasionally plugged it in to a couple different distros to retrieve data, and it pops up asking for the decryption password each time just like it always did. (To relate to the topic title, I didn't try whole disk encryption, nor did I encrypt /boot or /root on that laptop, just /home and /data where source code and money things live). -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 20/04/17 02:16 PM, John Andersen wrote:
On 04/20/2017 06:44 AM, Anton Aylward wrote:
What you need to think about is whether the idea of an encryption system that works only when your machine is shut down is enough.
Exactly. And usually that means its only worth while for a laptop that travels and may get lost/stolen, or media that can "walk away".
Let me qualify that: it is only worth while for a laptops that travels and may get lost/stolen WHILE SHUT DOWN. If the thief is ingenious enough to steal your laptop while logged in and the data is accessible in the clear and has the means to keep the laptop powered up then that is a very different scenario. See http://www.johnsandford.org/kidd04.html for a novelization of this scenario.
You are going to give up that encryption key like a blubbering school boy when they come with warrants and guns, so why pretend encryption protects anything on always-running spinning storage in your home or office server room?
The real difference between _their_ Stasi, "The Ministry for State Security" and _our_ Stasi, 'The Department of Homeland Security", is that we live in a more material rich society. We have (cholesterol rich) beef on the table, 40+ inch TVs, Graceland, Disneyland, cheap air travel (if you are willing to queue, be groped and stripped searched, and possibly dragged off kicking and screaming) and other consumer comforts, as well as the ability to bitch and complain about it all on the 'Net, in print and at the pub, just so long as you don't actually do anything.
I've used encryption (LUKS) on 13.2 on my traveling laptop for years and it never caused me any problem. I abandoned it when I did a fresh 42.2 install on SSD.
That reassures me immensely. When I travel, I remove the password protection from all my portable devices. I used to think that it would save a lot of hassle. It used to, yes. Now I'm getting asked why I don't use passwords...
The old disk is in a caddy, and I've occasionally plugged it in to a couple different distros to retrieve data, and it pops up asking for the decryption password each time just like it always did.
Yes, I do that with my old //etc and more, keep the DVDs with /home and so forth. Some RootFS live on LVM partitions. Now I have to figure out how to stop drakut/mkinitrd scanning them. Oh, right /etc/default/grub ... os-prober
(To relate to the topic title, I didn't try whole disk encryption, nor did I encrypt /boot or /root on that laptop, just /home and /data where source code and money things live).
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 20/04/17 12:10, Carlos E. R. wrote:
Well, if I'm going to install a new system with raid 5 or 6, my traditional knowhow says I have to install a separate /boot replicated on each disk,
No need for that - provided you have sufficient redundancy grub will be able to find your /boot (and if you don't have sufficient redundancy, you're screwed anyway).
and run grub 3 or 4 times manually to install grub on all.
This is nothing to do with raid, and everything to do with having a bootable disk. You should always install grub on every disk that has (part of) your root partition. That way, it doesn't matter how many (or which) disks you lose, or whether your bios gets hopelessly confused about the disk discovery order, the first disk the bios recognises always has a valid bootloader. Once the bootloader is running, that can (try to) sort out the rest of the boot procedure. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 19/04/17 19:25, Carlos E. R. wrote:
Must be new feature in grub.
How can you boot from raid 5, if the kernel is distributed on 3 disks, can not be found as a contiguous block anywhere?
Pretty standard. Grub2 is now a mini-operating-system in its own right (like emacs, it comes with a kitchen sink installed :-). Load the raid module into grub, and it will happily boot off a raid system (or lvm, or whatever, with the right modules), and it couldn't care where /, or /boot, are. You just need to make sure you use an initrd to boot, as user-space is required to assemble a raid array, and of course no initrd == no user space == no way to boot off modern linux raid. (That's for bios systems - uefi is different, don't ask me how as I haven't yet played with it.) The only way to boot off raid with no initrd is to use a mirror with a v0.9 or v1.0 superblock. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata wrote:
L A Walsh composed on 2017-04-18 12:27 (UTC-0700):
I setup: /dev/sda1: boot@64MB Is 64MB a typo? I remember that was a recommended size something like 15 years ago, when kernels were very much smaller.
No... The one on my main machine has 235MB of files -- but that's with 24 kernels. I don't figure to be updating an appliance-type device as often.
On TW host gx62b I have 4 kernels installed. du -h /boot shows 235M consumed by /boot, or about 59MB (!?) per kernel not counting anything for bootloader files. Seems like even one installed kernel could conceivably not fit in a 64M boot filesystem given the larger size of initrds created at installation time. !!!! -- 4 kernels consuming 235M???
How? -- each of my kernels take from a low of 5.5 to a high of 7.0 MB each. Then I have System maps for each of those @ 2.8-3.3MB each, so say 8.3 - 10.3/kernel? AH!... it has to be the initrd's... sad, but I'd think those were mostly duplicated files (at least from same OS release). If you could combine them all so you would only be charged once for dup files ... I deal with that by having my "initrd" be my root drive. So only am using the ~10M/kernel. FWIW, on the rebuild, set it to 128MB. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-04-19 01:54, L A Walsh wrote:
AH!... it has to be the initrd's...
Yes. You are installing using defaults, not "your way". -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 18/04/17 04:45 PM, Felix Miata wrote:
L A Walsh composed on 2017-04-18 12:27 (UTC-0700):
I setup: /dev/sda1: boot@64MB
Is 64MB a typo? I remember that was a recommended size something like 15 years ago, when kernels were very much smaller.
On TW host gx62b I have 4 kernels installed. du -h /boot shows 235M consumed by /boot, or about 59MB (!?) per kernel not counting anything for bootloader files. Seems like even one installed kernel could conceivably not fit in a 64M boot filesystem given the larger size of initrds created at installation time.
I have a 1.6G /boot with three kernels, all of Grub2: occupancy 6%. Of course the modules live under /lib which is on the RootFS. I wonder sometimes about Bleachbit and if it should be able to purge those. Butter than 90% of them don't get used on a specific system. I will grant you that Linux, unlike MS-Windows, is hard-disk portable across hardware. This is exceedingly useful when it comes to using a USB stick! To be fair, some versions of Linux are more 'portable' as USB/LiveCD than others. I recall times that I've had problems with RedHat, Mageia and openSuse LiveCDs, and of course ubuntu LiveCD, (which I've given up on ever using!), but never, ever with Knoppix. But for most people the hard drive in desktop PC is personal. Under what conditions might I move the drive to another machine as opposed to install/reinstall and then restore my /home and /srv? Well, quite a lot, actually, I've done that a few times. I am not a vendor or someone who installs on disks and ships them to friends. I've never been pressed for space enough to want to purge modules. Bleachbit? Well I use that to purge caches, primarily. # du -sh /boot/* 3.1M /boot/System.map-4.10.10-1.ga78ebd0-default 3.1M /boot/System.map-4.10.9-1.g195f937-default 3.1M /boot/System.map-4.10.9-2.g739eada-default 4.0K /boot/backup_mbr 4.0K /boot/boot.readme 192K /boot/config-4.10.10-1.ga78ebd0-default 192K /boot/config-4.10.9-1.g195f937-default 192K /boot/config-4.10.9-2.g739eada-default 4.0K /boot/dracut 6.8M /boot/grub2 0 /boot/initrd 11M /boot/initrd-4.10.10-1.ga78ebd0-default 11M /boot/initrd-4.10.9-1.g195f937-default 11M /boot/initrd-4.10.9-2.g739eada-default 16K /boot/lost+found 492K /boot/message 4.0K /boot/perl-BL_delayed_exec 372K /boot/symvers-4.10.10-1.ga78ebd0-default.gz 372K /boot/symvers-4.10.9-1.g195f937-default.gz 372K /boot/symvers-4.10.9-2.g739eada-default.gz 4.0K /boot/sysctl.conf-4.10.10-1.ga78ebd0-default 4.0K /boot/sysctl.conf-4.10.9-1.g195f937-default 4.0K /boot/sysctl.conf-4.10.9-2.g739eada-default 9.4M /boot/vmlinux-4.10.10-1.ga78ebd0-default.gz 9.4M /boot/vmlinux-4.10.9-1.g195f937-default.gz 9.4M /boot/vmlinux-4.10.9-2.g739eada-default.gz 0 /boot/vmlinuz 6.8M /boot/vmlinuz-4.10.10-1.ga78ebd0-default 6.8M /boot/vmlinuz-4.10.9-1.g195f937-default 6.8M /boot/vmlinuz-4.10.9-2.g739eada-default # du -sh /lib/modules//* 208M /lib/modules//4.10.10-1.ga78ebd0-default 208M /lib/modules//4.10.9-1.g195f937-default 208M /lib/modules//4.10.9-2.g739eada-default -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (9)
-
Andrei Borzenkov -
Anthony Youngman -
Anton Aylward -
Carlos E. R. -
Felix Miata -
Jan Ritzerfeld -
John Andersen -
L A Walsh -
Per Jessen