Elive doesnt see my ext4 partition on USB disk

I have a 1TB USB disk partioned with two fat 32 partitions and one ext4 partitions. Suddenly Elive cant see the ext4 partition, it could yesterday. So I hooked the disk into PuppyXenial 7.5 and there the partition was. And I could make new folders and read the content in folders, everything as normally. Back to Elive, connected the disk and the two fat 32 partitions were there but not the ext4 partition. Hm...

I am not that good with /etc/fstab vut I suppose you have to add some entries there to AutoMont the partition... May be Puppy is doing that automatically...

@Thanatermesis

Does Elive, automount connected drive ? Or @Gunnar_Mossberg has to modify /etc/fstab

As I work around I am curiou to see if you can see the EXT4 partition with the DISKS application or GParted.... I think with DISKS you'll be able to mount it until someone gives a more intelligent answer than mine

To have a good idea what's going on:
Open a terminal and use the command:
"tail -f /var/log/syslog" and then connect the USB drive.

That way you can see what's going on internally, including the errors.

1 Like

Yes, my ext4 partition is there. Still I cant open it. The FAT partitions act normally.

~ ❯❯❯ tail -f /var/log/syslog
Feb 25 08:19:55 localhost mtp-probe: checking bus 4, device 3: "/sys/devices/pci0000:00/0000:00:14.0/usb4/4-6"
Feb 25 08:19:55 localhost mtp-probe: bus: 4, device: 3 was not an MTP device
Feb 25 08:19:58 localhost kernel: [26383.946797] scsi 5:0:0:0: Direct-Access Lenovo USB Hard Drive 1A PQ: 0 ANSI: 6
Feb 25 08:19:58 localhost kernel: [26383.947008] sd 5:0:0:0: Attached scsi generic sg2 type 0
Feb 25 08:19:58 localhost kernel: [26383.947974] sd 5:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
Feb 25 08:19:58 localhost kernel: [26383.948219] sd 5:0:0:0: [sdb] Write Protect is off
Feb 25 08:19:58 localhost kernel: [26383.948221] sd 5:0:0:0: [sdb] Mode Sense: 43 00 00 00
Feb 25 08:19:58 localhost kernel: [26383.948499] sd 5:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Feb 25 08:19:58 localhost kernel: [26383.973412] sdb: sdb1 sdb2 sdb3
Feb 25 08:19:58 localhost kernel: [26383.974260] sd 5:0:0:0: [sdb] Attached SCSI disk
^C

Well, clearly all 3 partitions are seen but apparently the file-manager has some mount issues which could in fact be user permission related. In the sense that FAT partitions have no sense of ownership but ext4 explicitly does. It isn't a very apt filesystem to carry around over different machines i.e USB disk.
A user in the Elive live version has a different UID than one made during an install routine, so that might be a problem.

My usual "dirty" solution is:

  • mount the partition as root/sudo ... "sudo mount /dev/sdb1 /mnt"
  • change ownership of everything inside to have user access .... "chown -R gunnar:gunnar /mnt"
  • and have user access to all the files there.

After unmounting the volume with "sudo umount /mnt" you can test if it will auto-mount (through re-inserting) now but I have my doubts.
The changed ownership should stay intact but now you may encounter similar problems on other installs/machines like Puppy.

PS.
Changing title to be more precise.

~ ❯❯❯ sudo mount /dev/sdb1 /mnt~ 1
[sudo] lösenord för olman:
mount: /mnt~: mount point does not exist.

you made a typo, it's /mnt without the ~.
You can use another directory if you want i.e
"mkdir /home/olman/USB"
and then
"sudo mount /dev/sdb1 /home/olman/USB"or
"sudo mount /dev/sdb1 ~/USB" because ~ on the commandline is the same as your $HOME aka /home/olman.

BTW.
Do not copy the external quotes if you copy/paste the commands!

~ ❯❯❯ mkdir /home/olman/USB~ 130
~ ❯❯❯ sudo mount /dev/sdb1 /home/olman/USB
[sudo] lösenord för olman:
mount: /home/olman/USB: mount point does not exist.
~ ❯❯❯ sudo mount /dev/sdb1 ~/USB 32
mount: /home/olman/USB: mount point does not exist.

You just made a mount point "/home/olman/USB~ 130"
NOT "/home/olman/USB" !

You have a copy/paste issue there. Simply type the commands yourself. The "~ 130" should not be there. :face_with_head_bandage:

Ah, sorry for that but
~ ❯❯❯ mkdir /home/olman/USB~
~ ❯❯❯ sudo mount /dev/sdb1 /home/olman/USB
[sudo] lösenord för olman:
mount: /home/olman/USB: special device /dev/sdb1 does not exist.
~ ❯❯❯ 32

still not right USB~ is not the same as USB

You have a strange issue with typing characters.

BTW,.
Let the shell do the work for you:
type:
sudo mount /home/ol then hit TAB for autocomplete to:
sudo mount /home/olman/
then
sudo mount /home/olman/US and hit TAB again to autocomplete to the directory that's there.

Or simply type
ls
to see what you named it to.

Note

When copying from certain formatted web pages (like this forum) from a web browser, certain invisible characters like the ~ also get copied along and show up when pasting in a terminal.
That is probably what is causing this messy stuff.

1 Like

Im tired of this and thought that maybe I made a misstake when installing. So started from the installation stick just to check and no problem, my usb disk showed up with all partitions. I could open all of them NO problem. Actually it worked as in all other os. Then I erased the internal disk and made a fresh installation from the usb stick. I choose defaults everywhere and answered "yes" to all questions. And the problem with the ext4 partition returned!

Output from fstab
Generated by the Elive installer

UUID=b0828b60-74fd-4734-9db0-77eb0d9b46c3 / ext4 defaults,commit=120,relatime,discard,barrier 0 1

Like I said before it's a user privilege problem.
The installation/live stick runs with "root" privileges whereas the installed system user does not have those privileges.

Probably that Ext4 partition has once been made on a different OS/distro that uses different user IDs than default Debian for the first user.......Ubuntu was notorious for that.

These problems will bite you again and again if you use a filesystem that is ownership sensitive (like ext4) on USB.

1 Like

OK, thanks for your time!

I copied the content of the ext4 partition while running from installation media, erased the ext4 partition, made a new FAT32 partition and everyting (?) runs. Problem solved! It was all about my ignorance, sorry for that!

I suspect most users have no idea this can happen to them and usually restrict themselves to one machine or OS ........ so it's not all that ignorant.:smiley_cat:

I move around a lot on different machines using USB disks as backups and moving large files from one machine to another.

I made the same mistake once (being fed up with size limitations of FAT) and formatted the drive to ext4 (I never used M$ anyway) and it took me a while to find out about the different IDs.

At the time IIRC most Distros numbered the 1st user 1000, the second 1001, the 3rd 1002, etc. but Ubuntu started at 1001. As it is the number that gets used not the name when privileges are checked, that created quite a flurry sometimes. :scream:

2 Likes

EXT4 is not a very good filesystem (but we have no choice since its the biggest supported one & standard)

specifically to this issue, if you format ext4 filesystem from a recent kernel, you cannot read with an older one (i don't know the exact kernel versions versions but basically a new ext4 filesystem made for example from elive beta, cannot be readed from the elive stable version which includes an old kernel)

this is a pretty bad design, similar to the microsoft office on which the documents are not compatible witth the older versions of their office (forcing you to upgrade), so the correct thing should have been to simply rename the new filesystem model ext5 :woman_shrugging:t4:

1 Like

Are you serious?
I always thought EXT4 was simply EXT2 with journalling strapped on. :shocked:

Well, EXT4 has some features, which are not bad, like SSD and flushing things, it works -good-, but is not so well designed, you can lose data in a forced shutdown (never happened this reiserfs in 15 years) and like i said, you cannot read your ext4 new partitions in older kernels, like in elive 3.0 (try it and you will see, hah!), also, the data will take like 20% more of disk space than in a reiserfs filesystem. Now, talking about bad filesystems by kernel, btrfs is the worst thing ever made. In fact reiser4 could have been the best FS ever if it was not because of its author issues, by other side reiser4 works and is good, but it has a few things that should be fixed / improved in order to consider it like really usable, for example:

  • i found some unknown inodes left in multitasking I/O
  • seems like very slow in external disks
  • "du" is not compatible because of its internal design for being a fast filesystem, so this is good and bad, but can have a real-life impact if you need to use "du" for things (for example the usb tool of elive to calculate the size of the iso to record, or many other things that you can have in tools)
  • since it is not integrated in the kernel, it is not "signed", making it non-secureboot compatible, which well, we hate secureboot but if the isos are compatible then it can boot in these machines too which is a bonus
1 Like