Hi

I cannot make UBCD to work with YUMI (pendrive multiboot tool, http://www.pendrivelinux.com/yumi-multi ... b-creator/ ).
When booting UBCD, it jumps just to GRUB command line (I think it is that).
I use latest versions of both.
I can boot Ubuntu and Hiren BootCD with no problems.

Please help.
I know that it is probably YUMI issue, but I think you could determine the problem much faster.

TIA

YUMI-0.0.2.8.exe – August 27, 2011 - should be able to handle UBCD 5.1.1.

For a "one distro only" job, YUMI uses syslinux, so you could very well use ubcd2usb as well.

For a "multiple distros" job, YUMI uses GRUB to boot 1 ISO image made from all the distros "merged".

Start with the "one distro only" ( or with ubcd2usb ). If that works, go on with the other option too.

If the "one distro only" works, but the "multiple distros" doesn't, then you need to search for help from YUMI.

Or, you may want to try some other tool from the list there http://www.pendrivelinux.com/category/usb-creator/.

I'm also having trouble getting UBCD to work with YUMI, but not in the same way. I can setup a boot cd of UBCD or a usb (using ubcd2usb) that works fine; however, when I use YUMI to do a single- (and then later multi-) boot usb, UBCD isn't able to load Parted Magic. Everything else works, and PM seems to be working--up to the point where it fails when "Searching for pmagic-6.6.sqfs..." -- reports that it couldn't be found of course.

Obviously I could have a separate Parted Magic entry on my YUMI usb as well (and I do--for the x64 version), but... I was wondering if anyone else has any tips on this, as I'd really like to get UBCD to load Parted Magic (when coming from YUMI). I even manually extracted UBCD (YUMI just loads it from the iso file) and converted all the syslinux menus' paths properly. AGAIN, everything works except for the loading of PM.

Anyone.. HALP!

Well. I got it working.
Here's how: I eventually noticed that you (Victor) have the pmodules directory (containing the all important sqfs) in a different place than in a stock PM iso.

Stock PM is like so: pmagic/pmagic/pmodules
UBCD PM is like so: pmagic/{pmagic,pmodules}

I assume that this works somehow because of the iso_filename=ubcd511.iso kernel argument but uhmm.. I don't quite get it.

For my purposes, moving the pmodules dir into pmagic/pmagic/ solved my issues. Perhaps this will help someone else. I'd love to understand more what was going on though.

The pmodules is not in a different place. It's {bzImage, initramfs} that are.

On stock PM, it looks like this:



On UBCD, it looks like this:



It's the path of pmodules that is important, because PM looks for it there once the kernel is loaded into memory.

I am not sure how moving it to:

/pmagic
/pmagic
/pmodules

helped, 'cos that sure ain't where it is on the stock PM CD.

@Victor,

I'm not sure where exactly the "pmodules" folder "is expected".

The "position" in the folder tree could be related to the parent folder "\pmagic\" alone, or it could be also related to the root of the ISO:


OR

it could be related to the other "\pmagic\" folder, where "bzImage" and "initramfs" are located (or anything else).

I'll put it this way (sorry for all the capital letters and the "\", which are not the "Linux" style, but I though in this case it would be better):



Which means that in UBCD.ISO, there is indeed a "\pmagic\pmodules\" as in PMAGIC-M.N.ISO;

BUT it also means that the "relative level" (in the folder tree) of "bzImage", "initramfs" and "\pmodules\" are NOT the same.

In PMAGIC-M.N.ISO, all 3 are at the same "relative level", while in UBCD.ISO, the "\pmodules\" folder is 1 level up (relative to the 2 files "bzImage" and "initramfs").

So, when ryran moved the "\pmodules\" folder one level "down", the result was:



and then the 2 files and the "\pmodules\" folder were "at the same relative level in the tree".

Changing the tree might also need to change some "cfg" file or changing some argument in it so to boot PartedMagic from UBCD, but the folder tree "might" need this type of improvement.

I hope I was clear. Of course, Icecube should know more about the conditions of the folder tree and the config files .

I'm still not sure about ISO9660 being able to support that "long" path (using 2 "\pmagic\" consecutive folders), specially for the "*.sqfs" file (more than 31 characters long for the complete path). This might not be a problem in a USB drive (since it doesn't use ISO9660 ), but it might be in an optical media.

