A word of caution about running a live system

[Member dirkd]

While experimenting with Antix19 today, I ran into unsuspected and baffling difficulties, which turned out to be caused by the live USB used for installation. Maybe I can help some others by telling about it on the forum.

I have two separate small ssd’s in my computer. The first one has the Antix17 system I use on a daily basis, the other one an old Antix15 installation that hasn’t booted for some years now. I wiped the second one and installed Antix19 from a live USB. I can then experiment freely using dual boot, and make the switch permanently when I feel ready. Data and media files are on other HDD’s and can be shared without any problem by both installations. I have used this procedure before without experiencing any problems whatsoever.

I ran into problems with Antix19 soon, and decided to start over at a later time. However I was unable to boot to my old Antix17 system, although I had been very careful to not let the installer touch its disk. To be precise, I could boot to a console, but was unable to start a graphical interface. I saw complaints about a ‘read-only file system’ and log files were not saved. The only thing I remembered about using the Antix17 disk from within the Antix19 system was a double click on the disk from within SpaceFM, causing it to mount the Antix17 file system (I was planning to copy some configuration files). Apparently this was a huge mistake: doing so gave the Antix17 filesystem a new UUID, thereby preventing it from mounting properly on booting Antix17.

Here if my /etc/fstab file from Antix17:

# /etc/fstab: static file system information
#
# Created by make-fstab on Sat Jul 11 08:52:37 EDT 2015

# <file system> <mount point> <type> <options> <dump/pass>

UUID=ab172d74-d0d9-45a1-8b51-2611c6a539df / ext4 defaults 1 1
UUID=0841d91d-5dcc-4fc1-99ee-11257a2b9855 swap swap defaults 0 0
UUID=ab172d74-d0d9-45a1-8b51-2611c6a539df /mnt/sys/Antix-15 ext4 auto,exec,users,rw 0 0

/dev/sdc3 /mnt/data ntfs-3g auto,exec,users,rw 0 0
/dev/sdc2 /mnt/apps ntfs-3g auto,exec,users,rw 0 0
UUID=7E701FE8701FA5C5 /mnt/sys/Windows ntfs-3g auto,exec,users,rw 0 0
UUID=68c02545-221d-49bd-ba85-0045c670828f /mnt/media ext4 auto,exec,users,rw 0 0

#shares op nasty
//nasty/media /mnt/nasty/media cifs username=dd,password=xxxxx,iocharset=utf8,sec=ntlm 0 0
//nasty/data /mnt/nasty/data cifs username=dd,password=xxxxx,iocharset=utf8,sec=ntlm 0 0
//nasty/web /mnt/nasty/Web cifs username=dd,password=xxxxx,iocharset=utf8,sec=ntlm 0 0

/dev/cdrom /media/cdrom iso9660 noauto,exec,users,ro 0 0
/dev/cdrw /media/cdrw iso9660 noauto,exec,users,rw 0 0
/dev/dvd /media/dvd udf noauto,exec,users,ro 0 0
/dev/dvdrw /media/dvdrw udf noauto,exec,users,rw 0 0
/dev/sr0 /media/sr0 auto noauto,exec,users,ro 0 0

And this is the result of running blkid:

/dev/sda1: LABEL=”media2″ UUID=”68c02545-221d-49bd-ba85-0045c670828f” TYPE=”ext4″ PARTUUID=”304f4518-01″
/dev/sdb1: LABEL=”rootantiX17.1″ UUID=”9e72bdbb-b308-4d0c-adf8-95bf7cca9544″ TYPE=”ext4″ PARTUUID=”8e783a29-01″
/dev/sdc1: LABEL=”Sys” UUID=”7E701FE8701FA5C5″ TYPE=”ntfs” PARTUUID=”00000001-01″
/dev/sdc2: LABEL=”Apps” UUID=”4E42BDA2399B3504″ TYPE=”ntfs” PTTYPE=”dos” PARTUUID=”00000001-02″
/dev/sdc3: LABEL=”Data” UUID=”042F889220B256CB” TYPE=”ntfs” PTTYPE=”dos” PARTUUID=”00000001-03″
/dev/sde1: LABEL=”antiX19″ UUID=”39bdad5f-0949-43eb-bbce-713ddd636655″ TYPE=”ext4″ PARTUUID=”7378c34d-01″
/dev/sde2: LABEL=”swap” UUID=”0841d91d-5dcc-4fc1-99ee-11257a2b9855″ TYPE=”swap” PARTUUID=”7378c34d-02″

As you can see, both / (the Antix17 root partition) and /mnt/sys/Antix-15 (the old Antix15 root partition) have the same UUID in fstab (which still baffles me, as to how this is possible) which is not actually assigned to any partition, according to the blkid output.

I solved the problem by booting into the rather shaky new Antix19 system and from there editing the Antix17 /etc/fstab so that it contained the correct UUID’s. The next reboot into Antix17 was 100% normal again.

[Author]

Posts