list of forum markup codes (and testing sandbox topic)

Forum Forums Administration Site Help list of forum markup codes (and testing sandbox topic)

  • This topic has 19 replies, 4 voices, and was last updated Nov 21-2:28 am by Robin.
Viewing 5 posts - 16 through 20 (of 20 total)
  • Author
    Posts
  • #45254
    Member
    Robin
    Helpful
    Up
    0

    Test

    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/sys
    

    Now 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-USBstick
    

    Now we make write Grub itself into the MBR of the USB-stick:

    
    		# update-grub2
    		# grub-install /dev/sdc
    

    Let grub update its config on the USB-stick:

    
    		# update-grub
    

    And now we leave our chroot-environment again.

    
    	# exit
    

    Be 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-USBstick
    

    Close 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_isize
    

    As 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
    Robin

    #45261
    Member
    Robin
    Helpful
    Up
    0

    No 403 in any part now, funny thing. The culprit is obviously not a single sign or expression used in the text.
    Ok, then the text is probably too long for submitting it in one part. The field for posting didn’t complain about its length, so I thought it should be ok. I’ll now post it again in its correct place, you can delete these testings as you wish.
    greetings
    Robin

    P.S.: is there a limit for the text-length?

    #45449
    Member
    Robin
    Helpful
    Up
    0

    Just for the records:
    After this worked in this thread, there have been so many 403 from some protection system you employ it drove me nearly mad. Mostly at every upload part at the correct place in “tips” told me the board there was something wrong with my text, and I ended up cutting it in smaller and smaller chunks, putting them together again and cutting them in another way. This wasn’t fun at all, to be honest. You’ll get confused which part is already here and up to which line, after this upload chaos. Have never seen such an overexcited filter at work before.

    Just one example: In these two lines I had to replace 4 spaces by dashes to get it bypass the filter. What the heck is wrong with these lines? They originate from a simple BASH output (of rsync after having done its work) and had gone through here some minutes before flawlessly.

    
    		Literal data-:-0 bytes
    		Matched data-:-0 bytes
    

    As you can see here
    (some Posts above)
    which is exactly the same text, except for some minor corrections (typos, misspelling, …).
    I have literally cut every single line out and put it back again until I had the culprit. Within these lines it were these 4 blanks only, no other word of it did trigger the 403. Is this filter gone mad? 😉

    Have a nice day, anyway.
    Robin

    • This reply was modified 8 months, 1 week ago by Robin. Reason: link looked as it was cut after posting
    #45458
    Member
    skidoo
    Helpful
    Up
    0

    What the heck is wrong with these lines?

    If you lookup what “WordFence” is, you’ll discover that it is available in a free, and a paid, version.
    In the free version (as seen employed in this forum), broad and sweeping protection rules are bundled into a non-customizable list of anti-spam // anti-malware trigger rules.

    One quite common attack against web applications is to send payloads described as type “multipart blahblah data{colon} followed by a bytestream of data. WordFence, per its rules, “knows” that the content of a post submission should never be that “type” (and so, presence of the substring d-a-t-a-: triggers it to block the attempted submission)

    As users, and the site admins here (as users of the “free” WordFence version), we are blind to whatall actual rules are in place. As you have discovered, too often it is a frustrating trial-and-error excercise figuring out WTF a particular post has been blocked.

    #45468
    Member
    Robin
    Helpful
    Up
    0

    hello skidoo,
    don’t take my words above as an offence, I just wanted to inform you about the details in case you could adjust something in the filtering. But your post makes clear we have to take it as it is. After reading some of the wordfence pages while nearly being at the point of biting in the keyboard I thought something in this direction as you pointed out now with the word “data”. But – and this is the real strange thing – I deleted both the words “data” for exact that reason, deleted the colon, then deleted “literal” and “matched”, and it wouldn’t let me pass. Just with two empty lines it went through, and then I could fill in word for word again. Only when I replaced the four spaces with anything else it went through all of a sudden as a whole (now seeing the structure you pointed out it is clear to me why – any sign between breaks the structure and functionality in case it would have been an attack indeed). I don’t know too much about website programming (beyond html), so it was not eye-catching to me that this part must look like an attack for any protective software exactly. Next time I’ll be prepared for this and will know that it can happen.
    Better we have a protected forum and, well, we’ll live with this funny filter.
    cu
    Robin

Viewing 5 posts - 16 through 20 (of 20 total)
  • You must be logged in to reply to this topic.