Re: [qubes-users] Qubes 3.2 trim problem

2018-02-17 Thread 'awokd' via qubes-users
On Fri, February 16, 2018 5:05 pm, awokd wrote:

> And if I'm missing some other reason that dracut -H should be included,
> please let me know! Might make sense to remove it from the GRUB section as
>  well.

Found this which seems like it might be related:

https://ask.fedoraproject.org/en/question/80389/cannot-open-luks-container-with-rescue-initramfs/

Rescue gets generated without -H by default, and the standard with it. I
never noticed an issue because I'm using the default keyboard layout.

That's good enough for me; going to add -H back in. Thanks for pointing it
out.



-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0f0ec60fe631d46cb28b7d93fe98a5ff.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes 3.2 trim problem

2018-02-16 Thread 'awokd' via qubes-users
On Fri, February 16, 2018 3:22 pm, 'awokd' via qubes-users wrote:
> On Fri, February 16, 2018 3:13 pm, nunotmalhe...@gmail.com wrote:
>
>> sexta-feira, 16 de Fevereiro de 2018 às 15:02:54 UTC, awokd escreveu:
>
>
>>> dracut -f /boot/efi/EFI/qubes/initramfs-$(uname -r).img $(uname -r)
>>>
>>> works for a generic version at least. Will go with that unless
>>> there's a better suggestion.
>>
>> Don't forget that the original doc had the host only option -H.
>>
>
> I am intentionally forgetting that. :) Per the man page:
>
>
> "If you want to create lighter, smaller initramfs images, you may want to
>  specify the --hostonly or -H option. Using this option, the resulting
> image will contain only those dracut modules, kernel modules and
> filesystems, which are needed to boot this specific machine. This has the
>  drawback, that you can’t put the disk on another controller or machine,
> and that you can’t switch to another root filesystem, without recreating
> the initramfs image. The usage of the --hostonly option is only for
> experts and you will have to keep the broken pieces. At least keep a copy
>  of a general purpose image (and corresponding kernel) as a fallback to
> rescue your system."
>
> For a generic recommendation, the tradeoffs don't seem worth saving a few
>  bytes. I figure if someone really needs those bytes they can add the -H
> themselves.

Submitted https://github.com/QubesOS/qubes-doc/pull/592 ; thank you both.

And if I'm missing some other reason that dracut -H should be included,
please let me know! Might make sense to remove it from the GRUB section as
well.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/96345a81acea560a2ecff143b1941f38.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes 3.2 trim problem

2018-02-16 Thread Ivan Mitev



On 02/16/2018 05:15 PM, 'awokd' via qubes-users wrote:

On Fri, February 16, 2018 2:03 pm, Ivan Mitev wrote:



In case you update the doc, you may add `systemctl enable fstrim.timer`
for setting a periodic job in the configuration section [1]. However:
- the timer is run daily, not weekly (fstrim runs very fast though,
shouldn't be an issue). - it might be specific to R4.0 - I don't remember
if util-linux provided the timer in R3.2


Looks like it works on R3.2 as well, but when I "systemctl status
fstrim.timer" it is titled:

fstrim.timer - Discard unused blocks once a week

Are you sure R4.0 is daily? I can't really check right now.


I'm sorry, it's weekly, I've looked at the wrong timer.

Also, `systemctl start fstrim.timer` will be required if one doesn't 
plan to reboot in the next days...


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0920b2a5-ddba-4104-a2b3-20b7dc5cb340%40maa.bz.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes 3.2 trim problem

2018-02-16 Thread 'awokd' via qubes-users
On Fri, February 16, 2018 3:13 pm, nunotmalhe...@gmail.com wrote:
> sexta-feira, 16 de Fevereiro de 2018 às 15:02:54 UTC, awokd escreveu:


>> dracut -f /boot/efi/EFI/qubes/initramfs-$(uname -r).img $(uname -r)
>>
>> works for a generic version at least. Will go with that unless there's
>> a better suggestion.
>
> Don't forget that the original doc had the host only option -H.

I am intentionally forgetting that. :) Per the man page:

"If you want to create lighter, smaller initramfs images, you may want to
specify the --hostonly or -H option. Using this option, the resulting
image will contain only those dracut modules, kernel modules and
filesystems, which are needed to boot this specific machine. This has the
drawback, that you can’t put the disk on another controller or machine,
and that you can’t switch to another root filesystem, without recreating
the initramfs image. The usage of the --hostonly option is only for
experts and you will have to keep the broken pieces. At least keep a copy
of a general purpose image (and corresponding kernel) as a fallback to
rescue your system."

For a generic recommendation, the tradeoffs don't seem worth saving a few
bytes. I figure if someone really needs those bytes they can add the -H
themselves.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/803f3d71f8718924e8efaa43c0366902.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes 3.2 trim problem

2018-02-16 Thread 'awokd' via qubes-users
On Fri, February 16, 2018 2:03 pm, Ivan Mitev wrote:


> In case you update the doc, you may add `systemctl enable fstrim.timer`
> for setting a periodic job in the configuration section [1]. However:
> - the timer is run daily, not weekly (fstrim runs very fast though,
> shouldn't be an issue). - it might be specific to R4.0 - I don't remember
> if util-linux provided the timer in R3.2

Looks like it works on R3.2 as well, but when I "systemctl status
fstrim.timer" it is titled:

fstrim.timer - Discard unused blocks once a week

Are you sure R4.0 is daily? I can't really check right now.


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/680dc6e9b5f4f1a6fdcf5a0a400c9636.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes 3.2 trim problem

2018-02-16 Thread nunotmalheiro
sexta-feira, 16 de Fevereiro de 2018 às 15:02:54 UTC, awokd escreveu:
> On Fri, February 16, 2018 2:49 pm, 'awokd' via qubes-users wrote:
> > On Fri, February 16, 2018 2:37 pm, nunotmalhe...@gmail.com wrote:
> >
> >> sexta-feira, 16 de Fevereiro de 2018 às 11:34:10 UTC, awokd escreveu:
> >>> On Fri, February 16, 2018 10:37 am, nunotmalhe...@gmail.com wrote:
> >>>
> >
> >>> 4) Please try this longer version of initramfs generation. I think
> >>> the short version is OK for GRUB boot but EFI might need the longer
> >>> one: sudo
> >>> /usr/bin/dracut -f
> >>> /boot/efi/EFI/qubes/initramfs-4.9.56-21.pvops.qubes.x86_64.img
> >>> 4.9.56-21.pvops.qubes.x86_64
> >>>
> 
> >
> > Anyone know if there is a shorter version of the above command that works
> >  for EFI without having to specify the kernel version numbers?
> 
> Looks like:
> 
> dracut -f /boot/efi/EFI/qubes/initramfs-$(uname -r).img $(uname -r)
> 
> works for a generic version at least. Will go with that unless there's a
> better suggestion.

Don't forget that the original doc had the host only option -H.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b1c73c10-0931-4e13-a559-91ad6e934746%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes 3.2 trim problem

2018-02-16 Thread 'awokd' via qubes-users
On Fri, February 16, 2018 2:49 pm, 'awokd' via qubes-users wrote:
> On Fri, February 16, 2018 2:37 pm, nunotmalhe...@gmail.com wrote:
>
>> sexta-feira, 16 de Fevereiro de 2018 às 11:34:10 UTC, awokd escreveu:
>>> On Fri, February 16, 2018 10:37 am, nunotmalhe...@gmail.com wrote:
>>>
>
>>> 4) Please try this longer version of initramfs generation. I think
>>> the short version is OK for GRUB boot but EFI might need the longer
>>> one: sudo
>>> /usr/bin/dracut -f
>>> /boot/efi/EFI/qubes/initramfs-4.9.56-21.pvops.qubes.x86_64.img
>>> 4.9.56-21.pvops.qubes.x86_64
>>>

>
> Anyone know if there is a shorter version of the above command that works
>  for EFI without having to specify the kernel version numbers?

Looks like:

dracut -f /boot/efi/EFI/qubes/initramfs-$(uname -r).img $(uname -r)

works for a generic version at least. Will go with that unless there's a
better suggestion.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6ce95ea1269a2854cddd87525b3baae6.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes 3.2 trim problem

2018-02-16 Thread 'awokd' via qubes-users
On Fri, February 16, 2018 2:37 pm, nunotmalhe...@gmail.com wrote:
> sexta-feira, 16 de Fevereiro de 2018 às 11:34:10 UTC, awokd escreveu:
>> On Fri, February 16, 2018 10:37 am, nunotmalhe...@gmail.com wrote:

>> 4) Please try this longer version of initramfs generation. I think the
>> short version is OK for GRUB boot but EFI might need the longer one: sudo
>> /usr/bin/dracut -f
>> /boot/efi/EFI/qubes/initramfs-4.9.56-21.pvops.qubes.x86_64.img
>> 4.9.56-21.pvops.qubes.x86_64
>>
>>
>> Let me know if that fixes it (or not) so I can update the doc.
>>
>
> Hi!
> It fixed my problem! I never thought it could be a problem with dracut's
> arguments. You should update the doc.
>
>
> Thanks for the quick response!!!

Thanks for being a guinea pig! :)

Will submit an update request (and include Ivan's suggestion too).

Anyone know if there is a shorter version of the above command that works
for EFI without having to specify the kernel version numbers?


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/016a552567d66cc6c3c3ad3cf37163c2.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes 3.2 trim problem

2018-02-16 Thread nunotmalheiro
sexta-feira, 16 de Fevereiro de 2018 às 11:34:10 UTC, awokd escreveu:
> On Fri, February 16, 2018 10:37 am, nunotmalhe...@gmail.com wrote:
> > Hi!
> > Followed the trim tutorial in https://www.qubes-os.org/doc/disk-trim/
> > My computer boots through efi, so I did:
> >
> >
> > 1) set issue_discards = 1 in /etc/lvm/lvm.conf
> > 2) added discard to the end of the luks entry in /etc/crypttab. Also tried
> > with allow-discards 3) Added rd.luks.options=discard to both ke dracut -H
> > -frnel entries on /boot/efi/EFI/qubes/xen.cfg. Also tried with
> > rd.luks.allow-discards 4) Rebuild initrd in hostonly mode with dracut -H
> > -f
> >
> >
> > rebooted the system with each try and every time, the response to
> > command:
> > sudo fstrim -v / fstrim: /: the discard operation is not supported
> >
> >
> > Is there anything wrong?
> 
> First of all, is / on an SSD or hard drive?
> Try doing a "cryptsetup status /dev/mapper/luks-UUID#". Look for "flags:
> discards".
> 
> 2) Should be just discard
> 3) Should be rd.luks.options=discard
> 4) Please try this longer version of initramfs generation. I think the
> short version is OK for GRUB boot but EFI might need the longer one:
> sudo /usr/bin/dracut -f
> /boot/efi/EFI/qubes/initramfs-4.9.56-21.pvops.qubes.x86_64.img
> 4.9.56-21.pvops.qubes.x86_64
> 
> Let me know if that fixes it (or not) so I can update the doc.

Hi!
It fixed my problem! I never thought it could be a problem with dracut's 
arguments.
You should update the doc.

Thanks for the quick response!!!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/02834b79-76f8-4f81-993a-1e036a3ab154%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes 3.2 trim problem

2018-02-16 Thread Ivan Mitev



On 02/16/2018 01:34 PM, 'awokd' via qubes-users wrote:

On Fri, February 16, 2018 10:37 am, nunotmalhe...@gmail.com wrote:

Hi!
Followed the trim tutorial in https://www.qubes-os.org/doc/disk-trim/
My computer boots through efi, so I did:


1) set issue_discards = 1 in /etc/lvm/lvm.conf
2) added discard to the end of the luks entry in /etc/crypttab. Also tried
with allow-discards 3) Added rd.luks.options=discard to both ke dracut -H
-frnel entries on /boot/efi/EFI/qubes/xen.cfg. Also tried with
rd.luks.allow-discards 4) Rebuild initrd in hostonly mode with dracut -H
-f


rebooted the system with each try and every time, the response to
command:
sudo fstrim -v / fstrim: /: the discard operation is not supported


Is there anything wrong?


First of all, is / on an SSD or hard drive?
Try doing a "cryptsetup status /dev/mapper/luks-UUID#". Look for "flags:
discards".

2) Should be just discard
3) Should be rd.luks.options=discard
4) Please try this longer version of initramfs generation. I think the
short version is OK for GRUB boot but EFI might need the longer one:
sudo /usr/bin/dracut -f
/boot/efi/EFI/qubes/initramfs-4.9.56-21.pvops.qubes.x86_64.img
4.9.56-21.pvops.qubes.x86_64

Let me know if that fixes it (or not) so I can update the doc.


In case you update the doc, you may add `systemctl enable fstrim.timer` 
for setting a periodic job in the configuration section [1].

However:
- the timer is run daily, not weekly (fstrim runs very fast though, 
shouldn't be an issue).
- it might be specific to R4.0 - I don't remember if util-linux provided 
the timer in R3.2


(FWIW the documentation's instructions worked for me on R4.0rc4, with 
grub boot).


Ivan

[1] https://www.qubes-os.org/doc/disk-trim/#configuration








--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/55fe5b8c-5b26-af84-3424-ec51535f53f3%40maa.bz.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes 3.2 trim problem

2018-02-16 Thread 'awokd' via qubes-users
On Fri, February 16, 2018 10:37 am, nunotmalhe...@gmail.com wrote:
> Hi!
> Followed the trim tutorial in https://www.qubes-os.org/doc/disk-trim/
> My computer boots through efi, so I did:
>
>
> 1) set issue_discards = 1 in /etc/lvm/lvm.conf
> 2) added discard to the end of the luks entry in /etc/crypttab. Also tried
> with allow-discards 3) Added rd.luks.options=discard to both ke dracut -H
> -frnel entries on /boot/efi/EFI/qubes/xen.cfg. Also tried with
> rd.luks.allow-discards 4) Rebuild initrd in hostonly mode with dracut -H
> -f
>
>
> rebooted the system with each try and every time, the response to
> command:
> sudo fstrim -v / fstrim: /: the discard operation is not supported
>
>
> Is there anything wrong?

First of all, is / on an SSD or hard drive?
Try doing a "cryptsetup status /dev/mapper/luks-UUID#". Look for "flags:
discards".

2) Should be just discard
3) Should be rd.luks.options=discard
4) Please try this longer version of initramfs generation. I think the
short version is OK for GRUB boot but EFI might need the longer one:
sudo /usr/bin/dracut -f
/boot/efi/EFI/qubes/initramfs-4.9.56-21.pvops.qubes.x86_64.img
4.9.56-21.pvops.qubes.x86_64

Let me know if that fixes it (or not) so I can update the doc.




-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/57d44bd8e25ae41b1db54fdef3c50b8a.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Qubes 3.2 trim problem

2018-02-16 Thread nunotmalheiro
Hi!
Followed the trim tutorial in https://www.qubes-os.org/doc/disk-trim/
My computer boots through efi, so I did:

1) set issue_discards = 1 in /etc/lvm/lvm.conf
2) added discard to the end of the luks entry in /etc/crypttab. Also tried with 
allow-discards
3) Added rd.luks.options=discard to both ke dracut -H -frnel entries on 
/boot/efi/EFI/qubes/xen.cfg. Also tried with rd.luks.allow-discards
4) Rebuild initrd in hostonly mode with dracut -H -f

rebooted the system with each try and every time, the response to command:
sudo fstrim -v /
fstrim: /: the discard operation is not supported

Is there anything wrong?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/0bf39f43-a628-4ff2-aed6-55e604a08db4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.