Linux Mint on the CF-31

Due to overwhelming demand, we have created a forum just dedicated to Toughbook users who use Linux!
Message
Author
User avatar
kode-niner
Posts: 700
Joined: Sat Jun 07, 2014 7:39 am
Location: Canada

Re: Linux Mint on the CF-31

#31 Post by kode-niner »

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: Select all

GRUB_CMDLINE_LINUX_DEFAULT="i8042.nopnp quiet splash"
Run a grub update then reboot.

Code: Select all

sudo update-grub
Daily drives a CF-31

droppointalpha
Posts: 63
Joined: Sun Nov 23, 2014 1:13 pm

Re: Linux Mint on the CF-31

#32 Post by droppointalpha »

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.

droppointalpha
Posts: 63
Joined: Sun Nov 23, 2014 1:13 pm

Re: Linux Mint on the CF-31

#33 Post by droppointalpha »

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.

User avatar
kode-niner
Posts: 700
Joined: Sat Jun 07, 2014 7:39 am
Location: Canada

Re: Linux Mint on the CF-31

#34 Post by kode-niner »

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: Select all

grub2-mkconfig -o /boot/grub2/grub.cfg
Daily drives a CF-31

droppointalpha
Posts: 63
Joined: Sun Nov 23, 2014 1:13 pm

Re: Linux Mint on the CF-31

#35 Post by droppointalpha »

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.

User avatar
kode-niner
Posts: 700
Joined: Sat Jun 07, 2014 7:39 am
Location: Canada

Re: Linux Mint on the CF-31

#36 Post by kode-niner »

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: Select all

/etc/default/grub
then run

Code: Select all

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: Select all

passwd -u root
and assign bash with

Code: Select all

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.
Daily drives a CF-31

droppointalpha
Posts: 63
Joined: Sun Nov 23, 2014 1:13 pm

Re: Linux Mint on the CF-31

#37 Post by droppointalpha »

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.

User avatar
kode-niner
Posts: 700
Joined: Sat Jun 07, 2014 7:39 am
Location: Canada

Re: Linux Mint on the CF-31

#38 Post by kode-niner »

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: Select all

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.
Daily drives a CF-31

User avatar
SHEEPMAN!
Posts: 2239
Joined: Thu Oct 14, 2010 1:13 pm
Location: TDR-HQ California

Re: Linux Mint on the CF-31

#39 Post by SHEEPMAN! »

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/

droppointalpha
Posts: 63
Joined: Sun Nov 23, 2014 1:13 pm

Re: Linux Mint on the CF-31

#40 Post by droppointalpha »

kode-niner wrote: Really? What does this return:

Code: Select all

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.

Post Reply

Return to “The LINUX forum!!!”