[SOLVED] Install issues - elilo install 64-14.2-current huge

Installer seemed, to me, to have changed my own boot partition /sda1's format from fat32 to fat16 during the target phase. I had used 'mkfs.msdos 32 -f' after reading of fat issues and links. In looking into my partitions, I noticed elilo put 3 directories into my EFI partition:

?*.keep ?grub ?efi

all links and all inaccessible and no boot, of course. parted showed /sda1 to be fat16. I reformatted it to fat32 and was able to correct tree structure and get elilo installed, at which point elilo.conf was created:

chooser=simple delay=1 timeout=1 # image=vmlinuz label=vmlinuz read-only append="root=/dev/initramfs vga=normal ro"

Produced kernel panics until I changed that root to /dev/sda3 and it works.

better lucky than smart?

In case it helps anyone...

Originally Posted by Jeff-G Installer seemed, to me, to have changed my own boot partition /sda1's format from fat32 to fat16 during the target phase.

No, it didn't. I just double checked and the command in the installer is exactly:

mkfs.vfat -F 32 -s 2 ${PREFERRED_EFI_PARTITION} 1> /dev/null 2> /dev/null

I wonder what you have done ???

I suspect that the partition was just already formatted in FAT16. In case the installer finds an EFI partition already formatted, it doesn't reformat it. Else, it tells the user that it found a not yet formatted FAT partition and asks if it should format it

I noticed elilo put 3 directories into my EFI partition: ?*.keep ?grub ?efi

Again, no. Either you looked into /boot instead of in /boo/efi or (and more probably) these files remain from a previous installation, as the installer certainly doesn't write at least the two first ones in the EFI partition.

all links and all inaccessible and no boot, of course. parted showed /sda1 to be fat16.

This seems to confirm my assumption: this remains from a previous installation.

In case it helps anyone...

Maybe, as it provides an advice to all: wipe previous file system and files from an existing EFI partition that you are going to use for installing Slackware before running the installer.

Originally Posted by Didier Spaier No, it didn't. I just double checked and the command in the installer is exactly: mkfs.vfat -F 32 -s 2 ${PREFERRED_EFI_PARTITION} 1> /dev/null 2> /dev/null I wonder what you have done ???

Good question - and sorry for the late reply and thanks for replying - this exercise has been an ordeal - I just have to learn to stop from making those leaps of intuition which aren't anyway close to the reality. This mkfs thing has me baffled but thats nothing new. I used mkfs.msdos, not .vfat. I had several rejects in this stage since I knew it needed to be fat32 (or thought I did). My using 8304 - Linux x86-64 root seemed fine to me as well.

I suspect that the partition was just already formatted in FAT16. In case the installer finds an EFI partition already formatted, it doesn't reformat it. Else, it tells the user that it found a not yet formatted FAT partition and asks if it should format it

Not my recollection but I did 4 installs before getting anywhere - I was changing my notes faster than I change my socks. But the installer DID redo what I had done 3 times with boot and swap, once with the file system.

Again, no. Either you looked into /boot instead of in /boo/efi or (and more probably) these files remain from a previous installation, as the installer certainly doesn't write at least the two first ones in the EFI partition.

You're correct, it was /boot and I wasted a week chasing this tail.

This seems to confirm my assumption: this remains from a previous installation.

Don't think so - after install #2, I 'dd-zero'd' the drive and by then was aware of the fs error, making sure I had fat32.

Maybe, as it provides an advice to all: wipe previous file system and files from an existing EFI partition that you are going to use for installing Slackware before running the installer.

Now you tell me...
Thanks for showing me the error of my ways, Didier.

Just for your information:

didier[~]$ ls -l /sbin/mkfs*
-rwxr-xr-x 1 root root   9904 déc.  11  2015 /sbin/mkfs
-rwxr-xr-x 1 root root  25216 déc.  11  2015 /sbin/mkfs.bfs
-rwxr-xr-x 1 root root 331712 mai   20  2016 /sbin/mkfs.btrfs
-rwxr-xr-x 1 root root  32200 déc.  11  2015 /sbin/mkfs.cramfs
lrwxrwxrwx 1 root root      6 sept. 14  2016 /sbin/mkfs.ext2 -> mke2fs
lrwxrwxrwx 1 root root      6 sept. 14  2016 /sbin/mkfs.ext3 -> mke2fs
lrwxrwxrwx 1 root root      6 sept. 14  2016 /sbin/mkfs.ext4 -> mke2fs
lrwxrwxrwx 1 root root      6 sept. 14  2016 /sbin/mkfs.ext4dev -> mke2fs
-rwxr-xr-x 1 root root  28016 août  15  2015 /sbin/mkfs.fat
lrwxrwxrwx 1 root root      8 août   2  2016 /sbin/mkfs.jfs -> jfs_mkfs
-rwxr-xr-x 1 root root  70848 déc.  11  2015 /sbin/mkfs.minix
lrwxrwxrwx 1 root root      8 août   2  2016 /sbin/mkfs.msdos -> mkfs.fat
lrwxrwxrwx 1 root root     12 août   2  2016 /sbin/mkfs.ntfs -> /sbin/mkntfs
lrwxrwxrwx 1 root root     10 août   2  2016 /sbin/mkfs.reiserfs -> mkreiserfs
lrwxrwxrwx 1 root root      8 août   2  2016 /sbin/mkfs.vfat -> mkfs.fat
-rwxr-xr-x 1 root root 359496 déc.  15  2015 /sbin/mkfs.xfs

So writing mkfs.fat, mkfs.vfat or mkfs.msdos has exactly the same effect

Furthermore you don't have to worry about the -F option as "man mkfs.fat" says:

       -F FAT-SIZE
           Specifies the type of file allocation tables used (12, 16 or 32 bit).  If nothing is  specified,
           mkfs.fat  will  automatically  select  between  12,  16 and 32 bit, whatever fits better for the
           filesystem size.