BitJam wrote:

nadir wrote:I am not sure why that matters. Isn't the point of using Unetbootin that it will use any dev? I never had to tell unetbootin if card or stick is sdc or sdb or sdd or whatever.

As I tried to explain to RC, the error message you got with the option to poweroff or reboot is a message I wrote. That means I am the one who will have to fix the problem. Unetbootin did its job but then I dropped the ball.

I never experienced a stick or card being called anything but /dev/sd*, hence couldn't even think of it

Some SDcards show up as /dev/mmcblk*. If SDcards plugged into your internal reader were assigned to a device name like this then my program would not have searched them to find the /antiX/linuxfs file.

Check done. /dev/sdb

Well that's too bad. I was hoping that by simply adding /dev/mmcblk* to the list of devices I check would fix the problem.

Ah, I have a guess as to what is wrong. I bet the internal SDcard reader is not on a usb bus. By default we only check usb devices and cdroms and dvds. This prevents us from mounting all the internal hard drive partitions looking for the /antiX/linuxfs file. All that mouting is very rude IMO because it can screw up the last-mount times since we don't have a working clock so early in the boot process. If there are other installs on those partitions then the screwed up last-mount times can cause a bunch of spurious error messages when booting those other installs.

If you add the boot parameter"from=hd" then we will look at internal drives. Give that a try. If you want us to check everywhere, use either"from=all" or"from=usb,hd,cd".

Whether that works or not, assuming an SDcard plugged into the internal reader is /dev/sdb then I would like to see the output of:

Code: Select all

udevadm info -a -p $(udevadm info -q path -n /dev/sdb)

It might be a little long so maybe it would be best to send it to me in a private message.

Another solution is to add a partition label to your SCcard and then use the boot parameter"blab=$LABEL". If you are lucky it might already be labeled. You can do an"ls -l /dev/disk/by-label" to see. If it is not already labeled then the easiest way to add a label is to run the gparted program (as root). Open up /dev/sdb (upper right hand corner of the gparted window) and then right-click on the first partition. There should be an option to change the label. If you change the label to"antiXLive" then you would use the boot parameter"blab=antiXLive". You may still need to set"from=hd" but by using a label you prevent us from mounting any of your other internal partitions.

You could also use the uuid of the partition using"buuid=$UUID". Every partition already has a uuid so you don't have to add one. The downside is they tend to be long and random so they are a pain to type in.

BitJam wrote:@nadir, thank you for the helpful info. I do have one more test for you to run although I'm running out of ideas to help you boot from your internal card reader.

If it is not too difficult I would like you to boot beta-3 from the external card reader (or a usb stick, or even a cd) with an SDcard plugged into your internal reader. I want you to select"mount usb" from the"F4 Options" menu of the antiX-beta3 boot loader. This option will automatically mount all usb devices at boot-time. I want to know if the SDcard in the internal card reader gets mounted when you boot. I usually use"df -h" from the command line to see what is mounted.

...

Next, you could use"retry=20" which will cause us to wait 20 seconds before giving up. Right now it should be waiting 10 seconds. If it is not waiting 10 seconds now then that could be part of the problem.

Third, if you mount an antiX LiveSDcard on your internal reader, does antiX/linuxfs exist? IOW, if the card shows up as /dev/sdb and its first partition is mounted at /media/sdb1 then does there exist a file at /media/sdb1/antiX/linuxfs? The uppercase"X" is crucial. If it shows up as a lowercase"x" then that could be the problem and should be fixable by using the"bdir=antix" (lowercase"x") boot parameter.

Finally, if you are feeling adventurous (and if you are comfortable with the command line) then you could use the boot parameter"bp=2" when booting from the internal reader. When you boot, you will almost instantly drop to a shell as root before we look for the antiX/linuxfs file.

Then look for /dev/sdb and /dev/sdb1 (I presume you have partitioned the SDcard and are booting from the first partition). Also look for /dev/mmcblk* devices. If nothing appears, then run"mdev -s" and look again. This command recreates the entire /dev/ directory.

If any of these do appear, then run"blkid $DEVICE" where $DEVICE is the the device that appeared. This should show you the uuid, label, and filesystem type.

Now try mounting the device yourself:

Code: Select all

# mkdir -p /mnt/sdb1
# mount -t $TYPE /dev/sdb1 /mnt/sdb1

You get the $TYPE from the output of the blkid command and I assuming the device is /dev/sdb1. The directory name under /mnt does not matter. Finally, look for /mnt/sdb1/antiX/linuxfs.

These steps should recreate what happens when we try to boot. You should umount the device before continuing. You can continue with the boot process by using the"exit" command or by hitting <Ctrl>-d.

nadir wrote:No problem. And don't worry. I am not in the desperate need to get that running.
If i use antiX i usually use it from CD. Truth: I barely use cards or sticks at all.

Ups. /dev/sdb is not there, only sda with all four partitions. mmcblk isn't there neither. fdisk - l confirms that nothing is found (I said it above, but anyway: i did boot from the SD-card internal on the laptop. It does work. I don't do it all the time though).

find /dev -type b | egrep -v"/ram|/loop"

BitJam wrote:

nadir wrote:No problem. And don't worry. I am not in the desperate need to get that running.
If i use antiX i usually use it from CD. Truth: I barely use cards or sticks at all.

My interest is in getting our software to boot in most situation. I doubt the problem you hit is unique to you.