[continued from previous message]
option, you can run a program to get it to boot off a HD exactly as it
does off a USB. In both USB and HD copies, there is a bash script ...
/utils/linux/makeboot.sh
... which can be run to make the installation bootable in exactly the
same way from either medium. Probably it would be needed for a USB only
rarely, because programs that write the ISO image to the USB seem
generally to take care of things pretty well, but for a HD installation,
it seems to be the easiest way to get everything to work as it should.
However, if your Clonezilla HD partition is formatted FAT32 like a USB,
then you can't just run the file, because FAT32 doesn't support the x
attribute, and by default modern linux systems tend to mount FAT32
partitions translating the attributes of all files as non-executable.
The easiest way around this is to run the script through bash ...
sudo bash /utils/linux/makeboot.sh /dev/sdxy
... where sdxy is the designation of the Clonezilla disk and partition,
in my case ...
sdb2
Now when you boot from that hard disk, it will boot straight into the
normal brightly coloured Clonezilla menu with large fonts, and will
behave seemingly exactly as if it had been booted off USB. Then you can
reinstall grub to get everything else back. For the Clonezilla option,
preserving what has been won, add to the file (in Ubuntu, other distros
may differ) ...
/etc/grub.d/40_custom
... the following ...
menuentry {
savedefault # If you've enabled saving the last grub choice
set root=(hdx,y) # Where x & y are the CZ disk and partition #s
chainloader +1
}
Note 3
======
Booting W9x images requires memdisk from the Clonezilla USB.
The first image is a floppy, the second a USB stick, recreated since the
first thread in June. Readers of that original thread may remember that
getting that W98 Emergency USB stick image to boot was the most
difficult problem to solve, and that originally I never got it to boot
directly from Grub, but I have now solved this by remaking the image
completely virtually, as described below.
I'm pretty sure I know now what the original problem was, though I have
not done a definitive test to prove my theory, being content merely to
have solved the problem somehow or other. I think the problem was that
the original USB stick had a Microsoft MBR, which for a long time had a
bug which Microsoft eventually only 'solved' by obviating it through
adopting UEFI booting methods. The bug was this: no matter what number
disk the MBR was loaded from, it looked for the partition table from
Disk #0, not that of the disk from which it itself was loaded. The
definitive test would be to replace the MBR in the problem image, and
see what happens, but I'm afraid that, having solved the problem now by
other means, I can't be arsed.
Here's how I recreated the image in such a manner that it worked:
3.1 First, obtain a decent MBR. Historically, I've found those
installed by Lilo inter-work well with Microsoft's idiosyncrasies, but
Lilo is no longer available from recent versions of Linux, so here's a
way to obtain it (others more knowledgeable about Lilo &/or distribution
file arrangements may be able to suggest a way to download it directly):
3.1.1 Boot from an Ubuntu 18 USB, and choose to Test, NOT install.
3.1.2 Run a terminal
3.1.3 sudo -i
3.1.4 apt -y install lilo
(ignore the warning, has no relevance here)
3.1.5 Attach either a "don't care" USB stick or a USB drive bay
with a "don't care" disk in it; let us suppose that in this instance it
comes up as /dev/sdx
3.1.6 lilo -M /dev/sdx mbr
3.1.7 dd if=/dev/sdx of=/Lilo_MBR.img bs=1 count=446
( must be to some place that will survive exiting the Ubuntu 18
installation environment, say on a local HD which you will have to mount
beforehand. Note that 446 stops just short of the disk's partition
table, you don't want to be copying that.)
3.1.8 Close down the Ubuntu 18 installation environment and reboot
into normal Linux.
3.2 Copy the MBR obtained as above to become the start of the new W98
system disk, then complete the first sector by creating an empty
partition table (64 bytes more) and appending the boot record tag (2
bytes more):
cp -a Lilo_MBR.img W98_Disk.img
dd if=/dev/zero of=W98_Disk.img bs=1 seek=446 count=64
echo -ne '\x55\xAA' | dd of=W98_Disk.img bs=1 seek=510
3.3 Extend the image to be large enough to contain what is required to
be on the disk, in my case a little under 50MB, so ...
(50*1024^2)/512 - 1 = 102399
... sectors
dd if=/dev/zero of=W98_Disk.img seek=1 count=102399
3.4 Create a partition table on the disk with a single FAT32 (LBA)
partition:
fdisk W98_Disk.img
n (accept subsequent defaults offered to create single partition
over whole disk)
t then 0c (change partition type to W95 FAT32 (LBA)
a (set sole partition active)
w (write the result back to the image and exit)
3.5 Make a FAT32 filesystem on the partition (if /dev/loop1 is already
in use, choose a successively higher number until a free one is found).
The offset given, 1048576, is that of the first partition:
losetup /dev/loop1 W98_Disk.img -o 1048576
mkdosfs -F32 -f 2 /dev/loop1
losetup -d /dev/loop1
3.6 Now there's the problem of installing the Microsoft W98 system.
It's important to understand that this includes not just the three
system files - which could be put in place simply by copying them in
the correct order: IO.SYS, MSDOS.SYS, COMMAND.COM - but also the
Partition Boot Record (PBR), the first sector of the partition, which
contains the boot code to load IO.SYS, and it is this latter which is
the problem. In my case, I already have a bootable W98 system floppy
disk image, and QEmu is installed, so I did it in the latter, otherwise
some method similar to obtaining the Lilo MBR described above will be
required (beware line-wrap, QEmu command should be all one line):
qemu-system-i386 -fda W98_Boot_Disk.img -hda W98_Disk.img -boot order=ab
SYS C: (sets up PBR and transfers the 3 system files - IO.SYS,
MSDOS.SYS, COMMAND.COM - to the root directory in the correct order)
Then exit QEmu.
3.7 For the rest of the files, the image file can be mounted as a loop
device and the remaining files required for it can be copied in by any
normal procedure.
Note 4
======
The 'insmod ntfs' line is there because the ISOs are stored on an NTFS
partition. Note that the Grub settings for the Ubuntu installation ISOs
are nearly identical, the only variation being for the initrd line ...
Ubuntu 18:
initrd (loop)/casper/initrd.lz # <-- .lz file extension
Ubuntu 20+:
initrd (loop)/casper/initrd # <-- No file extension
Note 5
======
For booting directly from Windows ISOs WimBoot is needed ...
https://github.com/ipxe/wimboot/releases
... which I have placed in the ISOs directory of the Image partition
(#4) on my USB stick. Then as described above and as found online I
added the following fragment to ...
/etc/grub.d/40_custom
... and it and all the installation ISOs for Windows 8 through 11 work.
I would imagine that Vista probably also would work, but that XP and
earlier would need a different arrangement:
menuentry "Windows 7 Professional 64-Bit Install" --unrestricted --class
Windows {
savedefault
set
[continued in next message]
--- SoupGate-DOS v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
