Salix Forums

Atip wrote:

Code: Select all

Salix

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1p1   ?  3223366781  3470046704   123339962   78  Unknown
/dev/sdc1p2   ?   432871117  1208554935   387841909+  10  OPUS
/dev/sdc1p3   ?  1869562563  3788792630   959615034   8b  Unknown
/dev/sdc1p4   ?  3762290688  3770613779     4161546    a  OS/2 Boot Manager

TC
     Device Boot      Start         End      Blocks   Id  System
/dev/sdc1p1   ?  3224498923  3657370039   216435558+   7  HPFS/NTFS/exFAT
/dev/sdc1p2   ?  3272020941   930513678   976730017   16  Hidden FAT16
/dev/sdc1p3   ?           0           0           0   6f  Unknown
/dev/sdc1p4        50200576   974536369   462167897    0  Empty

Salix fresh
Disk identifier: 0x00000000

     Device Boot      Start         End      Blocks   Id  System
/dev/sdc1p1   *        2048     7975239     3986596    c  W95 FAT32 (LBA)

Sorry, but there's something terrible wrong here. You never should be getting such a weird partition layout. It should look just like the last extract ('Salix fresh'). Whatever 'Salix fresh' should mean. I don't know of tinycore of course.
Apart from that you're getting weird disk names. I've never seen that device naming with normal block devices (usually they're /dev/sdc1 instead of /dev/sdc1p1). What distribution is this? These uncommon names almost certainly cause trouble.

Regarding the names, this version is possibly more reliable: http://gaia.homelinux.org/misc/install-on-USB.sh
But some more information would be nice nevertheless.

You have this weird names if you ask disk info on a partition, for example using /dev/sda1 for disk, instead of /dev/sda.

Shador wrote: Regarding the names, this version is possibly more reliable: http://gaia.homelinux.org/misc/install-on-USB.sh
But some more information would be nice nevertheless.

I tried it. Result is the same, can't find kernel linux.

Could it is a speed problem? There is a cheatcode "rootdelay=??" Could that be incorporated
somewhere?

Those seem like a BSD naming convention. , maybe GPT involved?

Ekimino wrote:Those seem like a BSD naming convention. , maybe GPT involved?

BSD used afaik letters to enumerate partitions (e.g. ada1s1a or ada1a). Such names are also commonly found with loop devices (e.g. /dev/loop1p1).
I also specifially asked to create a MSDOS partition table with gparted. Did you do this, Atip?

Atip wrote:I tried it. Result is the same, can't find kernel linux.

It's probably what JRD said, that you ran fdisk with partitions instead of whole disk devices. I wouldn't have assumed that. Is that what you did?

Atip wrote:Could it is a speed problem? There is a cheatcode "rootdelay=??" Could that be incorporated
somewhere?

No, it's failing too early for that to be relevant.

What could give us some more hints as to what is failing is if you boot the physical stick virtually in a standardized qemu environment.

1. Clean the stick as previously mentioned and create a MSDOS partition table with one fat32 partition
2. Put Salix in the root of that partition and run install-on-USB.sh (post the output of install-on-USB.sh here)
3. Run boot_info_script (post the output also here)
4. Be sure to unmount the stick in your file manager
5. Install qemu-kvm
6. Run: qemu -hda /dev/sdb (or whatever the stick's whole disk device is)

In the best case this should boot the stick normally in the virtual machine.

At last! It does now boot from the stick.

I made a MSDOS partition as before /sbin/mkfs.msdos /dev/sdc1. Fired-up gparted and there
I saw on this sdc1 drive 450 Mb of unallocate space of a total of 3.8 Gb. I might have missed
that before. I then whiped everything clean with gparted and made a new MSDOS partition with gparted.
Now it showed one 3.8 Gb FAT32 partition.

Followed the standard procedures of making sdc1 live bootable. On first try it started booting
so fast that I could not read the messages. However, it takes then a total of 3 minutes untill desktop
is final. On the HP-2133 Netbook it takes 4 min.

The questions are why could I boot before into HP-2133 and not into my PC desktop and why
w/o doing any partitioning I could make this stick bootable with TC linux?

Thanks everyone for their efforts!

No idea and given the current information I most probably won't ever be able to answer that question.

Whenever I could tell the setup done by install-on-USB.sh was as expected. So it's likely to be originally caused by another part of the setup. Combined with the fact that the behaviour is inconsistent among different machines a BIOS misbehaviour is likely. But only given a very specific setup (partition(s) (table), syslinux version?, ???) that bad behaviour seems to cause a failure.
So the root cause is likely a buggy BIOS. Without possibilities to reproduce (and to gather information) a workaround won't emerge other than by chance.