Re: [CentOS] Best practice preparing for disk restoring system
On 18/11/2020 03:35, H wrote: On November 17, 2020 4:07:52 PM EST, "Felix Kölzow" wrote: Maybe "rear" is an appropriate solution for you? https://relax-and-recover.org/ On 17/11/2020 18:23, Chris Schanzle via CentOS wrote: I would include LVM and mdadm info as well, since I use those features. I encourage you to look at what long-lived tools, such as clonezilla, write into their archive directories. It's impressive. If you zero out all free space on all of your HDD partitions (dd bs=1M if=/dev/zero of=/path/deleteme; rm /path/deleteme) or use 'fstrim' for SSD's, you could use dd to image with fast & light compression (lzop or my current favorite, pzstd) and get maximum benefit of a bit-by-bit archival copy. On 11/16/20 11:02 PM, H wrote: Short of backing up entire disks using dd, I'd like to collect all required information to make sure I can restore partitions, disk information, UUIDs and anything else required in the event of losing a disk. So far I am collecting information from: - fdisk -l - blkid - lsblk - grub2-efi.cfg - grub - fstab Hoping that this would supply me with /all/ information to restore a system - with the exception of installed operating system, apps and data. I would appreciate any and all thoughts on the above! ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos Thank you, that tool is new to me but looks very interesting! ___ Yes, indeed. Up to now, I have very good experience with that. Setup new server. Create "rear" backup on USB, nfs-share or more secure via sshfs. Destroy Raid, Create new Raid. boot from rescure image. type "rear recover". DONE. All that in less than 10 minutes. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Thunderbird 78.4.0 after update
Hello, after an update I ended up with Thunderbird 78.4.0, it looks a little different, which is ok, but it seems that all my descriptions and also alerts disappeared. Is that a known problem? If so, how to fix that. (btw; I am not sure if I ever installed/used lightning, but that addon/extension doesn't seem to be there anymore.) If it is a known problem, is there a way to fix that? thanks, Ron ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Best practice preparing for disk restoring system
On November 17, 2020 4:07:52 PM EST, "Felix Kölzow" wrote: >Maybe "rear" is an appropriate solution for you? > >https://relax-and-recover.org/ > >On 17/11/2020 18:23, Chris Schanzle via CentOS wrote: >> I would include LVM and mdadm info as well, since I use those >features. I encourage you to look at what long-lived tools, such as >clonezilla, write into their archive directories. It's impressive. >> >> If you zero out all free space on all of your HDD partitions (dd >bs=1M if=/dev/zero of=/path/deleteme; rm /path/deleteme) or use >'fstrim' for SSD's, you could use dd to image with fast & light >compression (lzop or my current favorite, pzstd) and get maximum >benefit of a bit-by-bit archival copy. >> >> >> On 11/16/20 11:02 PM, H wrote: >>> Short of backing up entire disks using dd, I'd like to collect all >required information to make sure I can restore partitions, disk >information, UUIDs and anything else required in the event of losing a >disk. >>> >>> So far I am collecting information from: >>> - fdisk -l >>> - blkid >>> - lsblk >>> - grub2-efi.cfg >>> - grub >>> - fstab >>> >>> Hoping that this would supply me with /all/ information to restore a >system - with the exception of installed operating system, apps and >data. >>> >>> I would appreciate any and all thoughts on the above! >>> ___ >>> CentOS mailing list >>> CentOS@centos.org >>> https://lists.centos.org/mailman/listinfo/centos >> ___ >> CentOS mailing list >> CentOS@centos.org >> https://lists.centos.org/mailman/listinfo/centos >___ >CentOS mailing list >CentOS@centos.org >https://lists.centos.org/mailman/listinfo/centos Thank you, that tool is new to me but looks very interesting! ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] why does virtual console start affect graphical start up?
Please disregard this message. My additional muckings seem to have more or less fixed this including NOT saving journal files and using X to start gdm instead of Wayland. On 11/14/20 1:39 PM, Kay Schenk wrote: Hello all-- I have 3 CentOs 8 kernels insalled on my new machine -- 1. 4.18.0-193.14.2.el8_2.x86_6 2. 4.18.0-193.19.1.el8_2.x86_64 << using this one for this graphical boot 3. 4.18.0-193.28.1.el8_2.x86_64 Only #3 will boot without a *Virtual console can not start *error message but it hangs up trying to get into graphical mode, although it will boot to multi-user. The first 2 seem to work reaosnably well in either graphical or multi-user but I get a *Virtual console can not start *in boot messages with both of these. Does anyone know anything about this? Having a heck of a time trying to prevent lock ups. Thanks. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Best practice preparing for disk restoring system
Maybe "rear" is an appropriate solution for you? https://relax-and-recover.org/ On 17/11/2020 18:23, Chris Schanzle via CentOS wrote: I would include LVM and mdadm info as well, since I use those features. I encourage you to look at what long-lived tools, such as clonezilla, write into their archive directories. It's impressive. If you zero out all free space on all of your HDD partitions (dd bs=1M if=/dev/zero of=/path/deleteme; rm /path/deleteme) or use 'fstrim' for SSD's, you could use dd to image with fast & light compression (lzop or my current favorite, pzstd) and get maximum benefit of a bit-by-bit archival copy. On 11/16/20 11:02 PM, H wrote: Short of backing up entire disks using dd, I'd like to collect all required information to make sure I can restore partitions, disk information, UUIDs and anything else required in the event of losing a disk. So far I am collecting information from: - fdisk -l - blkid - lsblk - grub2-efi.cfg - grub - fstab Hoping that this would supply me with /all/ information to restore a system - with the exception of installed operating system, apps and data. I would appreciate any and all thoughts on the above! ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Best practice preparing for disk restoring system
I would include LVM and mdadm info as well, since I use those features. I encourage you to look at what long-lived tools, such as clonezilla, write into their archive directories. It's impressive. If you zero out all free space on all of your HDD partitions (dd bs=1M if=/dev/zero of=/path/deleteme; rm /path/deleteme) or use 'fstrim' for SSD's, you could use dd to image with fast & light compression (lzop or my current favorite, pzstd) and get maximum benefit of a bit-by-bit archival copy. On 11/16/20 11:02 PM, H wrote: > Short of backing up entire disks using dd, I'd like to collect all required > information to make sure I can restore partitions, disk information, UUIDs > and anything else required in the event of losing a disk. > > So far I am collecting information from: > - fdisk -l > - blkid > - lsblk > - grub2-efi.cfg > - grub > - fstab > > Hoping that this would supply me with /all/ information to restore a system - > with the exception of installed operating system, apps and data. > > I would appreciate any and all thoughts on the above! > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Intel RST RAID 1, partition tables and UUIDs
> On Nov 17, 2020, at 1:07 AM, hw wrote: > > On Mon, 2020-11-16 at 18:06 -0500, H wrote: >> On 11/16/2020 01:23 PM, Jonathan Billings wrote: >>> On Sun, Nov 15, 2020 at 07:49:09PM -0500, H wrote: I have been having some problems with hardware RAID 1 on the motherboard that I am running CentOS 7 on. After a BIOS upgrade of the system, I lost the RAID 1 setup and was no longer able to boot the system. >>> The Intel RST RAID (aka Intel Matrix RAID) is also known as a >>> fakeraid. It isn't a hardware RAID, but instead a software RAID that >>> has a fancy BIOS interface. I believe that the mdadm tool can examine >>> the RAID settings, and you can look at /proc/mdstat to see its status, >>> although from what I remember from previous posts, it's better to just >>> let the BIOS think it's a JBOD and use the linux software RAID tools >>> directly. >>> >> I see, thank you. Right now I am running off one of the disks because of the >> mishap, I am also waiting for a systemboard replacement at which time I can >> decided whether to go with Linux software RAID, ie mdadm, or back to the >> Intel BIOS RAID. >> >> The latter lacks any progress indicators in BIOS when rebuilding an array >> which took around 20 hours for a 256 GB RAID 1 setup and it is annoying not >> to know the status of the rebuild etc. Could mdadm in a command window >> helped me answer that question? >> >> Also, it seemed that the BIOS RAID damaged the partition table on the disks >> - should I expect that this happens? My guess would be no but what do I >> know... > > I'd use software raid rather the fakeraid. One of the advantages is that > you are not limited to the mainboard and can use the disks in another machine > if you need to. If you need to replace the board, you are not limited to > one that provides a compatible fakeraid. > > Using software raid with mdadm will give you indication about the progress > of rebuilds and checks by looking at /proc/mdstat, and you can automatically > get an email in case a disk fails if so configured. Being informed about > disk failures is relevant. > > I've used Linux software raid for at least 20 years and never had any problems > with it other than questionable performance disadvantages compared to hardware > raid. When a disk fails just replace it, and I've recently found that it > can be impossible to get a rebuild started with hardware raid, which makes it > virtually useless. > > I've never used the (Intel) fakeraid. Why would I? > > If you don't require Centos, you could go for Fedora instead. Fedora has > btrfs > as default file system now which has software raid built-in, and Fedora can > have > advantages over Centos. > There are advantages in a bleeding edge one can find useful. There is some bleeding too, plausible, so don’t be surprised. Valeri > > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
