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.

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.

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.

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.

Code:

pmagicORubcd.iso/ pmagic/ pmodules/ pmagic-6.6.sqfs

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:

Code:

USB/ multiboot/ ubcd511/ pmagic/ pmagic/ pmodules/ pmagic-6.6.sqfs

So. ....

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

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.

YUMI uses GRUB for multiboot, but other well-known tools use SYSLINUX for multiboot

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.

Quote:

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.

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

Quote:

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 .

See above comments...

Quote:

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

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:

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:

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?

Last edited by ryran on Fri Sep 30, 2011 5:46 pm, edited 1 time in total.

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).

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.

Ah. I see.

Quote:

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.

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.

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.

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).

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.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum