Implementing ATA unlock in Grub hdparm
Hi guys, I've got some free time on my hands and I was thinking of adding ATA unlock support in grub's hdparm implementation. I wanted to see if somebody was actively working on this, or if somebody would be opposed to it being implemented. My main reason for wanting this feature is to give unlock support to systems that don't support it through the BIOS. My laptop for example (an HP DV7-somethingorother) has no such support, so I'm forced to use a custom initrd to unlock and freeze my drives. Cheers, G -- gamaral http://guillermoamaral.com/ http://about.me/gamaral ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Bug#747653: grub2-common: update-grub adds both devices and a line feed for BTRFS RAID 1 setup
В Sat, 06 Dec 2014 12:01:11 +0100
Martin Steigerwald пишет:
> Am Montag, 2. Juni 2014, 19:39:22 schrieb Andrey Borzenkov:
> > В Sat, 10 May 2014 20:53:34 +0200
> >
> > Martin Steigerwald пишет:
> > > Package: grub2-common
> > > Version: 2.02~beta2-10
> > > Severity: normal
> > >
> > > Dear Maintainer,
> > >
> > > I am booting my Debian system via a BTRFS RAID 1 which spans a logical
> > > volume on a Crucial MSATA and Intel SATA SSD each.
> > >
> > > After running update-grub I am getting this in /boot/grub/grub.cfg:
> > > echo'Linux 3.15.0-rc5-tp520 wird geladen …'
> > > linux /vmlinuz-3.15.0-rc5-tp520
> > > root=/dev/mapper/sata-debian
> > >
> > > /dev/mapper/msata-debian ro rootflags=subvol=debian
> > > init=/bin/systemd resume=/dev/mapper/sata-swap>
> > > echo'Initiale Ramdisk wird geladen …'
> > > initrd /initrd.img-3.15.0-rc5-tp520
> > >
> > > update-grub basically adds both devices of the BTRFS RAID 1 device
> > > separated by a line feed. For mounting BTRFS RAID 1 tough one of them
> > > is enough, once btrfs device scan is run, for which I currently use an
> > > script for initramfs-tools as a work-around as it didn´t work out of
> > > the box on my last tests[1].
> > >
> > > This behaviour is due to grub-probe which is called by grub-mkconfig
> > > at line 139
> > >
> > > 138 # Device containing our userland. Typically used for root= parameter.
> > > 139 GRUB_DEVICE="`${grub_probe} --target=device /`"
> > > 140 GRUB_DEVICE_UUID="`${grub_probe} --device ${GRUB_DEVICE}
> > > --target=fs_uuid 2> /dev/null`" || true
> > >
> > > which is called by update-grub returns both devices with a
> > > linefeed:
> > >
> > > merkaba:~> grub-probe --target=device /
> > > /dev/mapper/sata-debian
> > > /dev/mapper/msata-debian
> > >
> > > grub-probe is an ELF binary.
> > >
> > > The following little change workarounds the issue for me:
> > >
> > > merkaba:~> diff -u /usr/sbin/grub-mkconfig.dist /usr/sbin/grub-mkconfig
> > > --- /usr/sbin/grub-mkconfig.dist2014-05-08 14:35:25.0
> > > +0200
> > > +++ /usr/sbin/grub-mkconfig 2014-05-10 20:46:00.380096263 +0200
> > > @@ -136,7 +136,7 @@
> > >
> > > fi
> > >
> > > # Device containing our userland. Typically used for root= parameter.
> > >
> > > -GRUB_DEVICE="`${grub_probe} --target=device /`"
> > > +GRUB_DEVICE="`${grub_probe} --target=device / | head -1`"
> > >
> > > GRUB_DEVICE_UUID="`${grub_probe} --device ${GRUB_DEVICE} --target=fs_uuid
> > > 2> /dev/null`" || true
> > >
> > > # Device containing our /boot partition. Usually the same as
> > > GRUB_DEVICE.
> > >
> > > But I suppose the real fix is to be made in the binary grub-probe.
> >
> > No, grub-probe is correct; grub needs to know all devices so it can
> > have full information which drivers it requires to access them.
> >
> > See also
> > https://lists.gnu.org/archive/html/grub-devel/2014-05/msg5.html
> >
> > I suggest you discuss it with Colin, but for now I tend to think, fix
> > should go into 10_linux. May be always use UUID for btrfs.
> >
> > But this sounds like new can of worms :(
>
> Any way on how to proceed on this one?
>
Try patch below
From: Andrei Borzenkov
Subject: [PATCH] fix linux kernel root= argument with multidev btrfs
Btrfs may reside on multiple devices, but only one of them should be
passed to root= kernel argument. Add two helper functions:
- get_root_device: select "best" device for the list. For single device
just return it to skip probing; for multiple devices try to find LVM as
before but fall back to the first device if not found.
- find_abstraction: return device with requested abstraction driver from
the given list.
Refactor code to use them and reimplement uses_abstraction on top of
find_abstraction.
Also replace check for LVM with uses_abstraction in 10_kfreebsd.
---
util/grub-mkconfig_lib.in | 50 ++---
util/grub.d/10_kfreebsd.in | 8 +++-
util/grub.d/10_linux.in | 10 +
util/grub.d/20_linux_xen.in | 10 +
4 files changed, 53 insertions(+), 25 deletions(-)
diff --git a/util/grub-mkconfig_lib.in b/util/grub-mkconfig_lib.in
index 29ef865..ecae264 100644
--- a/util/grub-mkconfig_lib.in
+++ b/util/grub-mkconfig_lib.in
@@ -283,21 +283,27 @@ gettext_printf () {
printf "$(gettext "$gettext_printf_format")" "$@"
}
-uses_abstraction () {
- device="$1"
- old_ifs="$IFS"
+find_abstraction () {
+ abstraction="$1"
+ devices="$2"
+ old_IFS="$IFS"
IFS='
'
-
- abstraction="`"${grub_probe}" --device ${device} --target=abstraction`"
- for module in ${abstraction}; do
-if test "x${module}" = "x$2"; then
- IFS="$old_ifs"
- return 0
-fi
+ set $devices
+ IFS="$old_IFS"
+
+ for device in "$@"; do
+for module in `"${grub_probe}" --device "${device}" --target=abstraction`;
do
+ if test "x${modu
Re: Patch to support GELI passphrase passthrough
On 11/28/2014 14:36, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 27.10.2014 16:56, Kris Moore wrote:
>> On 10/22/2014 13:50, Kris Moore wrote:
>>> On 10/22/2014 13:47, Andrei Borzenkov wrote:
В Wed, 22 Oct 2014 13:12:32 -0400
Kris Moore пишет:
> Hey, just a small patch to submit today. If you rather I send this to
> the bug tracker then I can do that also.
>
> This patch allows exporting the FreeBSD GELI passphrase to the kernel
> environment, which we will be doing in PC-BSD to avoid prompting for the
> passphrase a second time at bootup.
>
>if (!grub_password_get (passphrase, MAX_PASSPHRASE))
> return grub_error (GRUB_ERR_BAD_ARGUMENT, "Passphrase not supplied");
>
> + /* Set the GELI passphrase to GRUB env, for passing to FreeBSD kernel
> */
> + grub_env_set ("gelipassphrase", passphrase);
> +
If I read BSD loader correctly, this should be kFreeBSD.gelipassphrase.
Is geli freebsd-specific?
>/* Calculate the PBKDF2 of the user supplied passphrase. */
>if (grub_le_to_cpu32 (header.niter) != 0)
> {
It sounds more logical to export it after it has been verified?
I tried to find out about this "gelipassphrase" kernel variable but did
not find anything. Is it already used anywhere?
> Let me know if you have any suggestions or need any changes. I'm
> currently hacking on support for EFI framebuffer settings to be passed
> to FreeBSD kernel as well, will send patches once I get things working
> there.
>
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
>>> Well, this patch just makes the variable available to grub.cfg file,
>>> then we do some stuff there like this:
>>>
>>> set kFreeBSD.kern.geom.eli.passphrase=
>>>
>>> The patch for support in FreeBSD should be in HEAD soon, but here it is
>>> if you want to take a look:
>>>
>>> https://github.com/pcbsd/freebsd/commit/79f4efcf6a7d4268781adc227d76ed9f7f0b685d
>>>
>> Any further thoughts on this patch? The FreeBSD integration hit HEAD a
>> few days back.
>>
>> https://github.com/freebsd/freebsd/commit/bdb0ac02b9fd8f331fa70c8a4c29495b7ee43293
>>
>> The reason I don't export the variable directly is so that when GRUB is
>> used to boot older versions of FreeBSD we don't set that variable, where
>> it isn't cleared from kernel memory. I would rather users enable it in
>> their grub.cfg manually, just so they know what it is doing.
>>
> How do you propose to handle the case of multiple geli disks? Perhaps it
> makes more sense to add a command line flag to cryptomount to save
> passphrase? Or to have the name of variable derived from UUID and/or
> disk name (both can coexist)
>
At the moment the FreeBSD system doesn't have a way to pass through
multiple keys for different disks. It will just try the single key
provided and prompt for others if that doesn't match.
If they change this in the future, then I would probably amend the grub
patches to export multiple variables from the UUID's.
--
Kris Moore
PC-BSD Software
iXsystems
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
