On Mon, Oct 02, 2017 at 02:18:00PM +0000, Patrick Schleizer wrote: > Yethal: > > W dniu środa, 27 września 2017 14:08:56 UTC+2 użytkownik Patrick Schleizer > > napisał: > >> cooloutac: > >>> On Sunday, September 24, 2017 at 12:23:39 PM UTC-4, cooloutac wrote: > >>>> On Sunday, September 24, 2017 at 12:23:23 PM UTC-4, cooloutac wrote: > >>>>> On Sunday, September 24, 2017 at 9:25:24 AM UTC-4, Patrick Schleizer > >>>>> wrote: > >>>>>> Quote from https://www.qubes-os.org/doc/usb/ > >>>>>> > >>>>>>> Caution: By assigning a USB controller to a USB qube, it will no > >>>>>> longer be available to dom0. This can make your system unusable if, for > >>>>>> example, you have only one USB controller, and you are running Qubes > >>>>>> off > >>>>>> of a USB drive. > >>>>>> > >>>>>> How can one recover from such a situation if there is no PS2 > >>>>>> keyboard/mice available? > >>>>>> > >>>>>> I guess... Unless there is a better way...? Boot the system using from > >>>>>> an external disk using a USB recovery operating system... Then modify > >>>>>> the local disk (with broken Qubes)... Then do what? > >>>>>> > >>>>>> Cheers, > >>>>>> Patrick > >>>>> > >>>>> ya that. exactly. > >>>> > >>>> that would be the only way I would know of. > >>> > >>> sorry i misunderstood. you could use the qubes keyboard proxy. or > >>> unhide it from dom0. think they are both explained in the docs there, > >>> but don't think either are recommended but if you have no choice. > >>> > >> > >> The Qubes documentation explains how to hide/unhide it with the gui. But > >> when the disk is not booted (for recovery booted from USB), the gui > >> cannot be used since it refers to the USB booted and not internal disk > >> supposed to be recovered. > >> > >> To undo it some file on the internal disk needs to be modified. Which > >> files needs what modification? > > > > Remove rd.qubeshideallusb parameter from grub and then rebuild grub > > > > That requires to chroot into the mounted disk system? > > Isn't it difficult to run grub from a chrooted disk without messing up > bootloader of the disk that was booted or messing up which devices grub > is referring to? > > > Remove rd.qubeshideallusb parameter from grub [...] > > If that's all... Then why not just do this during normal system boot at > grub? > > Even if it's not hidden all the time from dom0... Won't the > keyboard/mice USB controller be quickly assigned to sys-usb, detached > from dom0 and still leave an unbootable system? > > As I understand the documentation rd.qubeshideallusb is "only" for > improved security. One can render its system unusable even without using > rd.qubeshideallusb. >
You should be able to fix this in grub: something like this - Interrupt the boot process and change the parameters to remove rd.qubeshideallusb, and add rd.break=cleanup. You'll be prompted to decrypt disks and then drop to shell. The root filesystem will be mounted ro at /sysroot. umount /sysroot. Mount it rw somewhere else (e.g /mnt - you'll have to create that) cd /mnt/var/lib/qubes/servicevms mv sys-usb sys-usb.bak umount /mnt Remount /dev/mapper/blah on /sysroot exit from the rescue shell The system should then continue to boot - sys-usb wont be able to start and so cant claim the usb devices - as you changed the boot parameters they'll be available in dom0. I don't currently have a USB keyboard with me so cant check this. Let me know if it works. It should. unman -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20171002212542.bcut2vbb6od5qkay%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
