ISO image is dual-isohybrid, you can burn it to CD/DVD or "dd" it to flash drive (note: the content of the flash drive will be decimated, so use one that you don't mind erasing):

Code:

dd if=fatdog-uefi.iso of=/dev/<your-flash-drive> bs=4M

Note: Make sure /dev/<your-flash-drive> points to your flash drive, because if it it points to your harddrive you can kiss all your data goodbye beyond the point of recovery. If you are not sure simply don't use "dd".

Booting on Secure Boot machines: you will be asked to load a certificate. Find fatdog64.cer under <keys> directory, and load it. Do not use any of the MS or Canonical certificates, they are there for test purposes.

Note: This is a test-build. Use it at your own risk. Expect bugs. Don't complain if it doesn't work, just report it. Same devx as 610/611 except that kernel module compiling won't work (different kernel), so no proprietary graphics driver for the time being. This isn't a replacement for 610/611. If 610/611 works for you, stick to that. This is a test build, it is not an alpha or beta release of Fatdog (though future Fatdog will be based on this work). It will not be maintained. Bugs for 610/611 should continue be reported under 610/611 thread http://murga-linux.com/puppy/viewtopic.php?t=82611, only bugs related to UEFI environment should be reported here.

The first is: It booted correctly under UEFI secure boot on my Compaq CQ58.

I had to enter the setup menu and select F9 boot device. The CDROM was shown and selecting it started the process.

I used Mokmanager to register the keys. Yes, Mokmanager is a bit difficult to use. I ended up registering both the FatDog key and other linux key. The problem is there is no feedback to the user if the key was registered correctly. After registering the key, one needs to select "continue boot" entry to continue.

I also use the UEFI shell, I found it was "white listed" (i.e. no key required). I just checked to see if it would work from the "boot from file" menu entry. I was also able to start it from the FatDog64 Boot Graphic.

I was not able to start FatDog64. The CDROM was spinning, but no light showing data transfers. After five minutes, I powered down the system. I will tried again,

I was able to reboot to Windows 8. It did take longer to boot to Windows 8.

So the iso works with UEFI. Thanks again for the effort. Happy New, I am sure I will have FatDog64 up and running soon._________________Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

Yes, the problem was me, too impatient. Once the keys for shim are set up, it takes about 2 minutes (with my CD) for the Fatdog64 console to appear after the Boot Graphic. The complete x-windows is up in about another one minute. My CDROM drive light was out for the entire process.

I did find one tip. At the first use, select the Grub (rEFInd) menu entry for start up with no save file. Fatdog64 starts a little faster because it does not look for the save file, especially since there are none. At the end of the session, save it in default configuration save file to the third main disk partition, Windows 8 normal. The next time, you are good to go.

Here is some information on how Windows 8 partitions the hard disk. The first partition is a primary NTFS one with WindowsRT (run time for normal complete installation, no recovery CDROM). The second partition is a primary VFAT with EFI programs. It appears one needs to use Windows 8 to modify. I tried to insert the UEFI shell into it. The UEFI BIOS refused to run it. The third partition is an extended logical partition for Windows 8 use. The fourth partition is an extended logical partition label Recovery with Windows 8recovery information.

It appears the normal Frugal installation with a save file is the easiest method of getting Puppy to be resident with Windows 8.

It is a Happy New Year._________________Enjoy life, Just Greg
Live Well, Laugh Often, Love MuchLast edited by JustGreg on Wed 02 Jan 2013, 09:26; edited 1 time in total

To modify the boot sequence, try "efibootmgr" after you are inside Fatdog. Its use is a bit cryptic, so you need to read up a bit. I haven't tested it so be careful, I can't offer any advice on how to recover if things go south.

Shell cannot be started directly from UEFI firmware because it is not signed by MS key (it is signed by fatdog key). You can only start it from refind.

Thanks for the information on the partition layout. It will be interesting to see other systems have similar layout.

I will leave the details of frugal install to kirk, which is more knowledgeable than me in that matter.

I will have to do some research on efibootmgr before using. It appears mokmanager only inserts keys and does not "manage" (add, remove view) keys. It is not clear how one does that. The keys must be store in the BIOS somehow and one should be able to control them. In working this, I get the feeling that the companies do not want the user to do anything that changes their "product". I think hardware modifications will more difficult in the future.

Yes, on the UEFI shell, there is no key. I have a question into HP Support on how to add the UEFI shell. Hopefully, I will get a reply on it. If one knows have to add the UEFI shell, then the process for adding an UEFI program will be very similar.

The booting of the hard disk is in complete control of Microsoft bootmgr.efi. I do not have any ideas on how to start another bootstrap loader with it. A CDROM start seems to be the easiest now.

If I find any additional information, then I will post it. Thanks again for your efforts._________________Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

Two post previously, I found that the last two partitions on my Windows 8 hard disk were logical and not primary. I did an inspection with GParted of the Windows 8 hard disk. It is nice to be able to see with Fatdog64 what Microsoft wants hidden.

There are five (5) partitions. The third partition (128 Megabytes in size) is not recognized by GParted. It has a flag, msftres, set. This partition is a "special" Microsoft partition. From the available web information (search on msftres), do not change the flag. It will cause problems with Windows 8 and its recovery process. One site for Windows 7 indicated that Windows 7 does not handled the new GPT approach and this partition is a fix up. One should not use the Linux hard disk tools, which handle GPT according to specifications, on the Windows hard disk.

At this time, with a Windows 8 hard disk, it seems best to run with the CDROM and a save file.

I hope the above helps._________________Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

has a good description on how the UEFI boot strap process works. If you have an interest in this, then it is worth reading. I hope this helps._________________Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

I've been testing on my daughter's new laptop that has Windows 8. Originally I had disabled secure boot and installed ReFind on the ESP (efi system partition). To do this, after installing to the ESP (with a kernel compiled as a UEFI application), I went into the UEFI setup and pointed it to Refind for booting. After James got shim/Mokmanager going I re-enabled secure boot and added the Fatdog64 keys so I could boot with secure boot enabled. I've also removed the Fatdog64 keys and installed the ISO posted here to a usb flash drive. With secure boot enabled, I booted from the usb drive. Mokmanager popped up and I added the Fatdog64 key and then Refind launched and then Grub2, and then Fatdog64 booted. So that worked well.

A few things to note if you're going to try a frugal install:

* Backup your ESP, if you loose it you'll hate your self .

* Disable fast boot in Windows 8. Fast boot is really just hibernation. To disable it open a terminal in Windows 8 and type powercfg -h off . The reason for this is that Windows mounts the ESP and when it hibernates it doesn't sync or unmount it. So if you boot another OS, shutdown, and then un-hibernate Windows the ESP's VFAT filesystem becomes corrupted.

The USB booting that we have now works well for me with secure boot enabled. The Mokmanager is not user friendly though. Hopefully the Linux Foundation will get their tool signed soon, it sounds much easier to use.

Do to the differences in UEFI implementations and the problem with Windows 8 nuking the ESP, we're very hesitant to support frugal installs. It's certainly doable, I've done it., but not real easy. I guess we're still pretty early in UEFI/Secure boot deployment, so hopefully things will get better soon.

It is a good idea to read it before using the Shell. For example, the dmpstore command will also list the available variables' information.

With Windows 8 to use the powercfg -h off command, one needs to have administrator privileges (aka root). To get the administrator command terminal, one has to hold down simultaneously the "Windows" and "X" keys. After a second or two, a menu pops up with entry "Command Prompt (Admin)". One clicks with the mouse on that entry to get the correct console terminal. You also have to agree to let the program modify Windows. The command will work.

Another way to shutdown (power off) Windows 8 without hibernation, is to click on the "normal"shutdown entry in the power control while holding down the "shift" key. It appears the restart Windows does not unmount the ESP. The best way is to power down without hibernation to ensure proper operation. Windows does this to reduce the start up time, which is still long.

I hope the above helps and hopefully, the Linux Foundation tool will arrive soon._________________Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

I had success with making a USB flash drive that will boot under the UEFI BIOS. I am posting this in case anyone else wishes to experiment. The USB device is faster than a CDROM.

I first tried the posted method of making an USB boot flash drive (i.e. dd the iso to the drive). It does work. I am familiar that this "screws up" the drive partition information. I tried it with an older 256 Megabyte flash drive. The drive worked fine. I did use both parted and gparted to see what happen to the partition information. Both reported the drive was marked as a GUID Partition Table device, but, no GPT data. This triggered my mind.

In researching UEFI, I found a description on Sabayon Wiki UEFI Boot page on "preparing a USB stick". The page had this as obsolete since Sabayon handles UEFI now. I tried it and the process does work. The USB flash drive has a normal partition table and could be used to have additional files (sfs, etc) on it. However, the USB flash drive is only good for a UEFI BIOS. It does not support the legacy BIOS boot process.

WARNING, WARNING, PLEASE DO NOT TRY THIS ON A HARD DRIVE! THIS IS FOR USB DRIVES ONLY WITH A SINGLE PARTITION.

The manual process uses both gparted and the console terminal:
1. Place the flash drive in an USB port and note the device name (e.g. sdb for this write up).
2. Start gparted (under the system menu devices) and select the device (sdb).
3. One needs to create a new partition table, which makes any data on the device unrecoverable. So, you need to make sure you have the correct device. In doing this to your primary hard drive, you will not make your day. Under the device menu, one selects create partition table. A second screen will pop up. You need to click the advance button to get a list of the table types. Select “gpt”. The screen with the types will close. Click on ‘OK” to create the new partition table.
4. Gparted will show that no partitions exist and all space is unallocated. Click on the unallocated space to select it. Under the “Partition” menu select create new entry. A screen will pop up with the options. The default should be the entire available space. Select partition type to VFAT 32. Click “OK” Gparted main screen will show the pending operation. Click on the apply button to create the partition.
5. Select the new created partition. Under the “Partition” menu, select the “Manage Flags” entry. On the pop up screen one clicks on the box (to mark it) for the boot flag. Click on the OK button, and gparted will up update the table to show the boot flag, which means the partition is a boot partition.
6. The device is now ready for Fatdog64. Exit from gparted and remove the drive. Re-insert it to ensure the system updates to the new USB flash drive configuration.
7. One needs to copy various Fatdog64 files to the device. I had made a CDROM from the ISO and use it as the source. One can also mount the ISO and copy the files from it. These files are needed to be copy to \ directory of the device: fatdog.jpg, grub.cfg, grubfont.pf2, initrd, vesamenu.c32, vmlinuz, and the directory help.
8. One needs to copy the file efiboot.img to a directory of the system being used (not on the USB flash device). I have the directory /root/test for such duties.
9. The file efiboot.img needs to be mounted in order to extract the need files. The file needs to be mounted to a directory on the system being used. I have made /mnt/test on my Puppies for this type of work. In a console terminal, one mounts the efiboot.img file with the command:
mount –t vfat /root/test/efiboot.img /mnt/test
10. From the directory /mnt/test, one needs to copy to the USB flash drive / directory these; directories drivers, EFI, keys and shellx64.efi file. The only certificate you in the keys directory is fatdog64.cer. You can delete the other two.
11. Now to unmount everything, for the efiboot.img, use umount /mnt/test in a console terminal. All the other devices (USB flash drive, CDROM or ISO) can be unmounted using the normal tools.
12. Your USB flash drive can be tested and should boot with an UEFI BIOS. You may have to use the Boot Device selection menu for the BIOS to ensure the USB flash drive device is booted before the hard drive. The postings both this one provide information on using mokmanager to install the fatdog64.cer key into the UEFI BIOS.

WARNING, WARNING, PLEASE DO NOT TRY THIS ON A HARD DRIVE! THIS IS FOR USB DRIVES ONLY WITH A SINGLE PARTITION.

If you create a save file on the device and it is not found then one has to edit the grub.cfg file and add waitdev=5 to the menuentry “Start Fatdog” line with linux /vmlinuz. This allows time for initialization of the USB devices.

The above method does work and makes good use of the larger available USB flash drives. I have done this to a 2 Gigabyte drive. The drive allows to use Fatdog64 when I get tired of using Windows 8. Please remember that Fatdog64 UEFI is a test version and still has kinks to be worked out. But, this is a good way of experimenting with UEFI BIOS equipment.

WARNING, WARNING, PLEASE DO NOT TRY THIS ON A HARD DRIVE! THIS IS FOR USB DRIVES ONLY WITH A SINGLE PARTITION._________________Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

Additionally, a small USB image is available at the same site for testing. I will try it out and report on the results here. I hope this helps._________________Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

I dd (copy) the image to a 256 Megabyte Flash Drive. I quickly found the very tiny MSDOS FAT32 partition did not allow anything else to be added. I just copied the the directories and files on the USB Flash drive to my hard drive. I deleted the old tiny partition and created a new gpt partition using the entire USB device. I then copied the original files from the hard drive to the USB flash drive. One can also use the mount procedure (step 9 in the post above) for the usb image to extract the needed files. Upon trying the USB flash drive with an UEFI BIOS, it booted up correctly and the menu only gave the UEFI shell, and loader. Selecting loader only restarts itself. After 10 seconds, the loader does start the UEFI shell as default.

I did copy the needed files from the test Fatdog64 to the USB flash device. I did find that in the directory loader, I had to add an entry to loader.conf for fatdog. One then has to create in the /loader/entries directory a new conf file named fatdog.conf. My content of fatdog.conf is:

Code:

title ReFInd Fatdog64
linux /EFI/BOOT/shim.efi

The first line is displayed menu entry text. The second line is the efi program to be executed The file shim.efi is called bootx64.efi (mjg59's shim.efi) in the fatdog64 test distribution.

In general the tools provided by Linux Foundation are more refined and easier to use. Once again, this stuff is still being developed, so there are some "sharp edges". Be careful, if you decide to experiment.

If a signed copy of Grub2 was available with a hash value for the MOK, then one could just use Grub2 to boot any UEFI compatible kernel . I have tried directly to start the fatdog64 grub2.efi using the UEFI shell, but, it fails the security check.

I have one problem with Grub2. Once Grub2 starts, it always uses the grub.conf file on the hard drive and not the USB drive. I have to do more research on this one. But, it does work.

I have found that UEFI shell is a small operating system with a nice features like an editor and hexeditor.

I hope this helps._________________Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

The problem I see is that LF's preloader does *not* accept signed binaries; while shim *requires* signed binaries; so just replacing bootx64.efi with preloader.efi and renaming grubx64.efi to loader.efi won't work. One needs to remove the signatures on grubx64.efi (in addition to renaming it to loader.efi) for it to work. So it is rather mutually exclusive at the moment._________________Fatdog64, Slacko and Puppeee user. Puppy user since 2.13.
Contributed Fatdog64 packages thread.

Yes, I agree with your on the signed binaries. At this time in MHO, I would continue with shim/rEFIND for fatdog64. There seems to be no advantage with the Linux Foundation "pre-loader"._________________Enjoy life, Just Greg
Live Well, Laugh Often, Love Much

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum