- This topic has 17 replies, 5 voices, and was last updated Jan 8-7:42 pm by Robin.
-
Posts
-
Robin
I just want to share my experiences for the benefit of other antiX users who might want to pursue a similar strategy.
The text is written for the real beginner, step by step and as detailed as possible, so the old-timer might feel a little impatient and bored while reading. But I’m sure he could amend some improvements of the workflow in the end.As I’ve stated elsewhere here in the forum, my final goal is to have the antiX system installed on the hdd of my notebook.
But what about the old, well oiled and fine tuned system installed on it? I prefer to keep it, since there are many helper programs installed, which I’ll probably won’t notice missing before I need one of them again, which then isn’t installed on the antiX system yet and then I could’nt remember its name, which causes me researching for some hours again.
Moreover there are some homebrew shellscripts for solving dedicated problems stored on it, which I also don’t remember exactly what and where, but if I need one, I’ll know: It has bin there and there.
From past times I remember, when dd-ing the complete hdd or partition two things will happen:
The resulting partition-images are not really handy, they need to be cut into parts, compressed to fit on a couple of DVD and I’ll probably never again have the diskspace to recreate and re-open them when I’d like to search them for a script or program I perfectly know I’ve had at hand for a special task in the old system. The second thing to happen is: Taking the before said into account, I will litter them, after having stored them for years without having any way to make use of them.
So this time I decided to manage things the another way around:
I want to move the complete existing system from hdd to an usb-stick, keeping it bootable and usable, just as antiX runs now from the stick. The roles will be changed after that. antiX will boot form hdd, and the old system will boot from the stick.I’ll repartition the hdd to current needs (it’s still partitioned as historically grown by successively installing
different operating systems, which means: a couple of pretty small partitions, in a crude order spread over the hdd. I’d prefer to make a clean cut and from now on use GPT instead of MBR, which should be possible even when this notebook does only provide BIOS, (no EFI). Then I’ll create one small (2 GiB) Boot partition, one 12GiB for / (root), one swap (4GB) and all the remaining space will be used for the /home partition. I’ll try to use Extlinux instead of grub now, the isolinux/syslinux bootprocess on antiX-live/persist has been convincing. And after these preliminaries I’ll finally install antiX in the newly created hdd structure. That is the line of approach.Back to the first step:
Exporting the complete system to a memory stick. Sounds easy, but there are some pitfalls. Sounds difficult on the other hand, but it isn’t really.First I had to prepare the USB-memory-stick. It is a cheap standard 64GB USB2/3 type, preformatted for use on Windows-systems. I’ll give a step by step explanation of the complete process just in case someone wants to undertake the same procedure before installing antiX.
(Make sure to use the fastest USB your PC provides. Some older models have USB 1.x and 2.0 both, and using the 1.0 only will slow things really down. Everything from 2.0 upwards should be ok, but it works even with 1.0, if you have no choice. You can check with lsusb as described below.)
Boot from antiX live-USB-Stick (or from CD/DVD). Don’t use a frugal install for this since it uses the hdd, possibly partitions you need to be untouched (unchanged) during the process.
Open a terminal (Menu–>Terminal), type “sudo su” and give your sudoer-password. (As you probably know, since it can be found in the antiX manuals, the standard PW for a non-persistent live system is “demo”.) Keep this terminal open until we’ve finished. Some people prefer to prefix every single command they key in with “sudo”. You can do it that way as well, omit simply the line “sudo su” and set sudo in front of each command instead.
hint:
– the “#” shows that you are in the role of “root” in that very moment, the command you key in is executed with root privileges.
– the “$” denotes that you are in simple user context and the commands are executed with the restricted privileges of the actual user.You’ll always find these marks in the terminal somewhere at the beginning of the commandline.
Don’t key in these signs, only the commands behind them.$ sudo su demo <--- sudoer pw in antiX live, key in when asked. # lsusb # lsblkExample Output of lsusb and lsblk (before pluging in the new stick):
# lsusb Bus 001 Device 003: ID 090c:2000 Silicon Motion, Inc. - Taiwan <--after knowing which bus is capable of USB2.0 we can see antiX live stick is pluged in one of the proper slots already. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub <--here we have the USB2.0 Hub, look for which bus-Number it has Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 002: ID 093a:2533 Pixart Imaging, Inc. <--this is an USB-mouse only, at one of the USB1.1 plugs. Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 2,6G 1 loop /live/linux <- these two loop-entrys belong to the antiX live system. loop1 7:1 0 1,5G 0 loop /home it is *not* your home-partition on your hdd, it contains antiX user "demo". sda 8:0 0 93,2G 0 disk <--here starts the hdd ├─sda1 8:1 0 8G 0 part /media/_daten1 <--this is the primary partition, originally used by another OS, nowadays used as file-storage ├─sda2 8:2 0 1K 0 part <--this is the extended partition (look at its size) ├─sda5 8:5 0 20G 0 part /media/_home <--this is the first logical partition within the extended partition ├─sda6 8:6 0 10G 0 part /media/_daten2 <--another partition previously used by an even older OS , now file-storage ├─sda7 8:7 0 42,5G 0 part /media/_daten3 <--this was preveously the home-partition of that even older OS, now file-storage ├─sda8 8:8 0 3G 0 part /media/_daten4 <--another historically grown partition now in use as file-storage. ├─sda9 8:9 0 2,2G 0 part [SWAP] <--this is the swap-partition of the old ubuntu system └─sda10 8:10 0 7,5G 0 part /media/sda10 <--this is actually the root partition of the old ubuntu system. sdb 8:16 1 29,5G 0 disk <--here starts the USB stick with antiX on it, even if it is named "disk" here. ├─sdb1 8:17 1 29,5G 0 part /live/boot-dev <--this is one of its partitions └─sdb2 8:18 1 50M 0 part /media/antiX-uefi <--and that is the other one. sr0 11:0 1 1024M 0 rom <--finally we have a cd/dvd-drive.This PC has as well 1.x as 2.0 USB connectors, you’ll have to look for the description at the end of the line for the word “2.0 root hub” (or even higher) and then at the beginning of that line where is written the bus number, in this example it is bus 001. Now look for what else is connected to that very bus number. In this case there is a Bus001 Device 003, which is the Live antix USB stick. Nice to know it sits on USB2.0 bus also. On one of the USB 1.1 plugs you can see the mouse (Bus 002, Device 002 in my example)
The partition order and usage is a little confused, since it is historicaly grown ;). Never mind, it’ll work anyway, since the partitions used for file-storage don’t need to be transferred to the stick. They’ll get stored elsewhere later on to free up the harddrive completely, which will be a really easy job then. The concern for today is to move the existing OS to a stick from within antiX live and make it bootable at its new residence.
Plug in the fresh USB-Stick. key in again:
# lsusb # lsblkExample output (after pluging new stick):
#lsusb Bus 001 Device 003: ID 090c:2000 Silicon Motion, Inc. - Taiwan Bus 001 Device 004: ID 058f:6387 Alcor Micro Corp. Flash Drive <--the new USB-stick, connected also to USB2.0 capable slot. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 002 Device 002: ID 093a:2533 Pixart Imaging, Inc. Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub #lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 2,6G 1 loop /live/linux loop1 7:1 0 1,5G 0 loop /home sda 8:0 0 93,2G 0 disk ├─sda1 8:1 0 8G 0 part /media/_daten1 ├─sda2 8:2 0 1K 0 part ├─sda5 8:5 0 20G 0 part /media/_home ├─sda6 8:6 0 10G 0 part /media/antiX ├─sda7 8:7 0 42,5G 0 part /media/_daten3 ├─sda8 8:8 0 3G 0 part /media/_daten4 ├─sda9 8:9 0 2,2G 0 part [SWAP] └─sda10 8:10 0 7,5G 0 part /media/sda10 sdb 8:16 1 29,5G 0 disk ├─sdb1 8:17 1 29,5G 0 part /live/boot-dev └─sdb2 8:18 1 50M 0 part /media/antiX-uefi sdc 8:32 1 58,6G 0 disk <--here we are! └─sdc1 8:33 1 58,6G 0 part /media/sdc1-usb-Generic_Flash_Di <--and this is the (empty) partition the manufacturer has put on it. sr0 11:0 1 1024M 0 romAfter plugging the new stick to an USB-connector, it should better be also located at bus 001, since we know by now this is the one which provides USB2.0 in this case. If not, try another plug and restart this procedure.
The Plugs aren’t to distinguish optically from outside. You’ll have to adapt the concept to what you will find at your PC, maybe you even find USB3.0Compare the output of the first with the second lsblk command. The enty which hasn’t been present there before is the devicename of the USB-stick for now (It will be changed when you plug it later again, depending on what else drives you have pluged in which order before, it might be /dev/sdd or /dev/sde then). You can clearly see the new device sdc in the example output, which refers to the drive as a whole, and the device sdc1 which is the partition, it has only one in this case, otherwise there would be entrys like sdc2 sdc3 and so on. These new entries are what we are looking for.
Write down:
/dev/sdc (for sdc, the drive) and
/dev/sdc1 (for sdc1, the partition).
(This is an example from my setup only, you’ll have to write down what you get from your own screen).These are the folders in your system where the programs can find and address that very drive and its partition(s).
It is absolutely important to be sure about which device you want to address later, since any mistake in these names will probably result in complete erasing another drive unwantingly! Don’t plug off or on anything before having gone through the following procedure completely, hence this might change these names in your system with all conseqences.Now start from the antiX main menue the program “gparted”:
Menu–>Programs–>Systemtools
(or just type in the root console window “gparted&”, the ampersand is not a typo! it lets you work on at the console while the program is still running.)At the upper right corner of gparted program window choose the “Drive” you just have found.
+++ WATCH OUT: A fault in choosing the correct drive here will delete your data without return!
– remove all the partitions on that drive (and only on that one)
– start the execution, wait until it is done.Maybe you get a warning, the partitions were just in use, since they probably have been mounted automatically while plugging on the stick. In this case you’ll have to unmount before proceeding: Key in your root terminal window from above:
# umount /dev/sdc1You can check whether you have successfuly unmounted the device completely by typing
# mount |grep "sdc"The answer of this command needs getting used to a little, since you are done when it doesn’t answer anything. If it comes up with something, you haven’t been successfull still.
Or just let all this be done by the drive-unmounter from the antiX taskbar. Now the deletion of the partition in gparted should complete without complaints.Next in the gparted window create new Partitions, according to your old system on the hdd:
1.) 1x Primary, ext 4, Name: “/”, Size as required, but bigger (or at least same size) than that partition containig the root-filesystem on your hdd, in my case this was 7,5GiB, I’ve chosen 10GiB which is 10240MiB (gparted asks for MiB)
2.) 1x Extended (size: all the rest of the Drive)
3.) 1x Logical, within the Extended one. ext4 also, named “/home”. Size may take the complete remains of the drive, as you like. At least it must have the size of the /home partition of your old system on hdd.
(at this point you’ll have to add more logical partitions if your old system you want to transfer requires them, name them as they are named in the old system. You can
get the correct names by keying in “blkid” in the still opened root-terminal from above.)
(Swap partition will not be created on this SDD, one can create this later, but there will be probably be always a swap partition on your hdd you can use, so you don’t really need one on the thumbdrive.)
If you’d like to make the system on the thumbdrive running a little faster, just read this text concerning a correct allignment of your new partitions: (Partition Alignment detailed explanation)
But it will work anyway, even without a correct alignment. Moreover I’m nearly sure gparted in the antiX version I’ve been using would manage this in the correct way automatically for you.– start the execution, wait until is done.
– Set the Flag “boot” on primary partition.
Close the program gparted, as we don’t need it anymore, but let the root-console window still open.
- This topic was modified 2 years, 5 months ago by Robin. Reason: fix some typos
- This topic was modified 2 years, 5 months ago by Robin. Reason: tiny amendment
Windows is like a submarine. Open a window and serious problems will start.
The freshly partitioned stick possibly won’t be readable in your old system, even if it has EXT4 drives itself. Crude thing this, but true. This is true, if the kernel of your hdd-system is older than the one on the antiX you are just working with. You can’t determine whether it’ll be readable (and bootable in consequence) by your old system, since Ext4
names itself always Ext4, instead of Ext4.01 Ext4.02 and so on, even if the versions are not backward compatible. So it can happen an Ext4 formatted USB-stick is unreadable in another PC, which understands Ext4 also, only cause of an even slightly older kernel version it still has.
So you’ll have to do some aditional steps:
In case you don’t know the version number of the old kernel by heart and don’t want to boot it up right now just for reading it out, you can look at its root partition:Key in into the still open root console window
# dumpe2fs /dev/sdc1 |grep "Filesystem features:"the result should look something like
dumpe2fs 1.43.4 (31-Jan-2017) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file metadata_csum uninit_bg dir_nlink extra_isizeThis output will show you which features are actually active on the Ext4 filesystem just created on the stick.
Now we’ll have to compare it with the capabilities of the Ext4 filesystem provided by your old system.Mount your root partition of hdd, in my case it was /dev/sda10 to a place you like or let antiX mounter script do it for you.
I mounted it to /media/sda10, so I had to key in for
looking into the grub config file:# cat /media/sda10/boot/grub/grub.cfg |grep "menuentry" menuentry 'Ubuntu, with Linux 3.2.0-126-generic' --class ubuntu --class gnu-linux --class gnu --class os {or read the names of the subfolders in the folder:
# ls /media/sda10/lib/modules 3.2.0-125-generic 3.2.0-126-genericIn any case counts the highest version number which is present there.
You will find for each feature in the output from dump2fs above an entry in the list provided in
Ext4 Kernel Support
and you should look carefully, if there is a feature in your Ext4 filesystem active which has been implemented only in a kernelversion higer than that you have found for the OS you want to transfer to the stick.
If you find all the features beeing supported by the Ext4 provided by your old system everything is fine, you don’t have to do the following steps and can directly go ahead to the file transfer below.But if not, as it was in my case, you’ll have to deactivate the features of the filesystem on the stick which are not supported. In my case it was a feature called “metadata_csum” which was the culprit, it is in Ext4 not before kernel version 3.18 and ubuntu didn’t provide a new kernel since 3.2.0-126 for the lts-system on that notebook.
So if we want to have the old system boot from the stick, we’ll have to make him suitable for the old kernel.
(Alternatively you could have done all the steps before from within your old system, but there was in my case no gparted installed, and you won’t get it installed these days anymore from the repos. They are not existant anymore at ubuntu servers. I could have done it using fdisk.)
Another way around would be to homebrew a new kernel from source, at least 3.18 (cause of metadata_csum) for the old system, which doesn’t make any sense in my opinion, for the system gets conserved for backup purposes only. So I’ll stick to what I can get.
Now, to make things short, key in the still open root console window:# tune2fs -O +uninit_bg /dev/sdc1 # tune2fs -O +uninit_bg /dev/sdc5 # tune2fs -O ^metadata_csum /dev/sdc1 # tune2fs -O ^metadata_csum /dev/sdc5and don’t forget to replace the /dev/sdc1 and dev/sdc5 in theses commands with your actual devices.
(for details about what you are doing: $ man tune2fs in another (non-root-)console window)
in short:
-O (great “O”ven, not to confuse with “Zero” or small “o”) means set/unset Options
the “^” in front of the feature deactivates it
a “+” in front of it activates it.
(I have activated additionally uninit_bg, since I found it activated on every ext4 filesystem created by my old OS, and it only speeds up the checkup of the filesystem)
The activated 64bit option should be no problem since it is implemented since kernel 2.6.28, even if it was not active in other ext4 filesystems created under the old OS.- This reply was modified 2 years, 5 months ago by Robin. Reason: typo
- This reply was modified 2 years, 5 months ago by Robin. Reason: some typos
Windows is like a submarine. Open a window and serious problems will start.
It might be possible, that you get asked by tune2fs to execute
# e2fsckin order to check the filesystem after switching features on or off. So just do it when requested.
Now we are ready to transfer the old system from the HDD to the stick.
Since we’ll need the UUID of our new partitions in the process we should write them down for later use:
the primary partition is /dev/sdc1, which will become our boot and root partition,
the first logical partititon in the extended is /dev/sda5 (a rule which is true in most cases for linux systems)
this will be our new /home partition.# dumpe2fs /dev/sdc5 |grep "Filesystem UUID:" dumpe2fs 1.43.4 (31-Jan-2017) Filesystem UUID: a4489010-a7a5-4249-b88e-4702a5672450 # dumpe2fs /dev/sdc1 |grep "Filesystem UUID:" dumpe2fs 1.43.4 (31-Jan-2017) Filesystem UUID: 76135213-70cb-4645-862b-4725026f4727Then we have to mount the partitions we want to transfer as well as these where it has to be written on:
For preventing accidentally writing something to the original partitions on hdd, we mount them adding the option “-o ro”, for read-only.# mkdir /mnt/Ubuntu-root # mount /dev/sda10 -o ro /mnt/Ubuntu-root # mkdir /mnt/Ubuntu-home # mount /dev/sda5 -o ro /mnt/Ubuntu-home # mkdir /mnt/USBstick-root # mount /dev/sdc1 /mnt/USBstick-root # mkdir /mnt/USBstick-home # mount /dev/sdc5 /mnt/USBstick-home(if one of the partition refuses to be mounted, execute “fuser”:
in case e.g. /dev/sda10 won’t mount key in# fuser -v -m /dev/sda10which will show you the culprit in most cases. Close the program which uses the device, then unmount the partition and start again with mounting it as above described.
Windows is like a submarine. Open a window and serious problems will start.
These preliminaries done, we will now actually start the transfer, using rsync.
This will create a copy of the complete file- and folderstructure of the hdd-partition on the partition at the USB-stick, as well for “/home” as for “/” (root). And again, if you have additional partitions to copy to the stick, do it the same way according to the sample creating and using addtitional mountpoints and correspondent rsync-lines. If you’d like to find out more about what all the options mean and what they do, you’ll find them listed in ” $ man rsync” typed in a non-root console window.# rsync --stats --progress --numeric-ids -axAhHSP /mnt/Ubuntu-root /mnt/USBstick-root # rsync --stats --progress --numeric-ids -axAhHSP /mnt/Ubuntu-home /mnt/USBstick-homeIf you provide the additional option “–quiet” it will work slightly faster, but you will not get any information about the running process.
Keep cool, it will last some time until everything is finally at its place…The reason wherefor we didn’t just use drag’n drop in a graphical filemanager (e.g. spacefm) for this task but condoned all these circumstances is: we have to keep the attributes and ownership of every single file and folder exactly as it was in the original, and have to copy symbolic links as such, not the aim they point to, all of which these graphical filemanagers aren’t capable to handle (well actually midnight commander can, but the commandline we use here is much more convenient).
After having finished that I decided to check the result:
# rsync --stats --progress --numeric-ids -axAhHSPc /mnt/Ubuntu-home/ /mnt/USBstick-home # rsync --stats --progress --numeric-ids -axAhHSPc /mnt/Ubuntu-root/ /mnt/USBstick-rootThe additional “c” option makes a checksum comparison, so if nothing shows up to have been changed, everything is fine now.
- This reply was modified 2 years, 5 months ago by Robin. Reason: some amendments
Windows is like a submarine. Open a window and serious problems will start.
Example output of the check, everything fine:
# rsync --stats --progress --numeric-ids -axAhHSPc /mnt/Ubuntu-root/ /mnt/USBstick-root sending incremental file list Number of files: 283,193 (reg: 183,665, dir: 26,884, link: 72,525, dev: 82, special: 37) Number of created files: 0 Number of deleted files: 0 Number of regular files transferred: 0 Total file size: 5.97G bytes Literal data-:-0 bytes Matched data-:-0 bytes File list size: 1.24M File list generation time: 0.220 seconds File list transfer time: 0.000 seconds Total bytes sent: 13.65M Total bytes received: 29.63K sent 13.65M bytes received 29.63K bytes 7.98K bytes/sec total size is 5.97G speedup is 436.01At this point, everything is written on the USB-stick already.
Now we have still to do some homework for school:
first, we have to modify fstab on the freshly created stick according to the given facts when booting from the stick later. Since we will never guess, which /dev/sdXY the stick will get assigned at boot-time, we will switch to UUID-method to identify the partitions. In case of “/” there is the UUID of the hdd, which has to be replaced with the one of the root-partition of the stick, we have written down at the beginning. Also the entry of the home partition has to be corrected: We replace the /dev/sda5 entry with the UUID of our /home partition of the stick. Moreover we have to replace ext3 by ext4, since we have an ext4 filesystem now.# cat /mnt/Speichertift-root/etc/fstab # /etc/fstab: static file system information. # # Use 'blkid -o value -s UUID' to print the universally unique identifier # for a device; this may be used with UUID= as a more robust way to name # devices that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc nodev,noexec,nosuid 0 0 # # / was on /dev/sda10 during installation #UUID=0eb91a9b-ea52-4f5b-9140-5a06f6f73d1d / ext4 errors=remount-ro 0 1 # moved to new location UUID=76135213-70cb-4645-862b-4725026f4727 / ext4 errors=remount-ro 0 1 # # # swap was on /dev/sda11 during installation # UUID=dbb40875-198e-4fd7-b6e4-e59ee464426b none swap sw 0 0 # existing swap on /dev/sda9 UUID=2d151628-e6f1-4e23-a8a6-7820d17b8a14 none swap sw 0 0 # # # existing home on /dev/sda5 94021be3-c160-4166-a151-92ad72b26f9a #/dev/sda5 /home ext3 nodev,nosuid 0 2 # moved to new location, using ext4 now UUID=a4489010-a7a5-4249-b88e-4702a5672450 /home ext4 rw,nodev,nosuid 0 2 #In the fstab file all the lines beginning with a sharp sign (#) are comments and will be ignored by the system. In this case they contain earlier entrys and comments some of which were created during original installation of the OS by the installer-script. Here are all the new UUIDs at its place already, but remember, this is an example for you only, you have to use your own UUIDs. Btw, if you wonder where do these originate from: these UUIDs get always freshly created by the partitioning tool during the partitioning and formatting of a disk.
You can edit this file with a graphical text-editor (e.g. geany from antiX menu), but you’ll need root privileges to write it back to the stick after having done all amendments.
So you might key in into the still open root console window# geany&btw, you don’t need to care about the tons of spaces between the entrys on a single line, they are for human readability only. It merely has to be at least 1 Space between them.
- This reply was modified 2 years, 5 months ago by Robin.
- This reply was modified 2 years, 5 months ago by Robin. Reason: always getting this silly 403 while posting this drives me mad
- This reply was modified 2 years, 5 months ago by Robin. Reason: some typos
Windows is like a submarine. Open a window and serious problems will start.
And here comes the feestyle skate, after having done all the duty:
No, not really, its not optional, what comes next. We have do adapt grub on the USB-drive.
Since the old system runs on grub2, we’ll stick to it.
If you find another bootloader on your old system, you’ll have to puzzle out how to transform its config so it will boot from the USB-drive.We just need a chroot-environment:
In order to alow grub to get all the relevant information of our running system we have to create some folders and
mount the following devices to them. You can name the base folder (chroot-USBstick) as you like and place them where you like in your filesystem, but for a clear view I prefer to use suggestive names.
You’ll have to type the commands in the still opened root console window.# mkdir /mnt/chroot-USBstick # mount /dev/sdc1 /mnt/chroot-USBstick # mount -o bind /dev /mnt/chroot-USBstick/dev # mount -t proc /proc /mnt/chroot-USBstick/proc # mount -o bind /sys /mnt/chroot-USBstick/sysNow we actually switch to the root of our new system on the USBstick. “root” refers at this point not any longer to the actual root of the antiX live system in this console window, but to the root of the system we are just going to trim. Every command is executed as if the system was running already, and it uses the therein installed versions of programs, rather than the ones you have at hand within the antiX live system. So consequently it writes all its configs to the correct places in the filsystem of the USB stick instead of changing things in the antiX live system.
# chroot /mnt/chroot-USBstickNow we make write Grub itself into the MBR of the USB-stick:
# update-grub2 # grub-install /dev/sdcLet grub update its config on the USB-stick:
# update-grubAnd now we leave our chroot-environment again.
# exitBe aware of any messages grub will write on the output. If there are any errors, you’ll have to sort them out, in order to make the stick actually bootable.
Now back in the “real” System, we should unmount the chroot folders:# umount /mnt/chroot-USBstick/proc # umount /mnt/chroot-USBstick/dev # umount /mnt/chroot-USBstick/sys # umount /mnt/chroot-USBstickClose the root console window.
We are done with it.Are we? Well, in my case there were some serious error messages, telling me grub wasn’t able to write to the drive at all. So my stick won’t boot so far. Don’t even need to try. Wandering what was going on, I did some research and found out, that older versions of grub actually didnt cope with some of the Ext4 options even kernels of the same age provided, and even if the grub version was delivered with a distribution which had these options in its kernel already. Since I knew, that the installed version worked very well on the original partitions, which some of them were ext4 already, I decided to look into the options which were set on these partitions. Here’s the result:
To be honest, I first tried to install (via downloading packages and dpkg, since the ancient apt refused to work due to format-change) a new version of grub in the old system within the chroot environment. But it failed, entangled in tons of unfullfilled (and unfullfilable!) dependencies, even worse the more I tried to sort them out by installing all the packages dpkg asked me for.
Never mind, the nice thing about these USB-sticks is: you can repair nearly anything with some Keystrokes only.
Since it was the root-filesystem only which was concerned, it doesn’t need anything but to let rsync check it again against the original, just as in the beginning, but letting it rewrite only these files which have been changed during the procedure.
First make sure to save the new version of fstab (and every config you already might have altered willingly) from the stick anywhere else, it will be reset too, but you can as well redo the little amendmends in it again when having forgotten to save it eslewhere before starting next step:# mount /dev/sdc1 /mnt/USBstick-root # rsync --stats --progress --numeric-ids -axAhHSPc /mnt/Ubuntu-root/ /mnt/USBstick-root(the folders to mount the devices on actually exist from the original transfer above, if not, create them again as described there.)
Now we’ll give him another chance, before replacing ext4 with ext3 finally (which should solve the problem actually, but I have’nt tried since ext4 worked after the following step perfectly for me):
Let’s check for any differences in the options between the ext4 created by gparted in antiX and the ext4 filesystems created by the older ubuntu system, which are on the original hdd partitions.
Meanwhile you should know some suitable commands for this task, we have used them above already:# dumpe2fs /dev/sdc1 |grep "Filesystem features:" dumpe2fs 1.43.4 (31-Jan-2017) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize # dumpe2fs /dev/sda10 |grep "Filesystem features:" dumpe2fs 1.43.4 (31-Jan-2017) Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isizeAs you can clearly see the options are identical except for two entrys:
needs_recovery
64bit
The first one is not really an option and will vanish when you check the filesystem. But “64bit” is an entry, which should be supported by kernel since ver 2.6.28, and the ubuntu is 3.2.0 already, what the heck does grub not recognize it years after beeing implemented in kernel? Nevertheless we have to deactivate it to give the stick a chance before reformatting the whole thing to ext3 or even ext2. There is a good chance it will work after deactivating this option, since the new filesystem on the stick then will have exactly the same option-settings as the original ext4 filesystem from ubuntu has had.
So let’s start the engine:# tune2fs -O ^64bit /dev/sdc1 # e2fsck -f /dev/sdc1 # resize2fs -s /dev/sdc1 resize2fs 1.43.4 (31-Jan-2017) Converting the filesystem to 32-bit. The filesystem at /dev/sdc1 is now 2621440 (4k) blocks long.This will last some time, since the whole filesystem on the partition is converted from 64bit to 32bit.
After having finished this, redo the steps from above from that point where we were creating the chroot-environment and chroot to the root of the USBstick in order to put grub2 in train.
Well, this time the old grub2 from Ubuntu within chroot works like a charm. Not any error message. So I am sure the stick will be bootable now. I don’t believe that it is necessary to deactivate the 64bit option at the home partition as well, since grub dosn’t have to do anything with it and the kernel is able to cope with. So let us leave this unchanged, on can do it later if it turns out to be really necessery.After having left chroot as before, and after unmounting everything not needed anymore, I gave the new stick a try.
And yes, the old system boots actually flawlessly without any complaints from USBstick now, as if never anything had changed. One drawback might be, that it is noticable slower than booting from hdd. I’ll try to check for the reason of this behaviour when I have some spare time so I can possibly sort it out. Maybe the 64bit home file system slows things down, since this notebook is a native 32bit system. But hey, its for backup purposes only, not for everyday usage!
The only thing I’ll have to keep in mind after repartitioning the hdd is to actualize fstab on that stick in order to set the correct UUID for the then new swap-partition on the hdd.Since all Data from the other partitions will become backuped elsewhere soon, I am now at the point to start installing antiX on the hdd.
For every newcomer who is encouraged to experiment now with these commands on his own: What we have used above are really powerful commands, and adding some other options of them at the commandline with root privileges might really damage your system, when accidently entered whithout knowing exactly what you are doing. So be careful!
Suggestions for further improvement or simplification of the process are welcome.
Greetings & have fun with it
RobinWindows is like a submarine. Open a window and serious problems will start.
catfood
Missing part due to
A potentially unsafe operation has been detected in your request to this site
Your access to this service has been limited. (HTTP response code 403)
If you think you have been blocked in error, contact the owner of this site for assistance.
Block Technical Data
Block Reason: A potentially unsafe operation has been detected in your request to this site
Time: Wed, 18 Nov 2020 0:51:44 GMT(That’s the errors I get when trying to downsize my youtube links on our music forum, lol.)
This thread is a bit above my paygrade, but I like where you’re going, and hope to learn more from here.
- This reply was modified 2 years, 5 months ago by catfood.
Howdy Jessie.
BobC
catfood, I’m amazed that you needed to edit that post after seeing the “roll your own linux out of a tin can and some string” post above it 🙂
I’ll have to try that sometime, Robin. I’ve had to do many of the pieces of it at one time or another after digging them from various places but never understood that much of it before.
The good news is that the topic is no longer marked as spam 🙂
ModdIt
Thanks Robin, for an excellent post,
Maybe soon a big help for me as i want to move my setup to be more SSD centric.
SSD is cheap at present ;-).just wondering if this might be better moved to the wiki as it might well become hard
to find in the depths of the forum after some months.Hello catfood, BobC and ModdIt,
Thank you for your kind words. I’m glad to see you can make something of it, and I’m excited about reading whether the elaborated process will work for you as well as it did for me.
I just wonder whether we can put some parts of it (or maybe the whole process) into a script and automatize it, at least to a certain degree. Would be a ‘nice to have’ to find one day in antiX a simple button within a menu which says “press me, I’ll consign your old OS to an USB-stick and make it bootable for you. Just plug it on.” We’ll see. But if it is possible at all, we have to go step by step and see how far we come with it and where the pitfalls are. <small>There is a chance to get through it, since antiX puts itself also on sticks completely by scripts, and we don’t have here to cope with tonns of different configurations, since there is a fully configured system on the hdd of the user which has merely to be moved to a new residence.</small>
A first small part of such a construct I got nearly ready, It’ll determine the correct devname of the freshly plugged in stick doubtlessly which has to be partitioned. A thing, which costs the old-timer merely a smile, but for the real beginner it is a first insurmountable obstacle sometimes, wherefore I have described this part structured in small steps above .
Maybe I can upload a stub of the script to the dev section next days, so interested people can test it. It works fine here already, but I’ll go through it just to see whether I haven’t left behind some lines intended for testing purposes only.
But there is a live besides Monitor and keyboard, I don’t spend that much time at the computer, so it’ll take a little.have a nice day
RobinWindows is like a submarine. Open a window and serious problems will start.
rayluo
Thanks Robin for such a detailed post! I’m sure it would be useful to those who would be in the same boat.
FWIW, I’ve been in similar situation before, and had exactly the same motivation to keep my “old, well oiled and fine tuned system installed on it… I prefer to keep it, since there are many helper programs installed, which I’ll probably won’t notice missing before I need one of them again, which then isn’t installed on the antiX system yet and then I could’nt remember its name, which causes me researching for some hours again.” (There is really no way to say it better than Robin did.) But then, I ended up just using antiX’s liveUSB exclusively, thus keep my “old, well oiled and fine tuned system” literally intact on my exist hard drive. 🙂 As long as your machine has enough memory, using liveUSB-booted system is not slow.
As long as your machine has enough memory, using liveUSB-booted system is not slow.
Well, this is exactly the point. Restricted to 2GB RAM only here it will run out of memory and simply freeze when e.g.apt-get update and apt-get upgrade and then install two or three big program packages or try to install a new kernel. I had to redo some hours of work already, since I ended up the file system wasn’t able to writing back persistent-root from RAM to the stick, even if there was plenty of free space on it. So I want defintively move antiX to disk for longtime usage.
And – since it rains cats and dogs here today – here already comes the first result of scripting some parts of the process for people not so familiar to command line operation. Now they will have only to start the script, then plug the stick, and read all the information they need collected on screen. In this first version (ver 0.25) it’ll gather and present the correct devicename of the stick and its partitions. Next version will come up with the usb connection infos of stick and pc, and then I’ll add the infos needed about mounting state and so on. For now it covers first half of the first post in this thread.
The script output is partly inernationalized, which means:
– depending on the language your console is set to you’ll get the information in english, french or german language. All the messages aren’t translated to other languages yet, in this case you’ll get english output. Feel free to post corrections to my translations used in the script, since I’m not a native speaker in english or french hence you’ll might find some strange mode of expression there.
Translations to more languages are welcome also, I’ll put them into the next version then.
– The internal comments and hints within the script are written in german, but I’ll translate these to english also in next version so everybody can understand what action a specific part of the script performs.Usage: /bin/bash tell-device.sh [options]
open a terminal window (normal user), start script, plug stick, read info on screen.
options: -h or –help shows everything you’ll need to know.I have tested this on antiX 17.4.1 fully updated from repos recently.
have fun with it.
Robin- This reply was modified 2 years, 5 months ago by Robin. Reason: again sorting out the 403
- This reply was modified 2 years, 5 months ago by Robin. Reason: and again sorting out the 403
Windows is like a submarine. Open a window and serious problems will start.
Robin wrote:
Restricted to 2GB RAM only here it will run out of memory and simply freeze when
e.g.apt-get update and apt-get upgrade and then install two or three big program packages or try to install a new kernel.
Or Nvidia graphics drivers. Fail Fail Fail. Not the fault of antiX, I am sure of that.My experience too, even on my core I5 box with 8 GB I had to create a new runit experiment in 5 stages, each time
remastering, deep freeze or incremental upgrade. Took several attempts to reach a working stick.Antix remaster is an absolutely fantastic tool but maybe we should give more tips on what happens with an older iso on
older hardware, mine is not so old but I made a new stick after no progress for 3 hours plus.What you are doing: RESPECT. If you feel you need any help with english or I see any problems contact will follow.
German is my every day language but I grew up in Midlands. England, and pretty used to transtate..You are welcome, ModdIt! Thank you very much for your kind regards, I really appreciate your offer for help in translation.
I’d prefer to write the texts needed for the script myself in English language also first (since I need some practice in order not to get rusty while not having the opportunity to speak and write the language) So it would be great if you could replace expressions or sentence structures which attract your attention as native speaker while reading them already. Don’t keep yourself from rewriting texts or strings of mine from the script completely, since it is you who does have the real feeling in using English language, not me (even if I don’t need to translate in the strict meaning of the word, for when writing in English I also think in English).You might send your suggestions and replacements to me using the private messages on this board, since I don’t think people here like to dig the piece of information they are searching for amidst posts which are concerned with better wording. I’ll then replace the strings and comments in next version of the script to your suggestions, and you’ll get a place in the comment in the head of our script naturally, if you like.
Let’s stick to English, I feel it would be impolite to all the others when switching to german right here. I’m fine with English.
Not the fault of antiX, I am sure of that.
Here you are right, absolutely. antiX isn’t to blame for this at all, since you simply can’t something “aus den Steinen klopfen” (how do you say in Great Britain?) which isn’t there. Limited to a finite amount of memory, you’ll have to decide whether you’ll use it for just running the basic operating system or better use it for the software you need to run. You can allocate your amount of memory only once, and as long as there is a hard-drive present to hold the system… But the real great thing about antiX, its real strength, is the way you can move, having a fully featured system you can use even for everyday work, while “gemütlich” moving the old whatever-OS and the new antiX system to its final residences, while already enjoying all the benefits antiX provides. And this path I hope to improve by making it easier for people to free up their hdd to install antix there if they like so, after having a great time using it right from USB-stick. All this is probably the less a question the faster and more modern your system is. Somebody who has got USB 3.0 to 3.2 with a speed range from 5 up to 20 GB/sec transfer, and a mainboard which is able to hold tons of memory will probably never come to the idea of installing something on hdd ever again. For all the others, who don’t have all this, I’ll try to write the script. I’m using antiX running from a USB stick for about ten months now and had some time to learn a bit about its glory as well as about some little clouds in the blue sky. And the sky is blue, really.
Windows is like a submarine. Open a window and serious problems will start.
- You must be logged in to reply to this topic.
