Jump to content
MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. ×


  • Posts

  • Joined

  • Last visited

  • Donations

  • Country


Everything posted by alacran

  1. @JFX Thanks, already quoted there your last post. alacran
  2. @JFX From: http://reboot.pro/index.php?showtopic=22473#entry219717 Hope this can be useful. alacran
  3. Thanks, allready fixed the post. Yes, I'm aware Porteus entries are included in your programs, I tested first Porteus, it boots fine, but tested on 2 PCs and the sound do not work on both of them. Slacko64-7.0 sound works fine. EDIT: Porteus sound is working fine, but the program do not include any sound file to tets the sound, then from it comes my idea it was not working fine, just tested on Yutube and all is fine. By the way I usually have found sound issues on many distros, only Ubuntu and Linux-Mint Cinnamon (not the other Mint flavors) worked fine here, In fact your entries for Linux-Mint ISO are working very fine, but I'm looking for something smaller, about 1 GB total size including a 512 MB persistence file. I'm testing now Puppy Linux Fossapup64 v9.5 (409 MB, released on Sept/2020, based on Ubuntu), entries on menus are same as on Slacko64-7.0, but using Fossapup64 folder. So far all seems to work fine, it looks even faster than Slacko64-7.0 and more complete, this distro has an small program not included on Slacko64-7.0, (and no name available, to try to install it on other distros) that let rebuild the ISO keeping all the user settings and modifications (packages added and deleted), I want to change the browser for FireFox, I have done this before on other older flavor versions of Puppy, but haven't tested it on this distro yet. alacran
  4. Thanks for your new versions. I will download and test them ASAP. I improved a little the menus from my previous post to load Slacko64-7.0 from Slacko64 folder located on the root of U-BOOT or U_NTFS partitions. For a folder (Slacko64) on the root of U-BOOT or U-NTFS partition on USB device Default KBD is en-US but can be changed on first boot; pkeys=es is a sample to set my Spanish KBD, delete it if unneeded. MBR grub4dos iftitle [if exist (hd0,0)/Slacko64/puppy_slacko64_7.0.sfs] Puppy Linux Slacko64 - (hd0,0)/Slacko64 kernel /Slacko64/vmlinuz pmedia=usbflash pdrv=U-BOOT psubdir=/Slacko64 pkeys=es pfix=fsck,fsckp initrd /Slacko64/initrd.gz iftitle [if exist (hd0,1)/Slacko64/puppy_slacko64_7.0.sfs] Puppy Linux Slacko64-7.0 - (hd0,1)/Slacko64 root (hd0,1) kernel /Slacko64/vmlinuz pmedia=usbflash pdrv=U-NTFS psubdir=/Slacko64 pkeys=es pfix=fsck,fsckp initrd /Slacko64/initrd.gz UEFI Grub 2 if [ "${grub_platform}" == "efi" ]; then if [ -e "(hd0,msdos1)/Slacko64/puppy_slacko64_7.0.sfs" ]; then menuentry "Puppy Linux Slacko64 7.0 - (hd0,msdos1)/Slacko64/puppy_slacko64_7.0.sfs" { echo "Loading vmlinuz" linux /Slacko64/vmlinuz pmedia=usbflash pdrv=U-BOOT psubdir=/Slacko64 pkeys=es pfix=fsck,fsckp echo "Loading initrd.gz" initrd /Slacko64/initrd.gz } fi if [ -e "(hd0,msdos2)/Slacko64/puppy_slacko64_7.0.sfs" ]; then menuentry "Puppy Linux Slacko64 7.0 - (hd0,msdos2)/Slacko64/puppy_slacko64_7.0.sfs" { echo "Loading vmlinuz" linux (hd0,msdos2)/Slacko64/vmlinuz pmedia=usbflash pdrv=U-NTFS psubdir=/Slacko64 pkeys=es pfix=fsck,fsckp echo "Loading initrd.gz" initrd (hd0,msdos2)/Slacko64/initrd.gz } fi fi By the way reboot.pro is ofline again, do you have some info of the issue? alacran
  5. JFYI I was able to run Puppy Linux slacko64-7.0 from a folder on the root of U-BOOT partition. Procedure: Create Slacko64-7.0 folder on the root of U-BOOT partition. Download the ISO and extract to that folder, as a bare minimum only following files are required: fdrv_slacko64_7.0.sfs, initrd.gz, puppy_slacko64_7.0.sfs, vmlinuz and zdrv_slacko64_7.0.sfs (332 MB in total). This are the menu entries I used: For a folder (Slacko64-7.0) on the root of U-BOOT (FAT-32) partition on USB device Default KBD is en-US but can be changed on first boot; pkeys=es is a sample to set my Spanish KBD, delete it if unneeded. MBR grub4dos iftitle [if exist (hd0,0)/Slacko64-7.0/puppy_slacko64_7.0.sfs] Puppy Linux Slacko64-7.0 - (hd0,0)/Slacko64-7.0 kernel /Slacko64-7.0/vmlinuz pmedia=usbflash pdrv=U-BOOT psubdir=/Slacko64-7.0 pkeys=es pfix=fsck,fsckp initrd /Slacko64-7.0/initrd.gz Grub 2 menuentry "Puppy slacko64 7.0" { echo "Loading vmlinuz" linux /Slacko64-7.0/vmlinuz pmedia=usbflash pdrv=U-BOOT psubdir=/Slacko64-7.0 pkeys=es pfix=fsck,fsckp echo "Loading initrd.gz" initrd /Slacko64-7.0/initrd.gz } On first boot you are able to edit your settings, connect to your LAN, etc. when you turn off the OS you have the option to create a persistence file, if using default settings it will be slacko64save.4fs file, located into Slacko64-7.0 folder. NOTE: Every time you close the OS you are allow to save changes or not as you prefer. alacran
  6. There is no rush my friend, take your time, and maybe better waith for new UEFI grub4dos version. By the way as I read grub2 of a1ve do not have that problem since the begining because it is coded to find the EFI on FAT-32 first and FORCE to load it, only when it is not present there, it looks for it on NTFS partition. That's way you were able to boot from it and not from G4E when you had the compressed EFI on NTFS partition. alacran
  7. Yes, that sound fine, I usually make the VHDs from Win10XPE_x64, as it boots as Trusted Installer, there is no problem to remove the x-Boot and x-EFI, but it's better if they are not created, in fact I deleted them and bootmgr and BOOTNXT files before make a new recaptured WIM file, but so far they were created and renamed every time I use VHD_WIMBOOT. It will be good if they are not recreated anymore, as in any future new version approach are also unnecessary. Hope reboot.pro will be online soon. EDIT: Thanks for correcting me, I will take care of not commit that mistake again. alacran
  8. Attached the Wof status, my incredulous friend. alacran WOF_Status_L_EFI_2020-12-29_04-46-37.7z
  9. New version working very fine. Go to my issue Report: https://github.com/chenall/grub4dos/issues/248 Almost at the very end of it you will find a message from yaya, download the BOOTX64.rar.txt, delete the .txt and extrac the new version, he allready implemented the map -- mem --top and now it is possible to load files to the top memory just as on MBR version I just tested it Rambooting a 2 partition VHD of 2.3 GB and it booted very fine. I assume it will be officially released very soon. alacran
  10. Having the VHD attached, I created the boot files/folders with this command bcdboot L:\Windows /s K: /f ALL and latter edited the BCDs with BootIce. alacran
  11. Just to make sure it was not an issue created by a possible mistake I committed, I deleted all the VHDs used for testing since 2020-11-26 version and created a new 900 MB Win10XPE_x64.vhd FAT-32 single partition VHD just extracting the ISO to it, and also a 1088 MB 2 partitions Mini-10-UEFI-WB.vhd (WimBoot VHD), both are booting fine but the virtual Floppies, CDs and VHDs are present too on this new Mini-10-UEFI-WB.vhd. If Rambooting Mini-10-UEFI-WB.vhd on MBR all is fine (no virtual devices on it), then there is no dubt they are created by the UEFI version of grub4dos during loading to Ram. And now I have a new issue, during this new tests I was UEFI booting from the Win10XPE_x64.ISO to make certain editions to the menu.lst and copying some files. etc, it was booting very fine more than 5 times until it do not fully load anymore, the loading line remains forever about 1/3 from the beginig and never moves, replaced it with the copy on my USB and same thing, tryed with and old version and then the classic message boot_image_handle not found, so now it can load any other ISO but not that one (from any partition, as tried several). Also there is no way I can setup the resolution on this PC, If I put colors or set a resolution, then the screen is colored and with no letters on it. At least now it is 1024x768 (just by itself) because it was 800x600 before, anyway once the WB VHD or the PE VHD boot, the resolution (1024x768) can't be changed, This 22 inches screen standard resolution is 1920x1080, but I usually have it set to 1600x900 on everyday use. Also the halt commad makes the PC reboot. Then I could say: This new version is working better than previous, it is a great achievement to Ramboot by means of SVBus as I can confirm. But there are still many things to fix, let's be patient, I'm sure in a few months the VHD Ramboot will be working as fine as the MBR version, yaya, a1ve, sunsea and many others including Ventoy author are actively posting comments and ideas on the topic on wuyounet forum. In the mean time we could help testing every new version to give them feedback with our findings. @ wimb I suggest you to make a Win10XPE_x64.vhd FAT-32 single partition VHD (maybe 900 MB to 1 GB depending of the size of your ISO to start testing Ramboot, don't forget to delete the CDUsb.y file on the VHD or you will have problems during booting, this is just to make sure your PC UEFI firmware allows you to boot from it. If this goes fine you should try latter a Mini-10 Wimboot install on a 1088 MB 2 partitions VHD wich is working fine on my PC. Maybe you are luckier and you don't get the extra virtual devices I get here. alacran
  12. It seems I found the possible cause of the issue: Once Rambooting from a 2046 MB (just 2 MB smaller than 2 GB) VHD there are 3 virtual floppy drives (A:, B: and M:) + 2 virtual CDs (N: and O:) + 2 VHDs (they appear as un-inicialized) all of them related to SVBus, see attached pictures please. I don't have any resolution set on my menu.lst, after Rambooting and once on desktop the OS resolution is very low and it can't be changed. alacran
  13. Just made a 2046 MB VHD with same partition layout and installed on Compact LZX mode my Mini-10x64 on it and it Rambooted flawlessly on UEFI, This probes I was right when I said there is a 2 GB limit imposed to items loaded on Ram on versions grub4dos-0.4.6a_for_UEFI-2020-11-26 and 2020-12-05 I opened an issue on https://github.com/chenall/grub4dos/issues Related to can't map --mem more than 2 GB on Ram: https://github.com/chenall/grub4dos/issues/248 alacran
  14. New version available: This new version is capable to UEFI Ramboot my 800MB Wimboot Mini-10x64 as VHD or as IMA: A big thanks to yaya, a1ve, and all other developers involved on this great achievement. But the 2.3 GB Mini-10x64 Compact mode installed did not boot as VHD or as IMA file: Message is still the same: (hd0,1) Out of memory boot_image_handle not found Press any key to continue.... NOTE: Both, the 800 MB Wimboot and the 2.3 GB Compact mode, where installed on NTFS second partition, and boot files/folders are on first 64 MB FAT-32 0C partition (active to also be MBR bootable) of the (MBR inicialized) VHD or IMA. See pictures of sample BCDs attached on this post. From my previous post: Then only issue remaining is: Load to RAM VHD or IMA files bigger than 2 GB. alacran
  15. Just for testing pourposes, (as I do not see any practical use for it), I created a 900 MB VHD, inicialized it as MBR, single partition FAT-32 0C, and extracted there the content of my Win10XPE_x64.ISO (843 MB), only excluded the CDUsb.y file to let it find on internal HDs the partition where it is contained. Made following entrie on \EFI\grub\menu.lst: The VHD was loaded to Ram very fine and it booted flawlessly, this confirms the grub4dos for UEFI is working very fine. Then my statement on previous post is valid: I can say only issues pending to solve are Rambooting VHDs when using SVBus driver, and load to RAM big size VHDs (2+ GB). In fact I don't know which it the actual size limit to load on Ram some item, so far a 2.3 GB VHD or IMA file is not loaded, it reports not enought Ram, but I was able to load and boot from Ram linuxmint-19.3-cinnamon-64bit.iso which size is 1.89 GB, based on this I assume the limit is currently about 2 GB. alacran
  16. Just to confirm if there could be something wrong during the creation of the IMA file from the VHD file on my previous post, I decided to test it Rambooting on the grub4dos MBR version, using following commands on my vhd.lst, (just to keep more order), which is called by the menu.lst on root of the partition/drive: And it Rambooted very fine on MBR version, this confirms nothing was wrong during making an IMA file from the VHD file. Then the BSOD: INACCESSIBLE BOOT DEVICE got when using UEFI version is related to something else, I guess the current intent on this third version of grub4dos for UEFI to find/locate on memory the IMA the second (NTFS) partition/drive by means of translating/relocating the SVBus driver info to info that can be valid/used on UEFI environment is not working fine yet. @jaclaz Hi my friend. As you can see I make use of several different *.lst files called by the MBR menu.lst, just didn't mentioned it (this way) on my previous post for simplicity, I'm also aware the internal menu.lst of grub4dos for MBR can be modiffied very easy with BootIce if required to point to find the external main menu.lst on other location or to a renamed *.lst file. But as I have readen, to do same thing on the UEFI version it has to be done on the source code, and recompile it. Anyway IMHO we should respect the guidances from the author/developer about what commands are valid or not on this new version. alacran
  17. I'm able to MBR or UEFI boot, from internal HDs or USB device, MBR menu.lst is on the root of the disk and my UEFI menu.lst is on EFI\grub\menu.lst, as no entry on both menu.lst is shared between MBR and UEFI versions, there is no gain in doing what you suggest, also the developer/author very clearly stated which commands are not available on UEFI version, then it is better to use the right syntax on each case, and don' start trying to twist it. By the way as I found on my very first test, the iftitle do not work on UEFI version, but forgot to comment it. alacran
  18. A new test trying to Ramboot a VHD by means of grub4dos for UEFI: This time I created on my HD a 10x64-WB.vhd, 800 MB VHD inicialized it as MBR, first primary partition is FAT-32 0C Active 64 MB, second partition is NTFS the rest of espace. Then installed on Wimboot mode the Mini-10x64 on NTFS partition by means of wimlib-clc and created manually boot files and folders on Fat-32 partition, and edited both BCDs as on this post to test if it was capable to boot fine, I tested it Rambooting with grub4dos for MBR, and it booted very fine. Then by means of WinImage I made a 10x64-WB.ima file from the VHD, and added following entries on EFI\grub\menu.lst to test if it can be loaded to Ram and check if it was possible to Ramboot it on UEFI: I got same result with both, the IMA file was loaded to Ram very fine, and it started booting as I was able to see the dots moving in circle, but it wasn't able to totally boot and a few time latter I got the BSOD: INACCESSIBLE BOOT DEVICE alacran
  19. In order to test the use of variables I made following entry on \EFI\grub\menu.lst The linuxmint-19.3-cinnamon-64bit.iso Live CD booted flawlessly as expected, so this confirms it is also valid to use variables on the grub4dos for UEFI menu.lst, just same as the MBR version. alacran
  20. I had to adapt a little the usual especial (cheat code) menu entries as map --hook command is not available and/or required on UEFI version of grub4dos, also avoided the use of variables (just in case), but I think using variables will give same results too, I'll test the use of variables latter. Tried this entries on \EFI\grub\menu.lst Both entries got a successful boot without any issue. So far it seems Linux Live ISOs capables to boot on MBR and/or UEFI, can be booted on UEFI environment just making very minor adaptations to the cheat code used on MBR. alacran
  21. Yes, the Secure Boot is good for nothing, computers get Virus with or without it. The name is a fallacy. But it has being very well sold to the masses. It is only good to make money from the developers and OEMs as their software require to be approved and certified by MS, if not the drivers can't run if Secure Boot is enabled. So far at home all PC's HDs are MBR formated, I usually never format any HD as GPT (an unneeded complication for HDs smaller than 2TB), and as I use to Ramboot VHDs a lot by means of SVBus + grub4dos for MBR, all UEFI PCs at home have CSM enabled and Secure Boot disabled permanently. But for now I'm making an exception booting in UEFI just to test this new version, which seems very promising to me, especially now that almost all new machines are UEFI only. By the way tested the corrected entry on menu.lst: It do not work, message: (initramfs) unable to find a medium containing a live file system. Same message we get if we try the map or map --mem commands on the grub4dos for MBR without the especial (cheat) code: So it seems a especial code will be nedded on UEFI environment too. alacran
  22. My mistake, I forgot to map --mem /CD/linuxmint-19.3-cinnamon-64bit.iso (0xff) Will fix the mistake and try again and report back. alacran
  23. It creates a very small second partition FAT-32 formated at the very end of the device, where the NTFS drivers requiered to boot from NTFS on a UEFI environment are located, so anyway you HAVE a FAT-32 partition to let you boot from the boot files folders located on the NTFS first partition, this drivers make also possible to boot from files folders located on a exFAT partition. In both cases as long as Secure Boot is disabled. alacran
  24. The UEFI version is also capable to load to Ram files compressed as *.gz or *.lz4, same as the MBR version does, just tested with the following menu.lst entries: The grub4dos for UEFI \EFI\Boot\BOOTX64.EFI (renamed to g4ex64.efi) is located on MBR (hd1, 0) which has a FAT-32 0C Primary partition where the EFI files/folders reside, of course during UEFI booting the HDs order is swap and becomes (hd0,0) as it is the only UEFI capable (seen then as first HD). All of them were loaded to Ram and booted very fine. But linuxmint-19.3-cinnamon-64bit.iso didn't boot fine, I used this entry to try to boot it: alacran
  25. No, this is only valid to run under UEFI environment, so to try to run something, it has to be UEFI capable. And as jaclaz just said DOS is not UEFI capable. IMHO in fact the name is not really appropiate, also many people on wuyou.net forum think same way, some of them have suggested to rename it to grub4efi or grub4uefi. Almost all code has being rebuild and many features do not exists anymore, some because they do not apply on UEFI environment and other because haven't being developed yet, as an example it lacks map --mem --top command, very useful to Ramboot VHDs (having SVbus driver installed) on MBR/CSM machines; from the author on Release Notes: Basically I think there isn't any technical reason to keep using the name grub4dos since almost all code is totally different. So far the only commands (shared with MBR version) I have tested are: find --set-root, map, map --mem, commandline, reboot and halt. Keep using the grub4dos name creates a lot of confussion, also some people has suggested to rename the menu.lst config file to menu.efi. or efi.menu, but just putting it on \EFI\grub\menu.lst lets us avoid confussion in this case. This UEFI version can't be installed on MBR or PBR, do not require to use the grld file, also there is not a file grldr.mbr file which allowed us to run grub4dos from the MS bootmgr on MBR/CSM machines, and the grub.exe file that was used to run grub4dos from grub2 do not exists anymore. On the UEFI version only the BOOTX64.EFI (on \EFI\Boot\BOOTX64.EFI [which I renamed to g4ex64.efi to let it coexists with the MS bootx64.efi]) and the menu.lst files located on a FAT-32 partition are required. To run it from grub2 on UEFI environment I use: if [ "${grub_platform}" == "efi" ]; then if [ -e "/efi/boot/g4ex64.efi" ]; then menuentry "grub4dos for UEFI" { chainloader /efi/boot/g4ex64.efi } fi And to go back to grub2 we can use: exit_g4d alacran

  • Create New...