So, Victor, would it be "problematic" to get rid of 1 of the "\pmagic\" folder, and use the same relative tree as pmagic*.iso?

I am thinking about the current 2 separate "\boot\" folders, the several cgf files, and all the scripts (ubcd2usb, ubcd2iso, antivirus updates and so on). There might be also other considerations which I don't currently remeber.

I thought I was mistaken, so I checked again. But here's what I still find:


(ignoring other files and folders, focusing on "pmodules" alone)

Like I said, the location of pmodules is the only important one, since PM looks for it on the CD after the kernel is loaded.

"boot/" have been relocated to ubcd.iso/pmagic for obvious reason (to avoid conflict with ubcd.iso/boot).

bzimage and initramfs _can_ be relocated to "ubcd.iso/pmagic" instead of "ubcd.iso/pmagic/pmagic", but as cannot be stressed enough, their absolute locations are not important, only "pmodules".

Apparently (according to ryran), pmodules (and the pmagic-n.m.sqfs file) has a valid alternative location, or PM wouldn't boot at all with that file in the alternative location he used.

It would be nice to see a dir list of his YUMI drive .

Victor, I never said you were mistaken. What you posted is in accordance with the same tree I posted, and users have been using it for several years now .

My only intention in this topic is to make easier for users to install UBCD, specially with several tools that nowadays are doing this type of things easier than in past years.

If changing some location of the tree makes it better (without forgetting that the CD has to work too - not only the USB), it is worth investigating IMHO.

@Ryran, could you please post inside "code" tags your folder tree?

Wow! Thanks so much for replying Victor! (And Ady!) I sooooo appreciate all the amazing work you've put into this over the years.

After going back and looking at this, now I'm starting to doubt my sanity. I can confirm (of course) what you posted Victor about the content of pmagic & ubcd isos--that I was wrong in my statement of the layout of a stock PM iso.
Which is mind-blowing to me... since uhh... I'm not insane.. I'm actually relatively OCD (perfectionisticly-thorough) about this kind of stuff. How else did I get the idea to move pmodules? *sigh* Agh.

Well, in any case, I can reconfirm that I can't get my multiboot system to work unless I do it like this:

So. ....

Of course I had to modify the syslinux.cfg file for pmagic-in-ubcd in my extracted tree. Here's an excerpt.

Thanks for the reply and the info.

I have to say, something is odd here I don't know if it is YUMI only, or it would happen also with other similar tools that should do the same as YUMI does.

YUMI uses GRUB for multiboot, but other well-known tools use SYSLINUX for multiboot, so it would be interesting to compare results, and if this issue happens there too.

Here is the main reason I think something is strange. As Victor pointed out, the "/pmodules/" (with "/" this time ) and its contents "must" be in a certain location in the folder tree for PMagic to boot. This is not an UBCD requirement, but a PartedMagic one.

In fact, there is a kernel boot code to allow PartedMagic to look for the "/pmodules/" in a different path ("directory="; without quotation marks). This gives customization possibilities, but also reduces troubles.

You see, if you have the "/pmodules/" folder in a default location, and you boot PMagic from a different device, there is a chance that PMagic boot process would identify first that other "/pmodules/" folder, instead of the "intended" one.

That's for troubleshooting, but of course it goes the same for customizations. By using the "default" (well, "almost default") expected location, it makes it easier for UBCD to handle PMagic and for manually updating it.

So, ryran, is it possible that this is a YUMI or GRUB issue? Or maybe you have added both, UBCD and PMagic, to the selection in YUMI? (Just thinking out loud.)

I wonder, if YUMI in the simpler mode, installing only 1 tool (UBCD only in a clean USB drive, including clean MBR/PBR), which uses SYSLINUX and not GRUB, would get the same result . Unfortunately, I'm not in a position of performing that test myself .

ryran, could you please post the original cfg file for pmagic that YUMI built, before you edited it? Thanks.

ACTUALLY, YUMI uses syslinux whenever it can and falls back to using GRUB for ISOs that it doesn't have code to deal with. In the case of UBCD, there's actually an entry for it in YUMI, but when you choose that, YUMI doesn't do any of the cool syslinux stuff it does with most other things (like Fedora, for example) and instead just copies the iso over and sets it up with grub. So that was crap. Didn't work. (Refer to my original post.) So I extracted the iso and set up the syslinux cfg files myself.

