~Toughbooktalk~ Rob - 630-300-8877

The largest Toughbook discussion site on the net!
It is currently Sat Jul 21, 2018 3:35 am

All times are UTC-06:00




Post new topic  Reply to topic  [ 43 posts ]  Go to page Previous 1 2 3 4 5 Next
Author Message
PostPosted: Sun Apr 17, 2016 6:10 am 
Offline
User avatar

Joined: Sat Jun 07, 2014 7:39 am
Posts: 655
Location: Canada
Sorry, should have explained. But before doing this, check if there is a PnP OS option in the CF-31 BIOS and set it to NO. Much easier than mucking around with kernel parameters and it might work.

Otherwise, edit /etc/default/grub like the image in the previous post, insert it between the quotes of GRUB_CMDLINE_LINUX_DEFAULT
Code:
GRUB_CMDLINE_LINUX_DEFAULT="i8042.nopnp quiet splash"


Run a grub update then reboot.
Code:
sudo update-grub

_________________
CF-19 MK2 TOUCHSCREEN || CF-19 MK2 DIGITIZER || CF-30 MK3 "Jeff Edition" || CF-19 MK4


Top
   
PostPosted: Sun Apr 17, 2016 10:51 am 
Offline

Joined: Sun Nov 23, 2014 1:13 pm
Posts: 62
Yeah, this is the problem. Qubes has more paranoia built in than I do handling explosives. I cannot edit the actual grub.d file that forms the base for the grub.cfg file that is created/recreated every time the grub is updated (ie after updates to the OS).

Compounding this is the fact that the base, starting OS is actually the Xen Hypervisor. So none of the of opening settings information on the start up look ANYTHING like the usual grub kernel boot options. I'll try copy here in a little while what you actually see via either the "e" command at grub menu or by editing the grub.cfg in /boot/grub

I did figure out where to add the command but I can only edit grub.cfg. sudo does not work to access /etc/grub.d/ (the paranoia I mentioned above). I have not found documentation yet on editing that folder. There are, as I understand, CLI inputs to edit the requisite lines in grub from terminal but since I cannot access that directory with sudo, I hold little hope a CLI edit will succeed, never mind the fact that the hypervisor boot options look nothing like usual kernel options. Hell, even the entry itself was different. I simply added i8042.nopnp right at the end of the appropriate line.

I don't know if I mentioned it yet but event though the touchpad works, the touchpad options page in settings is still greyed out. I will try once w/o an USB mouse connected but I have the feeling the lack of PNP detection means touchpad settings will not function. Thankfully, the speed and performance are satisfactory.


Top
   
PostPosted: Sun Apr 17, 2016 11:37 am 
Offline

Joined: Sun Nov 23, 2014 1:13 pm
Posts: 62
Okay, here's the information from grub.cfg for you guys to see. FYI, if you are playing in Qubes to see how this is working, there is a CLI command to pass files from Dom0 to another VM. nano is your only editor it looks like under konsole, which is the one of the two terminal shells with sudo priviledges.

Below is the relevant section I had to edit. Above and below it are menu stuff and other menu line entries.

### BEGIN /etc/grub.d/20_linux_xen ###
menuentry 'Qubes, with Xen hypervisor' --class qubes --class gnu-linux --class gnu --class os --class xen $menuentry_id_option 'xen-gnulinux-simple-NUMBERSTRINGHEREREDACTED' {
insmod part_msdos
insmod ext2
set root='hd0,msdos1'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1' NUMBERSTRINGHEREREDACTED
else
search --no-floppy --fs-uuid --set=root NUMBERSTRINGHEREREDACTED
fi
echo 'Loading Xen 4.6.0 ...'
if [ "$grub_platform" = "pc" -o "$grub_platform" = "" ]; then
xen_rm_opts=
else
xen_rm_opts="no-real-mode edd=off"
fi
multiboot /xen-4.6.0.gz placeholder console=none dom0_mem=min:1024M dom0_mem=max:4096M ${xen_rm_opts}
echo 'Loading Linux 4.1.13-9.pvops.qubes.x86_64 ...'
module /vmlinuz-4.1.13-9.pvops.qubes.x86_64 placeholder root=/dev/mapper/qubes_dom0-root ro i915.preliminary_hw_support=1 rd.lvm.lv=qubes_dom0/root vconsole.font=latarcyrheb-sun16 rd.lvm.lv=qubes_dom0/swap rd.luks.uuid=luks-NUMBERSTRINGHEREREDACTED rhgb quiet i8042.nopnp
echo 'Loading initial ramdisk ...'
module /initramfs-4.1.13-9.pvops.qubes.x86_64.img
}


EDIT: While I have stuck the i8042 command on the vmlinuz line, I have not experimented with sticking it on the Xen hypervisor lines above. I figured the first VM line was probably where the detection happens. In actually, I have not idea and got lucky on the first shot. I dislike messing with success and so have not tried any other attempts. I do know, from earlier attempts at boot options, that anything below the last module line does not work.


Top
   
PostPosted: Sun Apr 17, 2016 2:32 pm 
Offline
User avatar

Joined: Sat Jun 07, 2014 7:39 am
Posts: 655
Location: Canada
Normally you shouldn't be messing with files in grub.d, you should be editing /etc/default/grub. If you can't sudo edit, then your /etc/sudoers file does not permit you to sudo everything, so ignore sudo and just use a root shell. Open a terminal, type "su" then your root password and you should be able to edit /etc/default/grub. I just noticed Qubes is Fedora based so after editing the file the command to issue is
Code:
grub2-mkconfig -o /boot/grub2/grub.cfg

_________________
CF-19 MK2 TOUCHSCREEN || CF-19 MK2 DIGITIZER || CF-30 MK3 "Jeff Edition" || CF-19 MK4


Top
   
PostPosted: Mon Apr 18, 2016 4:38 pm 
Offline

Joined: Sun Nov 23, 2014 1:13 pm
Posts: 62
No root account in the Dom0 VM. Looks like it is setup without root like Ubuntu but I will check further.

Qubes system and non-anon VMs are fedora. The whonix and tied anon VMs are debian.

Ordinarily, I would agree not to edit grub.d. But unless your change is made there, it is not permanent and will be wiped the next time grub.cfg is renewed by system updates. Thankfully, the Xen hypervisor should not see many changes.


Top
   
PostPosted: Wed Apr 20, 2016 9:00 am 
Offline
User avatar

Joined: Sat Jun 07, 2014 7:39 am
Posts: 655
Location: Canada
I'm sorry if I seem like I am repeating myself or if I was somehow unclear. This is the proper way of making grub changes permanent and no where do I mention directly editing grub.cfg

Edit file
Code:
/etc/default/grub

then run
Code:
grub2-mkconfig -o /boot/grub2/grub.cfg


All linux/unix systems have a root account. To enable root, issue this command to unlock the account
Code:
passwd -u root

and assign bash with
Code:
chsh -s /bin/bash root

root login is disabled mostly to discourage novice users from opening up root shells and wreaking havoc on their systems, forcing them to sudo everything. It also has the minor side effect of making it difficult to crack a root login from internet-facing services. As a server admin and linux desktop user, me not having a root login is like trying to drive a car from the passenger seat. Just be careful and you'll be fine.

_________________
CF-19 MK2 TOUCHSCREEN || CF-19 MK2 DIGITIZER || CF-30 MK3 "Jeff Edition" || CF-19 MK4


Top
   
PostPosted: Wed Apr 20, 2016 2:27 pm 
Offline

Joined: Sun Nov 23, 2014 1:13 pm
Posts: 62
I am not stating or implying anything about you giving instructions regarding grub.cfg. I am describing my work around because I couldn't access grub.d as some guide sets I had reviewed instructed to before you offered assistance.

At the time I posted my last response, I ran into the same permission denied when I went to execute your instructions but I did not try sudo in that instance as I got sidetracked on a separate line of inquiry; I thought I hit another lockout like grub.d and chased a second line of thought open in another browser window.

My last paragraph was simply a rehash of the guides I was reading. I wondered at how the system worked and where others were placing the command you list above (as it is not the first time I have run into it, only that either the location is unmentioned or people were editing a file in grub.d). As usual, texts ran mostly on the side of too little detail and file paths than too much, though the texts with too much manage to make the material obtuse to the point of frustration. What I learned from this is that, by in large, the world's education systems still have difficulty producing graduates who understand the fundamentals of producing good technical writing, specifically in composition and audience awareness.


http://www.qubes-os.org/doc/vm-sudo
This link explains why I have been confused with my observations on root, sudo, permissions, and the lack of log ins anywhere. I had not gotten to really dig in to the matter since Sunday or have a fresh try at your solution until now.

I have trialed the fix above using sudo and successfully wrote the the command into the grub file via nano. It seems to function as the grub.cfg edit did. No changes.

Given the information in the vm-sudo, I see no point in a root account at the moment.

I understand your analogy but it seems more than a bit off in its comparison.

Now to try track down the every once in a great while sudden reboot.


Top
   
PostPosted: Wed Apr 20, 2016 8:09 pm 
Offline
User avatar

Joined: Sat Jun 07, 2014 7:39 am
Posts: 655
Location: Canada
droppointalpha wrote:
I have trialed the fix above using sudo and successfully wrote the the command into the grub file via nano. It seems to function as the grub.cfg edit did. No changes.


Really? What does this return:
Code:
sudo cat /proc/cmdline


droppointalpha wrote:
I understand your analogy but it seems more than a bit off in its comparison.

Actually you've reinforced the analogy, but that's a discussion we might have on another day.

_________________
CF-19 MK2 TOUCHSCREEN || CF-19 MK2 DIGITIZER || CF-30 MK3 "Jeff Edition" || CF-19 MK4


Top
   
PostPosted: Wed Apr 20, 2016 10:51 pm 
Offline
User avatar

Joined: Thu Oct 14, 2010 1:13 pm
Posts: 2208
Location: TDR-HQ California
The problem with either the scary smart or scary experienced is the rest of us commoners need to sit on our hands.

Carry on gentleman. I love you both.

J'd

_________________
Fair for you/ Fair for me.
I chose to NOT be organized.

-------------------------------------------------------------------[/color]
http://toughbooktalk.com/
http://forum.notebookreview.com/panasonic/


Top
   
PostPosted: Thu Apr 21, 2016 8:10 am 
Offline

Joined: Sun Nov 23, 2014 1:13 pm
Posts: 62
kode-niner wrote:
Really? What does this return:
Code:
sudo cat /proc/cmdline


I'll check. But to re-iterate, since I think my statement may not have been wholly clear, the cmdline edit on /etc/grub/ works exactly the same as the grub.cfg edit (which is my expectation) and there it no difference in system performance. The touchpad settings tab, for instance, is still all greyed out but I would expect nothing different, as the edit of one file was simply the same edit made permanent for the other file.

kode-niner wrote:
droppointalpha wrote:
I understand your analogy but it seems more than a bit off in its comparison.

Actually you've reinforced the analogy, but that's a discussion we might have on another day.

Having a small fleet of vehicles, I'll ahead and say no. Root access is like having a computer hooked up to the ECM and making live changes to F/A mixtures and timing while you are driving. A guest account is a passenger driving and a normal user account with usual system privileges is a regular driver. One of these can't change the background/headlights, one can't change some fundamental system operations/engine timing, and one can screw the whole pooch very fast and cause the system/vehicle to crash via violent destruction of critical components.

And for the record, I am not a fan of working on cars.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 43 posts ]  Go to page Previous 1 2 3 4 5 Next

All times are UTC-06:00


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited