after browsing the manual and getting some very helpful tips here in the forum about installation options to USB, I've done some experimenting, and actually advanced a bit... with mixed results.

I believe that what I want to do now IS possible, however I'll need some specific details which I'm not sure if I'll be able to get here. Asking a bit doesn't hurt, I guess.

I'm trying to run the aptosid ISO _without_ burning it to a CD. The 'fromiso' tips I found in the manual preclude having whatever other partitions on the USB drive - that's not an option for me, unfortunately.

I'm currently running Windoze, and I have a working grub4dos multi-distro setup which runs from a vfat partition on a USB drive.

On this partition I have some ISOs from other distros and a menu.lst file. I use an app from pendrivelinux.com which does TWO things:

With entry above, aptosid-live DOES boot - up to a point. I get the initial options screen, then boot process starts, then it gets stuck on a 30-second cycling search for something on all devices and partitions (looking for the compressed FS, I guess), and finally dies in a busybox prompt.

Method 2unpacks the ISO into a folder structure inside the vfat partition. However, NO entry is added to menu.lst at all (most likely due to the fact that I had to do some hacking to the unsupported app that does this magic, fooling it into thinking that the aptosid iso would actually be a 'Debian-Live' ISO. Looks as if the app got lost looking for some non-existent Debian file/directory within the aptosid ISO structure.

So it seems I'm 'almost' making aptosid boot from within this multi-distro setup - only thing missing is a working menu.lst entry, which could either point to the closed ISO or to the unpacked one.

I might as well just burn the ISO to some media and forget about all this stuff, but in this case I'd miss the whole lot of fun of tweaking things and inventing alternatives.

If, and I'm taking your word for it, the only remaining issue is an entry in /boot/grub/menu.lst, then why not simply open it and edit it, so it points to the bootable kernel image?

That's an easy answer... lack of sufficient knowledge on my part about grub's syntax options and functionality.

From my past experience with grub - and particularly in this case, where I might get entangled with grub1 x grub2 subtleties - I've learned that: (1) - reading grub manuals brings my brain to a halt. And (2) - if you can't get at least a halfway nudge in the right direction from some knowledgeable friend, random trial-and-error with grub syntax won't get you anywhere.

Quote:

BTW, your post will soon be moved to the "Dragons" part of the forum, as this pendrive linux maneuver is not a configuration supported by the aptosid team.

Well, since this maneuver is unsupported by the team, I'll not insist too much on it... albeit thinking there's a lot of people out there who can easily build grub recipes from the back of their minds, and who might offer at least some hints on this.

If your boot menu is controlled by a /boot/grub/menu.lst file, then that means your booting is controlled by legacy Grub. In that case, if you open the file, working as root, with a text editor, and scroll down to the last part where you see the menu items, you should be able to view the items that are booting correctly, and observe how the menu is constructed with hd(x,y) notation for drive and partition numbers.

Then you can insert a menu item for aptosid, using the same style of notation, but with hd(x,y) adjusted to reflect the drive and partition where you installed aptosid.

Or, since you are enjoying some mental gymnastics, you could install Grub2 (from your Aptosid Live CD or USB stick), and let it set up booting for your other operating systems.

If your boot menu is controlled by a /boot/grub/menu.lst file, then that means your booting is controlled by legacy Grub. In that case, if you open the file, working as root, with a text editor, and scroll down to the last part where you see the menu items, you should be able to view the items that are booting correctly, and observe how the menu is constructed with hd(x,y) notation for drive and partition numbers.

Thanks. I was preparing to ditch this plan and go for burning a CD instead, but of course I'll not waste the opportunity of one more try with your comments.

As I'm working from Ms-Windows and all distros are either files or folders within the same partition, there's no (x,y) notation anywhere in menu.lst. The working distros I have (Clonezilla and System Rescue) all have the same syntax on menu.lst with 3 commands each: find, kernel and initrd.

Quote:

Then you can insert a menu item for aptosid, using the same style of notation, but with hd(x,y) adjusted to reflect the drive and partition where you installed aptosid.

BTW, this was my original idea beforehand, anyway. What I was actually expecting from the forum was some hint as to which files would be the correct ones to use in these parameter strings, since aptosid seems to use an unfamiliar (to me) naming convention.

I'll leave out any cheatcodes for the moment, and would explore these later if aptosid boots at all with these entries.

Quote:

Or, since you are enjoying some mental gymnastics, you could install Grub2 (from your Aptosid Live CD or USB stick), and let it set up booting for your other operating systems.

Well, yeah, but that kind of defeats my original purpose - which was NOT to burn a CD in the first place. Sorta like having to open a drawer to retrieve a key to be able to open the drawer...

OK, so I'll give this a try later on and come back with my results afterwards.

With method 1 you probably just need to type "fromiso=TEST.iso" at the "initial options screen" and it will work. It can't work from an iso contained in a file without the fromiso option. If you rename the file from TEST.iso to aptosid.iso then you would just need to type "fromiso".

With method 2 you need to write your own menu.lst entry.

Assuming that you just unpacked the kernel and initrd from the iso and put them in the /boot directory on your drive, and call the iso aptosid.iso, then all you need in the menu.lst is

Thx a lot, bfree & dibl for your input. The issue is now solved, and there's a lot of stuff I want to report - read below.

[rant]

Disclaimer: this block is offtopic, pseudo-technical, personal and entirely optional to read. It *might* also be a bit funny...

What follows below started just after I dared to say:

sdrubble wrote:

...miss the whole lot of fun of tweaking things and inventing alternatives.

well, I've actually missed an excellent opportunity to keep my mouth shut on above quote. This wasn't really fun at all for about 6 or 7 hours last night... the 'fun' lasted for only about the last 30 minutes of the battle, when things finally (and mercifully) started to click into place.

First of all, this was all done in an EEE 901 netbook, with no 'real' HDs or DVD drive inside. I also have all kinds of USB stuff hanging onto the poor little thing - mouse, keyboard, external monitor, hub, and not only one but TWO large external HDs.

I ended up performing around 30 or 50 reboots until finally done. Around 30% of these reboots were actually meaningless, and due only to an issue related to the specific HD unit I was performing this 'lab' onto. I suspect of some kind of USB power issue here, regarding either the machine BIOS, or its wiring, or maybe the HD itself, or maybe to the sum total of the external paraphernalia feeding upon the netbook. The issue, (which BTW DOES NOT happen at all with the second [newer] external HD), makes it become frequently invisible to the BIOS after a reboot or poweroff, and exactly when I want to boot from this HD. After the system boots, the HD behaves normally (only a bit slow).

An additional issue was not being able to access my 2nd machine while doing the interminable GRUB experiments, what would have been helpful in order to speed up Internet searches and editing files. As a boot to WinXP on this box takes around 12 minutes before it becomes half-useful, I preferred to boot to SystemRescueCD instead of Windoze for doing searches and fixes after each GRUB failure.

Adding insult to injury, my copy of SRCD has no reliable persistence (have to re-config lotsa stuff again and again, on each boot), and... SRCD boots - or NOT - from the same quirky HD. Aaaargh !!!

But wait, that's not all - there's still more suffering and unenjoyable self-improvements to report...

I had assumed that grub4dos was just a port of the original grub 0.97, and scratched my head countless times while chewing docs before finally finding out that it's a 'little bit' different from its father. More on this on item 02, after this 'rant'.

And finally, I've spent many of the multiple edit-reboot-reboot-reboot-grub-failure-reboot-reboot cycles following a grub syntax tip which had a 'slight incorrection', received right here from you guys... gory details will appear further below on item 04, after this 'rant'.

Okay, you can now laugh your heart out of all of these ridiculous details - that's what I ended up doing anyway, after all was done and solved and I could finally go to bed and 'rest in peace' at 03:00 in the morning.

01 - Just for the record: GRUB is very unforgiving (guess it HAS to be so), and its error messages might be quite misleading (not so sure if it also HAS to be so). On one instance, for example, parameters out of place were reported as 'bad file name' or some such. A good deal of analysis is needed to find out what's REALLY happening in a number of error cases.

02 - Grub4dos syntax (docs at http://diddy.boot-land.net/grub4dos/Grub4dos.htm) has a number of differences to GNU GRUB 0.97 (Manual at http://www.gnu.org/software/grub/manual ... rub.html). What I found is that some grub4dos commands (find and map, for instance) take additional '--xxx' switches which are non-existent in GNU GRUB. That makes a lot of difference when you forget which 'brand' of GRUB you're using and naïvely believe you can build & fix your syntax following the original docs from the father of all GRUBs.

Well, actually AFTER arriving at my final results it seems that my original ideas were a bit unclear, and at the time of my previous posts I wasn't myself understanding a whole bunch of the details involved... so congrats to yourself, as you actually understood what I WOULD be doing. And indeed, your comments DID help me quite a lot. I was about to give up on this pet project, when your post indeed prodded me to 'just one more little try'. Not little at all, by whatever measure!

which induced to me to a large number of failed attempts until at one point, while investigating one of GRUB's 'crystal clear' error messages, I finally managed to figure out that what you REALLY meant should have been:

º user has to manually type 'fromiso' at aptosid initial options screen
º user has to either rename the original ISO release-specific filename to a very generic 'aptosid.iso' (and therefore would want to take notes somewhere about WHICH release the file belongs to), OR else bear with manually typing 'fromiso=aptosid_long_release_specific_name.iso' at aptosid initial options screen.

this option does away with aptosid initial options screen (together with having to manually type 'fromiso'), and has none of the drawbacks of previous options.
------------------------------------------------------------------------------------------------
5.4 - aptosid ISO contents expanded into a directory of vfat partition, WITHOUT 'find' command

Not sure how I ended up deciding to put the kernel arguments here after initrd instead of kernel. Hope that one didn't distract you for too long and sorry.

Haha, easy matey... after the struggle is over all I see is the bright side of things.

Which in this case, means "lot of important stuff learned, in such a way as to NEVER be forgotten" !!!

And in any case, if it weren't for your post, I wouldn't have bothered to insist on this USB thing and would have to make do with burning a CD, which I didn't want to in the first place.

I hope you didn't feel let down by any of my pseudo-humorous comments. Brazilian humor is not always understood as such by other folks... and my personal variant of humor can sometimes be a particularly nasty one.

Cheers

muchan

Post subject:Posted: 13.05.2011, 21:11

Moderator

Joined: 2010-09-11
Posts: 469

OT, but just after reading your "rant", I first thought that in your place
I'd first take time to solve the problem of windows taking 12 minutes to boot...
(in general, people let so many unnecessary programs run background...
in minimalist setting Windows is much more confortable to use than its reputation. 8)

OT, but just after reading your "rant", I first thought that in your place
I'd first take time to solve the problem of windows taking 12 minutes to boot...
(in general, people let so many unnecessary programs run background...
in minimalist setting Windows is much more confortable to use than its reputation.

In that case, the real problem here would be ME, and not Windows. I love 'features' and can't really keep anything minimalistic enough for very long.

OTOH, the firewall and anti-virus alone take about 70% of boot time. As they always load LAST and block any system usage before that, time invested in tweaking would not compensate much.

Besides, when I'm not struggling with BIOS quirks or GRUB obscurities, I normally do an average of 2-3 reboots a week, so that boot time becomes an almost invisible issue.

On a side note, I'd never have expected to be discussing Ms-Windows on a specialized Linux forum...