Yes.. before I moved anything I experimented with the directory= kernel arg to no avail.

See above comments...

Again, all it did was a simple chainload with grub.. and again, PM-in-UBCD couldn't find the sqfs file.
In the end, I'm loading ubcd as simply as possible via my syslinux configuration, with a label entry like this:

And then the sed-tweaked main.cfg [excerpt]:

Thanks for reading. Honestly, I'm quite surprised the YUMI people aren't aware of this. Probably half of the people that use UBCD are using PM at some point or another. ..... Just.. weird.

EDIT: For posterity (and my own peace of mind) I've uploaded the important parts of all my multi-boot work (everything minus the extracted isos) to http://github.com/ryran/usbmultiboot

Okay. I wanted to start over from scratch so that things could be easily-reproduced -- and so that I could just have a simple script to run when new versions of UBCD come out. There are a few things I had forgotten:
(1) I *did* use the directory= arg in my pmagic config. I basically replaced the iso_filename=ubcd511.iso arg with my directory= arg. I don't really understand what either of those do. That's just what I tried and it worked.
(2) I converted the format of the pmagic syslinux.cfg file... instead of the default set-up of using 2 lines in each label entry to load something, e.g., COM32 ...linux.c32 & APPEND...bzImage...initrd= etc, I changed it to the 3-line format of: linux...bzImage / initrd... / append... -- I think I did that while I was trying to figure out the failure to find the sqfs image and just left it that way.

In any case. Back to the present. I started over. I changed the path in my multiboot setup from ubcd511 to UBCD for the sake of future-proofing. I also realized I didn't need to mess with the things I messed with in (2) above. This time, all I did was run the following (spread out & prettied-up just for you) from the dir of my extracted ubcd iso:


I also updated things at the website... now there's a script to do all this. (https://github.com/ryran/usbmultiboot/b ... c-multiusb).

In other news, I just noticed for the first time that CPU Burn-in, CPUinfo, and the other few items in the CPU category that use the bzImage kernel from pmagic don't work on my USB OR the stock UBCD V5.1.1 CD! Kernel panic. Modifying the the bzImage path to the one in ubcd/boot/cpustress/ works (tho a couple errors pop up) so I went with that. I'm guessing this was some accident that happened recently....? Victor?

OK, let's go for the easy one first : the cpu stress tools. UBCD 5.1 version used the PMagic's kernel instead of the original, so to attempt to make cpu stress work with more modern CPUs. This change didn't work so well. I haven't tested cpu stress in UBCD 5.1.1, but I don't think Victor went back to use the original kernel. The "best" thing to do is to update the whole thing to the latest version, but this updated customization was not done yet.

Now, about grub and syslinux in YUMI. If I understood you correctly, YUMI tried to use grub to load UBCD, but it failed in your case, so you changed it manually to use syslinux, correct?

Well, you mentioned your point #2, changing the "style" of entries, and then dropping that step in your latest trial.

Even if you dropped it, that comment gave me a hint. Which version of Syslinux YUMI is using? And which version of Syslinux you used to load UBCD?

UBCD 5.1.1 uses Syslinux 4.04, and when booting PMagic by means of Syslinux, you'd better use the latest version available. Older versions most probably fail on PMagic, because it uses features not available in older versions of Syslinux.

If you can, you could try using the latest BETA version of SARDU (NOT the stable version). In SARDU latest beta, you should be able to use SYSLINUX 4.04 with the original UBCD511.ISO (avoid modifications for this troubleshooting), and you can even test PMagic without UBCD, as a separate tool.

If SARDU, using SYSLINUX 4.04 is able so use PMagic from inside UBCD and even close the session correctly, then it would be clear that the problems are on YUMI's side (in respect to its support of PMagic and UBCD 5.1.1).

Ah. I see.

I didn't reinstall syslinux when I added all the syslinux config-stuff for UBCD, so I still have whatever version YUMI installed on the drive. From looking at the source for YUMI, I can tell it uses syslinux 4.03. <20 minutes later> I'm surprised that Fedora only has 4.02 in its repos... Anyway, long-story shorter, I updated the flash drive to 4.04. No difference--still need to have the pmodules folder moved, as per above. As for SARDU.... I'm not up for that right now. I'm happy with the way my drive works.

I just started using YUMI to see what I can do and I wasn't able to start PM within UBCD but no problems with an updated version of PM installed separately. I tried moving the pmodules directory into the pmagic/pmagic directory "within the ISO image" as I think ryran was suggesting but that didn't work for me. I also tried putting it into the root of the drive under pmagic/pmagic with no luck.

I finally got it working by putting pmodules directory into a pmagic directory in the root of the drive. I did not edit any config files so ryran's work around may have worked if I did but by just putting the pmodules in the pmagic directory in the root of the drive works with no editing of config files. Next I'll probably try stripping the pmodules directory out of the ISO to save the almost 200MB of space and see if it still works.

Alrighty then...

I rebuilt the ISO removing the pmodules directory and PM appears to work fine with the pmodules directory in pmagic at the root. I updated to the newest PM while I was at it. Actually copied over the new syslinux.cfg file and screwed it all up for a bit till I noticed what I had done. Copied over the UBCD version and changed the 6.6 to 6.7 and all seams to be well again and booting fine. Only thing is... I actually have never run the AV programs from the UBCD version of PM and have to do a bit of looking around to see how before I check if they are working as well.

I have had the issue of the ubcd.iso file becoming fragmented which gives an error and had to run wcontig to fix it which works every time so far.

I have to do some work for a while and will check back here later before I look up how to run the AV programs from PM in case someone wants to chime in on the how/hows... I kinda recall reading that I have to do it through a terminal window but not sure.

EDIT: OK, AV programs appear to be working fine. freshclam isn't working so I'll just do manual updates, now just to figure out how to update the definition files within the .txz files in pmodules.

@The Piney,

About updating the AV definitions, in UBCD you should be able to run the relevant scripts before rebuilding the ISO. There is "xfprot" to run f-prot too (besides ClamAV).

Now, about the pmagic*.sfqs file not found, could you please check the "case" of the name?

Here's what I mean. For the situations where the file is not found while trying to run PMagic from UBCD, open a cmd box under Windows and "dir /s" the UBCD and PMAGIC folders. How is the file listed? Is it "pmagic*.sfqs"? Or is it "PMAGIC*.SQFS"?

According to your answer, there may be some simple workarounds and even solutions available.

In addition, besides YUMI, there are other several similar tools that may work correctly (and my previous question about lowercase or uppercase of the sqfs file is a possible part of the solution).

@ ady

All instances are in lower case (pmagic*.sqfs) from the extracted ISO on my hard drive, remastered ISOs and on the flash drive.

Thanks for your prompt answer.

Well, then I'll have to keep searching.

The "normal" ISO9660 format is compatible with DOS names, which is 8.3 and uppercase filenames. When using mkisofs, the command line "needs" to have the appropriate parameters so to add some kind of extension to the standard ISO9660 format, like the Joliet extension for example (among other possible and/or recommended command line arguments).

Under Linux, the uppercase files are different from the lowercase files. PartedMagic won't recognize / accept the pmagic*.sqfs file if it is not using a lowercase filename. This has been reported several times in the PartedMagic forum.

The original ISO of UBCD is supposed to use the correct command line arguments for mkisofs. The remastered ISOs (containing the pmagic*.sqfs file) or the files in the UFD were the ones I was interested in.

Well, as I said, we need to keep looking. I wonder if tools other than YUMI also have this problem or if they behave similarly (and there are several similar / alternative tools to test).

I've built several DVDs using SARDU and I like that so I may give it a go for the USB drive some time soon. What I like about YUMI so far is you can add or remove distros any time you want by just running the program again. I think SARDU has to reload the entire drive each time but I'm not sure about that.

The only real downside I've run into so far with YUMI is that after adding/removing the UBCD ISO several times, it starts getting fragmented and I've had to run WinContig to clean it up. That and for some reason Damn Small Linux hasn't worked for me yet, although that could be a machine issue I guess.

Next, I'm gonna try adding other unlisted ISOs and see how that works, maybe ArtistX or one of the Linux Gamer or similar DVDs.