laprjns wrote:
Similar thing happen when selecting locale after having selected one of the bottom three items.
The second problem is that although the installer detected my Xp partition and provide a choice of mount point, it didn't appear that it was going to mount it on the mount point I selected, See screen shot :
Image
Had this problem, too. Happens when you don't unselect (i.e. confirm) what you've entered into the mountpoint field. (It should look like the one to its left.)
laprjns wrote:The first is that if I selected either keyboard or locale after selecting any of the other three items (Partition, Users, Packages), the dialog area seems to get over written without clearing the prior selection. Here a screen shot:
I got this screen once too, but thought it was just me trying to tick a tab-selected checkbox with enter instead of space.
JRD wrote:@laprjns : my script is not perfect. It should work if you remove the trailing slash :
Code:
./install-on-USB ../Download/salixlive-13.0-beta2.iso /media/disk
What about adding a check whether grub-install comes from a grub2 install. I don't want users to start complaining that their Slackware grub (legacy) fails.
(Limiting it to grub2 1.97 and greater should be fine, 1.96 is so unstable I wouldn't bother with it. It's probably incompatible too.)
JRD wrote:P.S. For Windows users who want to put the ISO on USB, I'm currently making a batch script for them.
I'm interested how you plan to install grub2 from Windows?
laprjns wrote:Also, prior to running the installer, I created a 512M swap partition, but the installer never indicated that it had detected it nor did it ask for one. Not sure if this is a problem or not.
I think I saw it somewhere during the fstab step in the code.
What about adding it to the really install dialog:
Code: Select all
Deteced (and used) swap partitions:
* /dev/blub xyM
...
I should really learn this python stuff, though I understand the programs, I don't quite get how it works.
EDIT:
Oh and nearly forgot:
@JRD: I think the ext4 as ext3 issue comes from blkid. Because Salix's does it right (try it yourself su -c 'blkid' on a computer with ext4 partition), there must be another one on the initrd. Probably in the usr.lzm package of the initrd.
EDIT2:
@JRD: Forget about it. Seems like blkid isn't the problem. But I found this interesting (on the ext4 wiki):
It is possible to mount both ext3 (and ext2, in kernels 2.6.28 and later) filesystems directly using the ext4 filesystem driver. This will allow you to use many of the in-core performance enhancements such as delayed allocation (delalloc) and multi-block allocation (mballoc), and large inodes if your ext3 filesystem have been formatted with large inodes as is the default with newer versions of e2fsprogs. Simply mounting an ext3 (or ext2) filesystem with a modern (2.6.27+) version of ext4 will not change the on-disk structures, and it is possible to revert to the ext3 (or ext2) driver should there be any problem with ext4. If you plan to use the ext4 driver to boot from an ext2/3 partition, and you compile your kernel without the ext2/3 drivers, you may need to add rootfstype=ext4 to the kernel command line.
http://ext4.wiki.kernel.org/index.php/E ... em_to_ext4
Sounds like we could open extX disregarding the version with ext4 (and gain performance additionally).
EDIT3:
I got blkid to detect ext4 properly, at least in chroot on ZW. Replacing /lib/libblkid.so.1.0 in the initrd with the one installed in ZW or Salix lead to the following output:
Code: Select all
/dev/sda10: LABEL="ZENBETA" UUID="7b46d26e-44b8-4e13-b8ab-6842d93aab68" TYPE="ext4"
instead of
Code: Select all
/dev/sda10: LABEL="ZENBETA" UUID="7b46d26e-44b8-4e13-b8ab-6842d93aab68" SEC_TYPE="ext2" TYPE="ext3"