Yes, fdisk will show IF any partition is flagged as "bootable"
But Linux doesn't require that flag (M.S. does > I/Out portion of intiate instructions)

Further, a loader may be "chained".... for BIOS to find/read contigous boot bytes

Recall, after install - Initrd is NOT a requisite to boot - only the loader to point BIOS to
2nd stage of initiation sequence.
Users often confuse - the MBR is located on First hard drive FOUND containing initial boot data:
That device need NOT be hda !!
Change cabling -or Bios boot sequence - where the first loader instruction set was installed will not necessarily be found by BIOS

Boot instructions may reside on other media (I.E. Syslinux-there are others)

Bobn9lvu: I think that Sage keeps complaining about Grub not being able to boot scsi. Is that so? If so it's a matter of using Lilo (I might get to that…).
However, you also need the init to be able to boot scsi… Jesse just tried my modified version with a scsi drive and it worked, but froze in rc.modules… so that's another hurdle in the way to booting off scsi drives.

No, once installed onto a scsii drive, Grub WILL boot, but when the kernal
gets loaded, it does NOT recognize the scsii drive and locks up the system
where only a hard reset will work to "try" and fix problem...
I had it work just fine from the MBR of a scsii drive but thats as far as it got.

I was able to select any of the menu entries I had made.

Puppy was one, and freedos was the other, and freedos booted just fine... through grub..

Dougal, I am impressed! It worked like a charm! The installer saw the partitions on the hdc drive and installed Puppy on /mnt/hdc2 exactly like I wanted.

I did have a little problem at first, of no /boot dir being created, but I think that was because I opted out when it moved on to the grubconfig part. I figured I didn't need to configure it because I already had it installed (on my old Puppy installation). I intended to simply go in later with a text editor and edit the old menu.lst file to start my new Puppy installation. But with no /boot dir on my new Puppy installation grub wouldn't be able to unpack and run the vmlinuz file (because it lives in /boot).

So I backed up the old menu.lst file in case of stuff-ups, ran the installer again, this time continuing thru the grubconfig sequence, and all ended well.

Thanks Dougal. I'm very grateful.

As a few people have mentioned, the choice between the 2 kinds of install -- option 1 and option 2 is somewhat harder to read than need be, though much, much better than previously. I'll look at it and see if I can't work out a simpler way to make that bit.

Hmmm... I just noticed an odd thing... Grub appears to misdiagnose my Puppy partition as ext2fs, when it is actually ext3fs. Doesn't seem to be a problem though. It boots fine._________________A life! Cool! Where can I download one of those from?

...I did have a little problem at first, of no /boot dir being created, but I think that was because I opted out when it moved on to the grubconfig part...I figured I didn't need to configure it because I already had it installed (on my old Puppy installation). I intended to simply go in later with a text editor and edit the old menu.lst file to start my new Puppy installation...

...ah, thank you miriam, I see now: the PUI creates the boot subdir, I assume now, after I choose to install grub!

This was a stopper for me because I have not yet used mbr grub, rather I have had (up to now) only fat32 (vfat) partitions all around and so have been running grub.exe from an autoexec.bat line. Exactly as miriam, I intended to simply go in later with a text editor and edit the old menu.lst file to start my full hd Puppy installation.

I presume then, that an mbr grub will be created, but that I could then get rid of it using (from a Windows 98SE boot floppy) fdisk /mbr, and then boot Puppy from live-CD and transfer the newly-created /mnt/hdb2/boot/grub/menu.lst settings to my pre-existing /mnt/hda1/boot/grub/menu.lst, so as to retain the option of my multi-Puppy setup started using autoexec...

...but then the question arises: can grub.exe, started from an autoexec.bat in a vfat partition...even see my ext3 hdb2 partition in the first place, to boot the contents of its /boot subdir?

I think I might actuall give up the idea of searching for where Grub is installed and just look for the menu file... that way I can just search for the grub menu file and the Lilo menu file and use that to determine.

Bob9lvu: As I mentioned, Jesse managed to boot with the scsi drive... Maybe you encountered a problematic kernel module?

Gn2: I think maybe the simplest way will be to not care where grub/lilo is installed, but just find the config file and modify it. The different "naming scheme" (hd0) is simply derived from the order devices are listed by fdisk -l so I can just use that…

The only problem with the output of fdisk is the fact that it can't handle a "superfloppy"… it give "no valid partition table". But I've found a way to bypass that (if you get that -- try "file -Ls" on device to find it's fs).

Using /dev/dvd and /dev/cdrom is something I've started doing when I created an app that finds devices and adds links to your desktop -- for easy mounting. I figured users will find it easier to understand what "cdrom" and "dvd" (or "cdrom2" if it's just two cd-drives) refer to…

Miriam: thanks, I've replied in the other thread.
As for the dialogues… I'm trying my best, but haven't gone over all of them and there's always that very convoluted base (Barry's text) that I'm trying to stick to…

SHS: I have no idea why the /boot partition is only created after you are asked about installing grub -- maybe more incoherent text… I'll have a look at that.
I'm also not sure why Barry uses those strange shell scripts for doing part of the work (those scripts are **created** by the installer! Why not just have the code in the installer and use a dialog to communicate with the user?). Will look into that, too.

I have also replaced the use of /dev/dvd and /dev/cdrom with the actual devices and will hopefully have an updated version later today.

Rerwin: I was wondering if I should use /dev/cdrom /dev/dvd or actually look for devices… the reason I chose it this way was
1) laziness… couldn't be bothered doing the whole looking for cdroms
2) it seemed simpler to write the code this way. I guess I could just create a loop that goes through the cdroms
3) I try and assume that if the code in rc.local0 does a lot to check the drives, then the links are ok…

I'll see, I might just go to using device names (not rely on anything…).

The wizard is beyond my control…

The last, first: The wizard is only the messenger here -- it is not the problem. But it reports that the autodetection during initialization made a bad CDROM guess. I thought I saw your name in one of the initialization scripts -- that's why I mentioned the problem in this thread.

I support your use of the already-set-up /dev/cdrom & -dvd links. A common coding goal is to eliminate duplicate logic where possible, to simplify code maintenance. Grafburn also uses the links and got "burned" by the erroneous setting -- once I ran the wizard to correct the cdrom link, both the installer and grafburn worked as expected.

My recommendation would be to continue to use the links but beef up the code to handle CDROM/DVD errors by referring the user to the wizard, to ensure the device is correct -- not to duplicate the discovery & user-override code, which is already in initialization and manually overrideable via the wizard.

The problem, now, is to correct the init/local0.rc code before it makes its way into the standard puppy. Should I start another thread about this? I see that 2.16a seems to use the 2.14 discovery logic, so the problem has not surfaced there, yet. I can try to work the issue, but will take my cue from you, since you might have some insight into what happened to the discovery logic.

Please don't view this as denigrating the hard work/great results of contributors to Puppy community:
--------------------------------------------------------
It is up to user preferences how to use his own system -
But rc.local should NOT be used to mount devices !
That folder is for "customised" initiations > E.G. Vlan, wireless, Apps to directly enter

There seems to be growing trend to advise it's use as a "catch-all" remedy to correct buggy automated
BASIC system configurations.

Such habits may be fine for individual use (Tmp work-arounds) but IMO
not good practice for version releases to public

Use of "generic" device names is also inadvisable
Use of the correct BLOCK device obviates such as cd/dvd/sdo ad-nauseum
That is S.O.P for 'Nix > eliminates obfuscated symlinks !
BTW - also obviates HOW to create device nodes > how Udev & populates /proc folder or how E_IOCTL works

If a user later wishes to re-name devices to anything they think more suitable,
at least they KNOW how to edit names in fstab/loaders/directories

The majority of W/Mgrs parse those directories -create icons
IMNSHO > Icons are eye-candy, not a necessity - as such, the only remedy is to learn your own system -
all is "generic" Linux
Wizards that work hinder that learning process
Wizards that fail - increase the work load to underlying events
all that we eventually must face, else ever depend on others ?

Best regards to all (Esp to all the time/load -stressed prolific contributors such as Dougal)

The incorrect CDROM and DVD device identifiers are obtained during the initial boot from CD, which, in 2.15CE, contains three leftover files that should not appear in the iso. They retain CD/DVD info across reboots, so Puppy thinks the values have already been determined for the current installation. The design, apparently, is for the files to be built when Puppy is first run on an installation, so must not exist at that time. This is the case in both 2.14 and 2.16.

The files are: /etc/cdromdevice, /dev/cdrom, and /dev/dvd. There also should be no /etc/dvddevice file; and there is none in 2.15.

It appears, to me, that the built version was run on before the iso was made, so picked up the devices used in the run -- hdb; that should be an unusual setup, so might suggest where the run was made.

I expect this to be of interest to WhoDo. The built release must not be run before cutting the iso -- a copy should be used for testing, not the set going to the iso. I wonder if there might be other instances where persisent data intended to be generated fresh for each installation got left in 2.15. Whoever ran the test might remember which functions were used and might be affected.

Anyway, I am glad there is no logic error. Build errors are to be expected as the release-build responsibility moves around.

It appears, to me, that the built version was run on before the iso was made, so picked up the devices used in the run

Or was just created by remastering, rather than using Puppy-Unleashed...

The devices are supposed to be re-checked every boot, I think -- at the beginning of rc.local0._________________What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

It appears, to me, that the built version was run on before the iso was made, so picked up the devices used in the run

Or was just created by remastering, rather than using Puppy-Unleashed...

Puppy 2.15CE Final-R2 was remastered. There was only one bugfix relating to alsaconf, so I didn't rebuild but just remastered from a clean install. Obviously it has picked up some of my configuration in the process. I never mess with /etc when remastering because I don't know enough about it.

Sorry for the problem, guys.

BTW, I lost my entire Unleashed setup before the remaster so there was very little choice. I'm still trying to find a copy of the Unleashed tarball so I can rebuild it. That hasn't been uploaded back to ibiblio.org since the crash.

Cheers_________________Actions speak louder than words ... and they usually work when words don't!
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com

Updates:
1) Fixed the problem with cdrom detection Rerwin had.
2) (Hopefully) fixed the problem SHS had with the missing kernel after a full install.
3) Added auto-detection of existing Grub installation and option to add an entry to the boot menu.
4) Some other things, some of which I already forgot…

Note that when I add Grub entries, the kernel (and initrd.gz if it's a frugal install) is NOT copied just into /boot/ -- since there's probably one in there already -- but into /boot/puppy214/ (or whatever your version is).

Please try this out to make sure it works ok.

Lilo users: if anyone can give me an example of how a Puppy entry in the lilo.conf should look like (especially for a frugal install) then I can add that, too.

Someone asked here before for the option to install an older version of Puppy. I don't think it's worth encumbering the installer with this as it's not likely something most users will want and there's a very simple way of doing it:
Say you're running 2.14 and want to install 2.02.
Before you start the installer, open a terminal and run

Code:

echo -n '202' >/etc/puppyversion

Then run the installer and it will look for 2.02.
After you're done, just open a terminal again and run

Code:

echo -n '214' >/etc/puppyversion

That's it._________________What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

Dougal; I just posted for a WD-Seagate type of HD setup disk that can be redistributed.

A generic utility boot floppy or USB to partition & format ext2-3 & fat32.
Then the option to install an OS to any partition, & then install SysLinux or Grub.

I'm not sure what all your Puppy installer does, but it sounds close.
I messed with SlimLinux for this, but it doesn't have Xdialog, so no GUIs.
I'd really rather not reinvent the wheel just to get a basic boot utility tool kit.

I have modified the Puppy Universal Installer and fixed some bugs. (I used the one from 2.14)

Please try it and report how it works.

If you have any requests concerning it, NOW is the time to make them.

I have one question, in case someone can help:
I have enabled installing to USB harddrives just like internal harddrives, but there's a comment of Barry's about USB harddrives needing syslinux -- in fact being installed like USB flash drives.
Does anyone know anything about this? I could easily make a distinction between "internal" harddrives and have the "externals" (USB) grouped with USB flash drives and installed like them.

Please see first post of the following link.

http://www.murga-linux.com/puppy/viewtopic.php?t=17601&start=30

Not sure if you indicating you can easily determine if the USB attached device was a flash/Compact Flash or actual hard drive. If so, a similar technique might solve the problem I describe in my post.

Thanks Much!
Regards
Ron

BTW... I believe your universal installer is one of the best features puppy offers. Thanks VERY much for your work on the Universal installer.

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 vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum