Pup214R v1.00 - Puppy Linux 2.14 Revisited, is now available

News, happenings
Message
Author
User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

grubby little details

#121 Post by prehistoric »

@Dougal

First, an apology for not testing and reporting the results of your pet to fix the grub menu.lst problem on frugal installs. My test machine was disassembled until yesterday. You were correct in your assumption, the problem showed up in a case where grub had not previously been installed. I reformatted the disk and tested in the same configuration that failed before.

The files are all copied to /boot/puppy214R, (I normally put the puppy directory up in / where it is more visible,) but menu.lst won't boot because of several errors. (The error code is from memory. I don't guarantee the errors are letter for letter what I found.)

Code: Select all

title Puppy Linux 214R, frugal (on hda1)
rootnoverify (hd0,0)
kernel /boot/grub/vmlinuz root=/dev/hda1 root=/dev/ram0 PMEDIA=idehd 
initrd /tmp/boot/boot/puppy214R/initrd.gz
Note the two roots on the kernel line and the strange location of initrd.gz. Boot failed by not finding vmlinuz.

This was manually edited to a working configuration.

Code: Select all

title Puppy Linux 214R, frugal (on hda1)
rootnoverify (hd0,0)
kernel /boot/puppy214R/vmlinuz root=/dev/ram0 PMEDIA=idehd psubdir=/boot/puppy214R
initrd /boot/puppy214R/initrd.gz
My own preference is to make psubdir=/puppy214R. This stays the same, regardless of whether or not any other Linux is installed on that partition, and is easy to find. If the partition is used as /home by another system, a boot directory is confusing.

Again, my apologies for not testing sooner. Your fast response to the problem simply got overlooked. If I was younger I would be in that code messing around. You're probably lucky I am not.

prehistoric

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

Re: grubby little details

#122 Post by Dougal »

prehistoric wrote:The files are all copied to /boot/puppy214R, (I normally put the puppy directory up in / where it is more visible,)
Are you sure all of them are in the subdir? The installer is supposed to only put the kernel and initrd in there -- the sfs files should go at the top level of the partition you chose to install Puppy to.
My own preference is to make psubdir=/puppy214R. This stays the same, regardless of whether or not any other Linux is installed on that partition, and is easy to find. If the partition is used as /home by another system, a boot directory is confusing.

The idea of the boot directory is that it's on the boot partition and that's where all boot-related files go -- so if you have a few versions installed, all the kernels and initrd's go in there.
Attachments
grubconfig.gz
(13.55 KiB) Downloaded 566 times
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

.sfs

#123 Post by ttuuxxx »

One thing I noticed when using puppy2.14r and .sfs files is that you can't just click on them to mount and view them, unlike the puppy 3.0 series, you click and look inside, In puppy 3.0+ they mount with a single click and disable the same way, very handy when your build your own custom version. Or just want a file etc.
thanks for your time ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

Re: .sfs

#124 Post by Dougal »

ttuuxxx wrote:One thing I noticed when using puppy2.14r and .sfs files is that you can't just click on them to mount and view them, unlike the puppy 3.0 series, you click and look inside, In puppy 3.0+ they mount with a single click and disable the same way, very handy when your build your own custom version.
That's intensional, as I don't believe laymen should have sfs files auto-mounted (I just press Ctrl+! and then type "mount -o loop file.sfs /mnt/data").
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

where to put Puppy files?

#125 Post by prehistoric »

@Dougal

The idea of putting everything in one Puppy folder is my own, it helps keep down confusion about which system uses which files, particularly if you have multiple versions of Puppy. I need to go back and check on exactly what the frugal install did by default. This time I'll get exact copies for you.

On my Gentoo system /boot is a separate 130 MB partition, which is only mounted when I want to change kernels or booting. This has plenty of space for booting systems built under Gentoo, but I have enough confusion about which kernel I'm testing under Gentoo, I don't want foreign kernels in there, and I don't want to wipe out Puppy with a change to a Gentoo script under test. (The Gentoo machine is down at the moment. I just brought two machines back up, so having one down is par for the course.)

Damn Small Linux is another example of Linux with frugal installs, which can coexist in partitions with other systems. Several other systems now use squashfs files. (Just checked TinyFlux 1.0, which at least uses a different extension.) Placing these directly at the root of the directory tree has already caused me trouble with Puppy variants. Since we need a Puppy directory for kernels, initrd and sfs files I feel there should be a single directory with all, a personal preference.

Several local people who have tried Puppy have called me with questions. I've learned to find out if they have previously tried several versions. Getting one file from one version and another from a derivative is a recipe for chaos and madness.

Incidentally, I agree with what you told ttuuuxx about mounting sfs files. People who don't have a clue really can get in a mess. Trying to find out what happened afterwards, when they didn't know to begin with, is a lost cause.

Please don't take any reports of bugs as personal criticism. There are good reasons for my reporting a problem with the grub install script rather than trying to fix it myself. I'm not up to speed on Puppy, and at the rate it moves I may never catch up.

Thanks for a useful and interesting puplet. Keep up the good work!

prehistoric

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

re: Grubby little details

#126 Post by prehistoric »

@Dougal

I'm posting this from the machine used for testing installs. Just did a frugal install of 2.14R using v 1.01 plus the grubconfig you just attached to your post. Hope this was what you intended.

With another Linux installed on hda6 and hda1 (formatted ext2) empty, the install worked as advertised, and I was able to boot either system.

After hiding (renaming) /boot on hda6 , and reformatting hda1, I did a frugal install to hda1 and found this entry in the resulting /boot/grub/menu.lst.

Code: Select all

# Linux bootable initrd config begins
  title Puppy Linux (frugal) install on /dev/hda1
  rootnoverify (hd0,0)
  /boot/puppy214R/vmlinuz /boot/vmlinuz root=/dev/hda1 root=/dev/ram0 PMEDIA=idehd
  initrd /boot/puppy214R/initrd.gz
# Linux bootable initrd config ends
Here is what I found in /boot/puppy214R:

Code: Select all

sh-3.00# pwd     
/mnt/hda1/boot/puppy214R
sh-3.00# ls
initrd.gz  pup_214R.sfs  vmlinuz  zdrv_214R.sfs
sh-3.00# 
Also confirmed that the script in v 1.01 has similar problems.

This is no problem for me to change, but would put off a newbie.

Hope this helps. I'm not confident of making changes in that script.

prehistoric

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

Re: re: Grubby little details

#127 Post by Dougal »

prehistoric wrote:

Code: Select all

# Linux bootable initrd config begins
  title Puppy Linux (frugal) install on /dev/hda1
  rootnoverify (hd0,0)
  /boot/puppy214R/vmlinuz /boot/vmlinuz root=/dev/hda1 root=/dev/ram0 PMEDIA=idehd
  initrd /boot/puppy214R/initrd.gz
# Linux bootable initrd config ends
Oops... that's a silly little mistake on my behalf that causes the wrong kernel line -- removed $1 from awk code...
Other than that, I think it is ok.
Here is what I found in /boot/puppy214R:

Code: Select all

sh-3.00# pwd     
/mnt/hda1/boot/puppy214R
sh-3.00# ls
initrd.gz  pup_214R.sfs  vmlinuz  zdrv_214R.sfs
sh-3.00# 
Also confirmed that the script in v 1.01 has similar problems.
Ok, I'll have a look at it.
This is no problem for me to change, but would put off a newbie.
Sure, it's better that you report to me than just fix it for yourself! This way I can fix the bug once and for all.
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

reckrhodes
Posts: 116
Joined: Wed 30 May 2007, 08:15

#128 Post by reckrhodes »

Just a little off topic. Is there any possibilities that this version of puppy will include the gslapt of Puppy 3.01? Because I like this Revisited version as a base for a customised puppy, its so fast in my laptop (Thinkpad T23).

Thank you very much.

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

#129 Post by Dougal »

reckrhodes wrote:Is there any possibilities that this version of puppy will include the gslapt of Puppy 3.01?
No, the filesystem in 2.14 doesn't match the Slackware libraries, so you'll have compatibility problems. (there was, however, a thread about adding Gslapt to Puppy prior to 3.0, so you might be able to install it and get it to work somehow).
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

Re: where to put Puppy files?

#130 Post by Dougal »

prehistoric wrote:Damn Small Linux is another example of Linux with frugal installs, which can coexist in partitions with other systems. Several other systems now use squashfs files. (Just checked TinyFlux 1.0, which at least uses a different extension.) Placing these directly at the root of the directory tree has already caused me trouble with Puppy variants. Since we need a Puppy directory for kernels, initrd and sfs files I feel there should be a single directory with all, a personal preference.
The reason I put the kernels and inird's in the /boot partition is for the same reason you have such a partition on your Gentoo machine: that partition has all the boot-related files and is used only when booting (I have a 50MB ext2 partition for it).

There is one reason why I am willing to change to having all Puppy files installed to one subdir: to keep things tidy. That way you just need to delete the pup214R directory and you've finished "uninstalling" (except for the grub entry).
In fact, I have now modified rc.shutdown so that on first boot it checks if you've booted from a subdir and then offers you to create the pup_save inside it.

So I went over the installer and modified it to put all files in $DESTMNTPNT/pup214R/ and spent quite a while going over the ugly kludge which is grubconfig and modified it to work with it, too.
I had only one thing I wasn't sure about: when Barry introduced the subdir option, he modified the installer so the grub entry includes the drive number not only in the root/rootnoverify line, but also in the kernel and initrd lines. For example:

Code: Select all

title Puppy Linux 214R, frugal (on hda1)
rootnoverify (hd1,1)
kernel (hd1,1)/boot/puppy214R/vmlinuz root=/dev/ram0 PMEDIA=idehd psubdir=/boot/puppy214R
initrd (hd1,1)/boot/puppy214R/initrd.gz
Now, I always thought it was unneccesary -- the "root" line tells it where the root is...
Anyway, I decided to check: I have a full install on hdb2, so I created the directory /mnt/hdb2/boot and put the kernel in it, then modified the grub menu to say

Code: Select all

root (hd1,1)
kernel (hd1,1)/boot/vmlinuz ...
and tried booting it.

I got an error (#21) from Grub: no such disk.
I tried playing around with with the grub shell and discovered that grub cannot see my hdb!!
I don't know what the deal is -- it's an old IDE drive, connected as primary slave -- but grub just kept offering me only hd0 and fd0...

So it seems like we're staying with having all the boot files in the boot partition...
Attachments
pup214R-installer-Dec-18th.pet
(32.59 KiB) Downloaded 580 times
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

re: Grubby little details

#131 Post by prehistoric »

@Dougal

Just ran your latest grubconfig (18 Dec) from the v 1.01 disk. On the first try I renamed the boot directory in the linux installation on hda6 to hide it, and formatted hda1. Did a frugal install to hda1. Everything went like clockwork and the system booted as intended.

Round two: formatted hda1 and rerenamed /reboot on hda6 back to /boot. This time grubconfig did not complete the install of grub. (I may have confused it by leaving entries in menu.lst for earlier installs.) This time it made a bizarre contribution to menu.lst

Code: Select all

# GRUB configuration file '/boot/grub/menu.lst'.
# generated by 'grubconfig'.  Wed Dec 19 12:38:18 2007
#
# The backup copy of the MBR for drive '/dev/hda' is
# here '/boot/grub/mbr.hda.1878'.  You can restore it like this.
# dd if=mbr.hda.1878 of=/dev/hda bs=512 count=1
#
# Start GRUB global section
#timeout 30
#color light-gray/blue black/light-gray
# End GRUB global section
# Linux bootable partition config begins
  title Linux on (/dev/hda1)
  root (hd0,0)
  kernel /boot/vmlinuz root=/dev/hda1 ro vga=normal
# Linux bootable partition config ends
# Linux bootable partition config begins
  title Linux on (/dev/hda6)
  root (hd0,5)
  kernel /boot/vmlinuz root=/dev/hda6 ro vga=normal
# Linux bootable partition config ends
# Linux bootable initrd config begins
  title Linux initrd /tmp/boot/boot/initrd-2.6.18.8.tex5.lgc.img on (/dev/hda6)
  root (hd0,5)
  kernel /boot/vmlinuz root=/dev/hda6 ramdisk_size=282 root=/dev/ram0 rw
  initrd /tmp/boot/boot/initrd-2.6.18.8.tex5.lgc.img
# Linux bootable initrd config ends
title --- For help press 'c', then type: 'help'
root (hd0)
title --- For usage examples, type: 'cat /boot/grub/grub.txt'
root (hd0)
There is an old problem here, which people have been living with, grubconfig generates menu entries for linux partitions with no vmlinuz. This is obviously not urgent.

The initrd line for the system on hda6 is another matter entirely. That system will not boot unless it is changed. No idea what grubconfig thinks is going on.

My own preference here would be to add an entry for Puppy to the existing menu.lst, or even write the entry to a separate file and let the user edit it in. If the system is booting with Grub from an existing Linux installation we should do nothing to prevent that from working.

The "foreign" Linux system here is TinyFlux 1.0. I've been using that for testing because it is relatively small (235 MB) and quick to install, and it is a cut down version of PCLinuxOS, which is currently at the top of distrowatch's list. (If they consider 235 MB tiny, what would they call Puppy?)

What you have now will handle the most common cases: frugal install with no previous Linux and install to a flash drive. (Unless the latter has changed since I last tested.) If you see an easy fix, then go for it. If not, a small stable system with live CD, flash drive install and frugal install which works in most cases is worth releasing, as is.

Regards,

prehistoric

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

Re: .sfs

#132 Post by ttuuxxx »

Dougal wrote:
ttuuxxx wrote:One thing I noticed when using puppy2.14r and .sfs files is that you can't just click on them to mount and view them, unlike the puppy 3.0 series, you click and look inside, In puppy 3.0+ they mount with a single click and disable the same way, very handy when your build your own custom version.
That's intensional, as I don't believe laymen should have sfs files auto-mounted (I just press Ctrl+! and then type "mount -o loop file.sfs /mnt/data").
So basically in a nutshell you want to complicate .sfs because you think new users are "laymen". and you have no support for slackware/Gslapt and by reading on don't want to. Really Dougal I really liked 2.14R. But I must say its a bit to swallow, that you want to complicate something that is simple and works well for the one out of 100 users that might muck something up looking into .SFS file. Couldn't you just have a notice like " Be Careful or Use at Own Risk or Are you Sure"??? Not type 34 characters/keys including spaces! Really are you a coder or do you like GUI? I'm not trying to argue and tell you how to do your thing, But when I feel something is wrong I always voice my concerns, If it falls on death ears then at least I tried.
ttuuxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
jcoder24
Posts: 604
Joined: Fri 06 May 2005, 12:33
Location: Barbados

#133 Post by jcoder24 »

sfs = squashfs = "a compressed read-only filesystem for Linux" emphasis on read only..

Quotation from squashfs.sourceforge.net.

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#134 Post by ttuuxxx »

jcoder24 wrote:sfs = squashfs = "a compressed read-only filesystem for Linux" emphasis on read only..

Quotation from squashfs.sourceforge.net.
Thats why I like the click and run way, I can visit my changes I've made and extract icons, themes etc. put to type 34 keys is just a pain, or click or 34 keys compare?hmmmm
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

jamesbond
Posts: 3433
Joined: Mon 26 Feb 2007, 05:02
Location: The Blue Marble

#135 Post by jamesbond »

Just downloaded 2.14R 1.01 ... thinking whether I should "upgrade" my faithful 2.15CE, and immediately noted one thing: Gxine doesn't play fullscreen (on Xvesa)?
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#136 Post by ttuuxxx »

jamesbond wrote:Just downloaded 2.14R 1.01 ... thinking whether I should "upgrade" my faithful 2.15CE, and immediately noted one thing: Gxine doesn't play fullscreen (on Xvesa)?
Hey jamesbond basically gxine is not good at all with the 3.0 series and should be replaced with xine-gui which work full screen. or vlc or mplayer which ever you choose.
Actually I would give it maybe a few weeks before replacing 2.15ce since this version is getting better day by day. I only replaced the 2.15ce I had only After I made My "Fire Hydrant".
Any which ways have fun and Merry Christmas
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

Re: re: Grubby little details

#137 Post by Dougal »

prehistoric wrote:Round two: formatted hda1 and rerenamed /reboot on hda6 back to /boot. This time grubconfig did not complete the install of grub.
Something doesn't make sense here: if you already have Grub installed (to /boot/grub on one partition), the installer should add the entry to it and grubconfig won't run at all! Could it have missed the file? (function find_grub_install in the installer)
There is an old problem here, which people have been living with, grubconfig generates menu entries for linux partitions with no vmlinuz. This is obviously not urgent.
I never heard of it before, but it seemed to me like that might happen, from looking through the code -- but only in the "simplegrub" case, where it seems to just search for Linux partitions and add entries for them...Fixed. (see loop starting at line 454)
# Linux bootable initrd config begins
title Linux initrd /tmp/boot/boot/initrd-2.6.18.8.tex5.lgc.img on (/dev/hda6)
root (hd0,5)
kernel /boot/vmlinuz root=/dev/hda6 ramdisk_size=282 root=/dev/ram0 rw
initrd /tmp/boot/boot/initrd-2.6.18.8.tex5.lgc.img
# Linux bootable initrd config ends
Ha! The reason the initrd with the funny name is found is that grubconfig searches for initrd*, but I guess it's ok, since that really is the file you want to use for TinyFlux.
What is funny here is that the reason it won't boot is something I mentioned in a previous post that I don't understand: I fixed this in the special Puppy-frugal section I added, but didn't rouch the normal case -- which obviously also needs modifying. Fixed.
My own preference here would be to add an entry for Puppy to the existing menu.lst, or even write the entry to a separate file and let the user edit it in. If the system is booting with Grub from an existing Linux installation we should do nothing to prevent that from working.
As I mention above, the installer already works that way: it finds menu.lst, then presents the user with a edit-box containing the proposed new entry and then inserts it.
Attachments
pup214R-installer-Dec-20th.pet
(32.9 KiB) Downloaded 517 times
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

re: grubby little details

#138 Post by prehistoric »

Hi Dougal,

This time we have a winner. As you observed there was something wrong with the previous test. (Faster than thought. :oops: ) When I reformatted and did the second install, I either forgot to restore the MBR or used the wrong backup. So, the Grub installation was broken, with an MBR for the hda1 install and everything else on hda6, with TinyFlux.

This time it generated a menu entry which would work, but failed to write it to the menu.lst on hda6. This is a tricky case where I think it is acceptable to have people edit menu.lst.

The only change I would make is to write the proposed entry to a tmp file and change the message to tell the user where to find it. Here's the menu.lst entry, including the previous working entry for the last puppy214R installation.

Code: Select all

title = Puppy 214R (frugal) on hda1
rootnoverify (hd0,5)
kernel /boot/puppy214R/vmlinuz root=/dev/ram0 PMEDIA=idehd psubdir=puppy214R
initrd /boot/puppy214R/initrd.gz

title Puppy 214R (frugal) on hda1
kernel (hd0,5)/boot/puppy214R/vmlinuz BOOT_IMAGE=Puppy_214R_(frugal)_on_hda1 root=/dev/ram0 PMEDIA=idehd
initrd (hd0,5)/boot/puppy214R/initrd.gz
The BOOT_IMAGE argument was generated by the TinyFlux (PCLinuxOS) installer. It does nothing for puppy, except explain where it is getting the sfs files. I had previously hand edited that entry to make it work.

Your ordeal is over. You can forget Grub in the near future. Thanks for your attention and patience.

prehistoric

User avatar
HairyWill
Posts: 2928
Joined: Fri 26 May 2006, 23:29
Location: Southampton, UK

#139 Post by HairyWill »

Dougal
I'm having problems resizing my pup_save, it is installed on an ext3 partition.

I have also booted off another partition and fsck.ext3 reported that my 214R partition is being unmounted uncleanly. This seems to happen every time I shutdown 214R.

I may have run fsckext2 on the partition and pup_save at one point, I don't know if this could be the cause of my problems.
Here's there error when trying to resize

Code: Select all

Forcing filesystemcheck on /pup214_save.3fs before resizing      done
Increasing /pup214_save.3fs by 65536 Kbytes please wait          failed
Dumping last lines of /tmp/bootinit.log...
65536+0 records in
65536+0 records out
resize 1.40.2 (12-Jul-2007)
ext2fs_check_mount_point: no such file or directory while determining whether /m
nt/dev_save/pup214_save.3fs is mounted
Dumping last lines of kernel log...
<4>EXT2-fs warning (device hda3): ext2 fill_super: mounting ext3 filesystem as e
xt2
<4>EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
<4>EXT2-fs warning (device hda3): ext2 fill_super: mounting ext3 filesystem as e
xt2
<4>EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
Will
contribute: [url=http://www.puppylinux.org]community website[/url], [url=http://tinyurl.com/6c3nm6]screenshots[/url], [url=http://tinyurl.com/6j2gbz]puplets[/url], [url=http://tinyurl.com/57gykn]wiki[/url], [url=http://tinyurl.com/5dgr83]rss[/url]

User avatar
Dougal
Posts: 2502
Joined: Wed 19 Oct 2005, 13:06
Location: Hell more grotesque than any medieval woodcut

Re: re: grubby little details

#140 Post by Dougal »

prehistoric wrote:This time it generated a menu entry which would work, but failed to write it to the menu.lst on hda6. This is a tricky case where I think it is acceptable to have people edit menu.lst.
What do you mean, the installer showed you the right entry in the edit-box but then didn't add it?
I think I know how something like that could happen -- it's something I've been needing to find a solution for for a long time:
I need to know where to squeeze in the entry from a script, so it doesn't go in the middle of a different entry (and you don't want it at the far end, after the extra grub options...).
What I currently use is the lines of the type

Code: Select all

#bootable linux...begins/ends
But if grub was installed by a different installer, you might not have such lines... so I need to find a sure way of knowing where to squeeze it in.

Your ordeal is over. You can forget Grub in the near future. Thanks for your attention and patience.
Maybe... when I fixed the problem of Linux partitions being added by grubconfig even if they don't have a kernel on them I copied some code for it and forgot to make a little adjustment... which resulted in it not adding any partitions... Fixed.
Attachments
pup214R-installer-Dec-22nd.pet
(32.97 KiB) Downloaded 511 times
What's the ugliest part of your body?
Some say your nose
Some say your toes
But I think it's your mind

Post Reply