How to get forcepae to stick

[frankus333]

G'day folks

I have been able to get Kubuntu 14.04 to install and run on an old HP Compaq laptop with a pentium m processor without PAE using the forcepae addition to the command line in the live USB as per these links:

https://help.ubuntu.com/community/PAE

https://help.ubuntu.com/community/EnablingPAE

However, the pae flag does not stick in the file listing the attributes, and so any update of the kernal fails, unless the same code (below) is run for each update involving the kernal.

cat /proc/cpuinfo | sed 's/flags\t*:/& pae/' > /tmp/cpuinfo_pae
mount -o bind /tmp/cpuinfo_pae /proc/cpuinfo
mount -o remount,ro,bind /proc/cpuinfo
grep flags /proc/cpuinfo
# should output "flags : ... pae ..."

I found I had to prepend sudo to get the mount commands to work, and change cpuinfo_pae to cpuinfo-pae as well (somehow terminal doesn't seem to read the underscore correctly?)

Extract from Konsole while trying an update involving the kernal:

Errors were encountered while processing:
/var/cache/apt/archives/linux-image-3.13.0-30-generic_3.13.0-30.55_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

The above code is not necessary at all with an installation of LM17 KDE on the same machine. The pae flag is present in the cpuinfo file after initial installation using forcepae parameter, and remains in the cpuinfo file after reboot, and kernal updates work fine.

Is there any way to make the pae info stick in whatever way is necessary to allow the updates to proceed normally each time for Kubuntu? I have tried editing the cpuinfo file, but get messages saying it can't be changed. Maybe there is more required than simply editing this file? The manual for the mount command seems to suggest that the above code is designed so that the changes WON'T be permanent in the flags information. Not sure why, or why editing the /proc/cpuinfo file to have the pae flag in it permanently isn't the complete solution? How has LM managed to achieve this?

I note that the actual PAE function is not relevant to my situation with this machine, because it does not have enough RAM to take advantage of it anyway. My main intention is to be able to avail myself of the current supported distros/kernals for as long as I can on this old hardware. At this stage that will take me to at least 2019 with LM17/Kubuntu 14.04, unless the kernals become too complex for this old hardware to run for other reasons than PAE, and/or a simpler distro like XFCE or LXDE also no longer runs.

[kubicle]

One option would be to install the "fake-pae" package from this ppa: https://launchpad.net/~prof7bit/+arc...buntu/fake-pae.

As long as you have the package installed, it will patch cpuinfo (with similar bind mounting) to show the pae flag.

[frankus333]

Thanks kubicle

I wonder if that is how LM does it? I have my doubts, because I could not find that PPA added to the list of repos, nor any file with fake-pae in its title,in my LM17 installation. Also, the link does not show a release corresponding to Trusty at this stage.

The grub terminal script at boot has the forcepae in it for LM17, and adding this to the grub terminal script for Ku 14.04 sets the flag after bootup, but it does not hold after reboot. I guess I could use

sudo update-grub

to make it stick, but it would probably be lost at the next kernal update which updated grub, and so the following kernal update would not work.

I will enquire on the LM forum to see if anyone can/will tell me the trick they use.

[kubicle]

If using the "forcepae" kernel option works, you can edit /etc/default/grub to make it stick through reboots and kernel installations (remember to run 'sudo update-grub' after the edit)

In /etc/default/grub, change the lines:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash forcepae"
GRUB_CMDLINE_LINUX="forcepae"

However, I'm not sure how the forcepae option works, so I couldn't tell whether it allows new kernel installations to go through...The ubuntu kernel install scripts check for the pae cpu flag on installation/upgrade attempts an exits with an error if not found.

The fake-pae method will work as it makes the flag show, but like I said, I don't know about forcepae...so you can test it yourself.

[frankus333]

Thanks kubicle

I had lots of messages in the konsole about ownership problems while trying to update the /etc/default/grub file, but managed to get the forcepae into both places as suggested, and these are now also reflected in the /boot/grub/grub.cfg file as well. However, the initial grub boot script won't retain the forcepae attribute after reboot, so the cpu flag does not get set each time. I presume I have to also run:


sudo grub-install /dev/sda


after booting with an edited initial grub boot script, to get that change permanently into the initial boot script. I also presume that if this works it would be required for the recovery boot script as well, in a separate reboot, as it seems only one page of the initial boot scripts can be edited per boot.


Playing around with what I presume is the grub information in the MBR (possibly affecting the booting of the LM17 installation) is a step too far for me at this stage, until I can get some more definitive assurance that this is the way LM17 has in fact achieved the forcepae continuity.


I don't understand much about the complexity of grub in a multiboot situation, and am concerned that if they are all controlled by a single set of grub information in the MBR, that is updated by each installation that has its kernal updated, then updates via one kernal could mess up grub settings for another OS on the machine. Maybe it is not feasible to have two different installations requiring forcepae on the same machine?

[kubicle]

I had lots of messages in the konsole about ownership problems while trying to update the /etc/default/grub file

Like basically all files in /etc, you cannot edit them "as user", you need to elevate your privileges...for example "kdesudo kate /etc/default/grub"

sudo grub-install /dev/sda

This should not be necessary, unless you're actually using Linux Mint's grub (and grub settings to boot)...and not kubuntu's.

---

Then again, if things seem too complicated, you can just use the fake-pae method, it'll just work (you don't need forcepae option at boot if you use fake-pae)...the fake-pae will basically just install an init file to do the necessary bind mounting at boot to fake the pae flag in cpuinfo.

[frankus333]

Thanks kubicle

I would love to find a clear and simple explanation of the privileges/permissions/ownership issues in Linux. My searches thus far have only turned up articles written for sysadmins. I think my problem with backups (https://www.kubuntuforums.net/showth...-Kubuntu-14-04) is related to these issues, and has so far not been satisfactorily answered. I presume it is a tricky issue, and may not have a simple explanation (sigh).

I was aware of the need to edit system files with elevated privileges from some prior experience getting swap to work in previous encrypted installations, and had tried different combinations of invoking privileges and different editors, but none worked without error messages. Some even refused to bring up the editor, such as gksu gedit and sudo kate

I ended up using kdesudo kate, as shown:

frankadmin@frank-nx5000-Ku14-04:~$kdesudo kate /etc/default/grub &
[1] 2278
frankadmin@frank-nx5000-Ku14-04:~$Bus:Open: Can not get ibus-daemon's address.
IBusInputContext::createInputContext:no connection to ibus-daemon
QDBusConnection:session D-Bus connection created before QCoreApplication. Applicationmay misbehave.
QInotifyFileSystemWatcherEngine::addPaths:inotify_ add_watch failed: No such file or directory
QFileSystemWatcher:failed to add paths: /root/.config/ibus/bus
Bus:Open: Can notget ibus-daemon's address.
IBusInputContext::createInputContext:no connection to ibus-daemon

I edited file by adding forcepae to last command line, and saved and closed Kate.

[1]+ Done kdesudo kate /etc/default/grub

Then I updated grub (apparently successfully).


The error messages with the other prior attempts (and some of the following attempts with kdesudo kate) had even longer error messages and warnings about things probably going to misbehave. As long as the editor actually came up, I proceeded.

Regarding the grub used for booting; I suspect the machine actually is using the LM17 boot grub, as that was the last installation added. Maybe that means I need to edit the grub.cfg file in LM17, to add forcepae to all the Ku 14.04 entries it has, and then run grub install again there?

Sounds like the liklihood of a multiboot forced pae installation remaining stable through kernal updates is increasingly remote.

Do you know if the fake-pae will work in Ku 14.04 even if that flavour hasn't been added as yet?

[kubicle]

My searches thus far have only turned up articles written for sysadmins

You are one

I was aware of the need to edit system files with elevated privileges from some prior experience getting swap to work in previous encrypted installations, and had tried different combinations of invoking privileges and different editors, but none worked without error messages. Some even refused to bring up the editor, such as gksu gedit and sudo kate

1. gksu and gedit are not installed on kubuntu by default, they are gnome "equivalents" of kdesudo and kate (respectively).
2. don't use sudo with GUI applications, use kdesudo instead (as sudo runs a mixed environment that retains some of user environment variables, which can lead to problems...if you must use sudo with GUI applications, use options such as -i that switches all environment variables to the target user...but using kdesudo with GUI applications is usually simpler rule of thumb to remember)

I ended up using kdesudo kate, as shown:

frankadmin@frank-nx5000-Ku14-04:~$kdesudo kate /etc/default/grub &
[1] 2278
frankadmin@frank-nx5000-Ku14-04:~$Bus:Open: Can not get ibus-daemon's address.
IBusInputContext::createInputContext:no connection to ibus-daemon
QDBusConnection:session D-Bus connection created before QCoreApplication. Applicationmay misbehave.
QInotifyFileSystemWatcherEngine::addPaths:inotify_ add_watch failed: No such file or directory
QFileSystemWatcher:failed to add paths: /root/.config/ibus/bus
Bus:Open: Can notget ibus-daemon's address.
IBusInputContext::createInputContext:no connection to ibus-daemon

Looks like "normal" debug output to me, rather than errors.
A good rule of thumb is that if the application starts and works, it's usually safe to ignore the debug messages.

Regarding the grub used for booting; I suspect the machine actually is using the LM17 boot grub, as that was the last installation added. Maybe that means I need to edit the grub.cfg file in LM17, to add forcepae to all the Ku 14.04 entries it has, and then run grub install again there?

It's often preferable to only have one of your installled distributions install and control grub (as grub can boot other distros as well), to avoid confusion on which installation controls grub and it's config/boot options. You could take a look at your Mint installation, and do the same modifications there (add forcepae to /etc/default/grub, run update-grub)

Do you know if the fake-pae will work in Ku 14.04 even if that flavour hasn't been added as yet?

I see no reason why not, I doubt there is anything release specific in there.

[frankus333]

Bingo! we have arrived at the solution.

The LM17 /etc/default/grub already has the forcepae in it (in the last line only; not in the default line with "quiet splash". Any particlar reason you suggested putting it in both lines? It appears twice in the initial grub scripts now.)

Updating grub in LM17 without making any changes caused it to pick up the changes in the Ku 1404 grub files, and so now the forcepae appears (twice) in the scripts for all the Ku 1404 kernals listed in the initial booting grub screens. All kernals of Ku 1404 now boot up with the PAE flag set correctly.

To confirm it held up after Ku 1404 kernal update, I booted into Ku 1404 again, confirmed it came up with the PAE flag set correctly, and selected the updates (long list) and let them run in tty1. All completed without errors. The latest kernal has been installed, and the PAE flag remains set for the main kernal, and the oldest recovery options kernal, when each is booted (didn't check the middle two kernals in the recovery list, but they have the parameter listed in the recovery initial grub script page, so should also be fine.) The Ku 1404 is now the first listed OS, as its grub now controls the machine. LM17 still boots up with the PAE flag set as normal.

The next test will be when I run the offered grub updates in LM17. I expect it will take back the initial grub control, but the changes now made to Ku 1404 should stick, and be written back into the initial grub script that LM17 re-writes; here's hoping.

If that proves to be the case, I see no need for the fake-pae modification.

Many thanks for your interest, kubicle. I much appreciate the help in climbing a little further up the learning curve.

[kubicle]

The LM17 /etc/default/grub already has the forcepae in it (in the last line only; not in the default line with "quiet splash". Any particlar reason you suggested putting it in both lines? It appears twice in the initial grub scripts now.)

Hmm...I was working on memory, and recalled GRUB_CMDLINE_LINUX_DEFAULT affected normal boot entries, and GRUB_CMDLINE_LINUX affected only recovery boot entries, but didn't check... so it's entirely possible GRUB_CMDLINE_LINUX affects all boot entries, in which case adding it only there would suffice.

[frankus333]

Thanks kubicle

For the sake of simplicity and "elegance" I removed forcepae from the _DEFAULT line, and everything now looks like the lines in LM17 scripts. All kernal versions now look similar and boot normally, with flag set.

Also, accepted grub updates for the LM17 installation, they completed normally, and LM17 has control of machine booting again. However, all Ku 14.04 kernals still boot with pae flag still correctly set.

Early in this exercise I installed kernals specifically marked as -pae (linux-generic-pae linux-headers-generic-pae) as suggested in the second link. They don't seem to appear in the boot advanced/recovery options, but did show up in kernals to be upgraded (listed as linux-generic-pae linux-headers-generic-pae and also linux-image-generic-pae). Also just for the sake of elegance (and avoiding unnecessary upgrades) I may try to remove them at some stage, and hope I don't break something.

I am happy to mark this thread as solved for now. Many thanks again for your supportive and stimulating input; I've learned a lot of useful stuff.

Cheers

[kubicle]

Early in this exercise I installed kernals specifically marked as -pae (linux-generic-pae linux-headers-generic-pae) as suggested in the second link. They don't seem to appear in the boot advanced/recovery options, but did show up in kernals to be upgraded (listed as linux-generic-pae linux-headers-generic-pae and also linux-image-generic-pae). Also just for the sake of elegance (and avoiding unnecessary upgrades) I may try to remove them at some stage, and hope I don't break something.

The *-pae kernel packages are just transitional metapackages, so that older installations (from the time when there were both pae and "nonpae" kernels available in the repos) will smoothly upgrade to the current kernel packages (which are pae only)

IOW, The *-pae kernel packages can be safely removed in trusty (they are just empty packages that depend on the "generic" kernel packages to make sure those get installed if one previously had pae kernels installed )

[frankus333]

Thanks kubicle

All three *-pae packages removed successfully, and all systems still go!

Cheers