Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

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. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


jaclaz

Member
  • Content Count

    20,249
  • Donations

    $0.00 
  • Joined

  • Last visited

  • Days Won

    38

jaclaz last won the day on November 30

jaclaz had the most liked content!

Community Reputation

1,373 Excellent

7 Followers

About jaclaz

  • Rank
    The Finder

Contact Methods

  • Website URL
    http://jaclaz.altervista.org/

Profile Information

  • OS
    none specified
  • Country

Flags

  • Country Flag

Recent Profile Visitors

18,823 profile views
  1. Which is good, but completely unrelated, since my note (and method) is NOT AT ALL about the "embedded" menu.lst in grub4dos, it is about embedding booting commands in the target .iso (or .vhd, or .img, etc.). I think you are still missing the point (which is about compatibility), sure we should use the right commands, but by having a non-existing command produce a warning (and/or a non-blocking error) the non-existing command can remain where it is. jaclaz
  2. Sure, as if copy/paste was not a thing. Besides, one could use n .lst files and have in menu.lst each entry ponting to a specific "other" .lst. Example (BIOS /menu.lst): title Start /CD/linuxmint-19.3-cinnamon-64bit.iso booting from the ISO loaded on Ram find --set-root /CD/linuxmint-19.3-cinnamon-64bit.lst configfile /CD/linuxmint-19.3-cinnamon-64bit.lst Example (UEFI EFI/grub/menu.lst): title Start /CD/linuxmint-19.3-cinnamon-64bit.iso booting from the ISO loaded on Ram find --set-root /CD/linuxmint-19.3-cinnamon-64bit.lst configfile /CD/linuxmint-19.3-cinnamon-64bit.lst linuxmint-19.3-cinnamon-64bit.lst title linuxmint-19.3-cinnamon-64bit.iso set iso_path=/CD/linuxmint-19.3-cinnamon-64bit.iso map (hd1,4)%iso_path% (0xff) map --hook root (0xff) kernel /casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper iso-scan/filename=%iso_path% quiet splash -- initrd /casper/initrd.lz And of course this would be useful for my personal approach (COSMIAS, which noone else uses BTW) with "embedded" batch and self-mounting (JFYI): http://reboot.pro/topic/17807-release-cosmias-a-new-approach-to-g4d-images/ Yep. jaclaz
  3. What you should try is to add to the menu.lst entry a: map --hook Two possible results: 1) the entry fails because the "unknown" command creates a blocking error 2) the unknown command creates a warning and the entry works nonetheless If this latter, you can use (minus the iftitle ) the same entry on both normal grub4dos and on UEFI grub4dos. jaclaz
  4. USB sticks can be seen EITHER as "fixed" (very few) or "removable" (most), at least on XP/Vista/7. Windows won't put a MBR on "removable" sticks, or if you prefer, "removable" USB sticks are NOT partitioned, they are normally "super-floppies", i.e. their first sector is a PBR and not a MBR. There are several different approaches to have the MBR on a removable stick, mainly: 1) write manually a MBR and partition table to it[1] 2) add a driver to the running Windows install that can make the stick be seen a "fixed" 3) use the stick "Manufacturer's tools" to "flip" the removable bit 4) make an image of the stick, mount it in a virtual drive, partition/format it, then dd it back to the stick Then there may be some issues with the BIOS of the specific machine, some *need* a second (minimal, hidden) partition to see the stick as "fixed" at boot time. Then the booting sequence remains the same: BIOS->MBR->PBR of active partition->bootloader or system file (i.e. IO.SYS or NTLDR or BOOTMGR)->OS Of course either BOOT.INI or /boot/BCD need to have correct settings. Choose among 1-4 above and I will point you to the details/tools needed, though the easiest would still remain uing one of the several partitioning/formatting tools that we have now available, namely I would recommend you RMPREPUSB. jaclaz [1] once there is a pre-written MBR and partition table on the stick, Disk Manager will allow formatting of the partition/volume in it BUT (if there are more than a single volume on a "removable" stick, only one will be mounted and assigned a drive letter)
  5. Naah, JFYI: but - to be fair - with the Service Packs it is not that bad (and as I see it Windows 7 is actually a Vista service Pack 3+) jaclaz
  6. Sure , but you started it . BTW, and JFYI deleting posts is usually frowned upon, if you wrote something that you later find to be incorrect, it is better to format the text by striking it, so that people can understand what happened. This is an example of something that is striken. jaclaz
  7. Sure, that is a so-called "cheat-code" or kernel parameters, it has nothing to do with the booting method (BIOS vs. UEFI), it simply tells the kernel where to look for the rest of the system. Those settings could also be put inside the initrd, but of course you would have to rebuild a custom one. Anyway, generally speaking, linux .iso's cannot normally be booted by chainloading the bootsector, which is normally bypassed by the explicit kernel and initrd commands and the cheat-codes, this is not "news" and it is not "peculiar" to the UEFI. Sticky since 2009: http://reboot.pro/topic/8944-boot-any-iso-image-or-boot-all-iso-images/ jaclaz
  8. Oh, no, I did not misunderstand you, rest assured . You wrote what you wrote: and I doubted it, to which you provided proof by posting a couple senseless (and not-funny) jokes coming from a Quora answer (without providing a link to it, i.e. additionally completely out of context) : https://www.quora.com/How-good-is-12-GB-of-RAM? Nothing more, nothing less. jaclaz
  9. Ah well, that (the origin, and the fact that you call - BTW not funny - jokes "proof) says it all, you convinced me, all the machines around running just fine with 3, 5, 6, 12 GB of RAM aren't. jaclaz
  10. Sure. the whole point is that the FAT32 is an artificial limitation that has no technical grounds whatoever AND that if a NTFS driver can be written that runs in EFI/UEFI, then *anything* can be written in it AND that the Secure Boot mechanism is a stupid provision, because: 1) it can be worked around nonetheless as you are well aware (see https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface/Secure_Boot ) 2) the signature mechanism is mis-managed by MS (and by the sheepish manufacturers that follow them) AND that - to be a standard - it is pretty much a failure as everyone makes changes to it: https://wiki.archlinux.org/index.php/GRUB/EFI_examples (possibly even in good faith as the specifications are more than 2,000 (two thousand) page long) jaclaz
  11. Still, in a perfect world, it is in theory possible to emulate BIOS in UEFI, not entirely unlike what CSM does on most "dual" UEFI/BIOS firmwares, at least for the basic functions that DOS requires. A sort of "reversed" Clover. The whole point that the Intel (and associates) guys used to sell us[1] the stupid EFI/UEFI crap[2] was that it was essentially an operating system on chip and that *everything* was possible in this environment. Now, more than 10 (ten) years have passed (actually almost 15), and we evolved from a very limited boot environment that could only execute a bunch of assembler, consisting ONLY of MBR code, PBR code and bootloader/bootmanagers to a powerful environment that can run *anything* BUT for which essentially only bootloaders/bootmanagers exist (and was it not for our friend PBatard - Author of Rufus among other things - we would also be limited to FAT32 ): https://github.com/pbatard/uefi-ntfs In a nutshell, the possibilities are out there, and hopefully - before or later - someone will take the challenge. jaclaz [1] please read a "force down our throats" [2] not only crap in itself, crap worsened by arbitrary overlays of uneeded complications and limitations, the perfect example of "committee design" worsened by the de facto monopolistic power of some of the components of the committee
  12. Well, you can "not-integrate" it and use a F6 floppy, the files here: https://www.helpjet.net/Fs-18881100-17836036-56797337-extract.html seem to have the txtsetup.oem just fine. You can use a "virtual" grub4dos floppy image: https://msfn.org/board/topic/179566-getting-sata-mode-to-work-during-and-after-xp-install/ https://msfn.org/board/topic/154071-f6-without-a-floppy-drive/ or a Syslinux/Memdisk one: http://wp.xin.at/archives/2702 jaclaz
  13. I am (quite a bit) outside of the hardware loop and my experience with Windows 10 is extremely limited (I only happen to do quick fixes to the PC's of friends from time to time). Lately (think of COVID-19 lockdown/smart working) I have seen a lot of movement about refurbishing old (but not that much old) "business" PC's (think of Lenovo, HP and DELL small form factor desktops) by essentially: 1) upgrading RAM to 4 or 8 GB 2) replacing built-in SATA hard disks (originally 250/320/500 GB) with 120/128 or 240/256 SSD's 3) using (or abusing?) Microsoft upgrade policy to update OS from 7 (or 8/8.1) to 10 The processors in these machines are usually Intel i3, i5 or i7. Now the question, in the past the rule of thumb was to quadruple MS OS minimum requirements for RAM and double or triple the processor speed to have a "normally behaving" machine, as an example past "lines" for me were: a. Windows 2000 512 MB Ram 1 GHz processor (VIA C3/C7 were border line) b. Windows XP 2GB Ram 2 GHz possibly dual core (Atoms and similar were border-line) c. Windows 7 (32 bit) 4 GB RAM 2.8/3 Ghz, dual or quadruple core Video cards (for "normal" office use, and web browsing, NOT for gaming or graphic applications) have never been an issue and integrated cards always worked fine for me. Now (thanks mainly to the stupid web and current browsers bloat) I believe that 4 GB are out of question for 64 bit OS and 8 GB is needed. The hard disk vs. SSD is a no-brainer, a small SSD (+ a USB 3 rotating hard disk if needed) runs circles around internal rotating hard disks only, and 120/128 GB is more than enough for "normal" use. So, what remains is the processor and its speed/clock. Suggestions, ideas, experience? [1] jaclaz [1] Please understand how the questions revolve around el-cheapo, ordinary, low-power office machines that are readily available used in quantities, NOT about custom-built PC's with high-end processors, KW power supplies and stupidly fast double or quadruple fan video cards with a zillion GB of dedicated RAM.
×
×
  • Create New...