Re: UBCD V5.2 discussion

No, a "real" ramdisk isn't created. The image is becoming that ramdisk. As you see in the following screenshot, C: contains everything after boot (obvius e.g. through folders TMP or USR) and gets renamed to RAMDISK. So even the label changes.



If I try to boot fdubcd.img as provided in UBCD V5.2a2 (unzipped of course) via qemu the boot hangs. My created image boots once (as hdd-image) in qemu, the label gets renamed and everything that had been copied to the "ramdisk" which is actually a hdd-image loaded into RAM, remains in this hdd-image, leaving it disfunctional as of the next boot. You also see the slightly smaller size in the screenshot of my hdd-image-version:



Now if I load my hdd-image in qemu as hdd directly you can see again exactly this screen after first boot - (which is very slow, since - as said - everything is written to that HDD during boot. In this case no kind of RAMDISK is created, so it takes very long to boot that way)

But if I reboot from this image I get this:



Can't be replicated with the current version of fdubcd.img as said, because it only boots via syslinux (no interest in grub-problems here) but not in qemu.

So if this image is only loaded via syslinux (or grub) nobody will ever have a problem with this. Only if somebody tries to load it directly as harddisk in a virtual machine, what even needs a fix right now. So not fixing it, might in this case not even be the worst idea