Re: [gentoo-user] [OFFTOPIC}: Does the MSI Tomahawk MAX is able to boot from a M2 SSD?
> On Mar 19, 2020, at 23:29, tu...@posteo.de wrote: > > Beside speed and cost: > Is there any difference between using a M2 SATA SSD > or a M2 NVMe SSD? I can tell you there's a huge difference in speed as NVMe is essentially the same as plugging directly to PCI-E. m.2 SATA is basically for backward compatibility with older OS. > > Does these drives are working with UEFI boot and > Legacy boot when it comes to boot Linux? You shouldn't have a problem with either. I've been booting with my own signed Grub for years with UEFI secure boot. If for some reason the motherboard won't take your self-made certificates/etc, return it. Andrew
[gentoo-user] [OFFTOPIC}: Does the MSI Tomahawk MAX is able to boot from a M2 SSD?
Hi, maybe someone here, who owns a PC with a MSI Tomahawk MAX motherboard can answer this question: Is it possible to boot Linux from the installed M2 Nvme (or if not from a M2 SATA) SSD? ? In the chapter about the BIOS the user manual of the MSI Tomahaswk Max only says "Select Boot Priority", but does not tell about the kind of selectable items. Beside speed and cost: Is there any difference between using a M2 SATA SSD or a M2 NVMe SSD? Does these drives are working with UEFI boot and Legacy boot when it comes to boot Linux? Thanks a lot in advance for any help...! (...sorry...I went out of cryo sleep just a few hours ago... ;) Cheers! Meino
[gentoo-user] Re: swaps mounted randomly [not out of the woods yet]
On 2020-03-20 00:30, Michael wrote: > Finally, I don't think you can use the hardware specific ID, found > under /dev/ disk/by-id/wwn-xx-part1, which is a > symlink to the /dev/sda1 name. Why not? I think you can just use it directly, in place of the /dev/sdaX. After all, it's just an alternate (indirect) name for the same device inode. -- Ian
Re: [gentoo-user] Re: swaps mounted randomly [not out of the woods yet]
On Thursday, 19 March 2020 19:08:55 GMT n952162 wrote: > On 2020-03-19 19:43, Michael wrote: > > On Thursday, 19 March 2020 18:32:12 GMT n952162 wrote: > >> On 2020-03-19 19:04, Michael wrote: > >>> On Thursday, 19 March 2020 17:03:15 GMT Ian Zimmerman wrote: > On 2020-03-19 10:59, n952162 wrote: > > I changed the UUID of all the partitions of the second drive and now > > all my devices are linked to in /dev/disk/by-uuid. I still have > > no/dev/disk/by-label, though. Also, my swap file on a mounted drive > > wasn't mounted, which was my original problem ;-( > > Do they in fact have labels? Just checking. > > Also, you're not not clear if your _partition_ still isn't getting > mounted, or just the swap file not getting activated. > > For a problem like this, there _has_ to be something in the log. > >>> > >>> We're using the term 'partition' here, but to avoid confusion, we have > >>> GPT > >>> partition table UUIDs (PARTUUID) and we have filesystem UUIDs (UUID). > >>> > >>> Similarly, we also have filesystem labels and GPT partition labels. > >>> > >>> Therefore it helps if there is consistency in the IDs being used to > >>> mount > >>> partitions. > >> > >> I used the UUID column of blkid(8) on the fstab entry, with UUID=. If > >> that is the partition UUID, where, how, and wherefore are filesystem > >> UUIDs? > > > > lsblk -o +PARTUUID,UUID > > > > will show both, but blkid also print filesystem UUID and partition table > > PARTUUID. > > Okay, then I got it backwards: both blkid(8)'s UUID and /etc/fstab's > UUID are the filesystem UUID. What is the partition UUID used for? GPT partition tables also have a 'UUID' for each partition, which is stored in the GPT tables. The GUID Partition Table (GPT) is called so because every partition on a disk has a “globally unique identifier,” or GUID (aka. PARTUUID). GPT tables use 64-bit sector pointers for each partition, but I don't know if the 128-bit code of GUID/PARTUUID contains info on the start sector of a GPT partition. Anyway, you can specify block devices to be mounted in your /etc/fstab using various methods. 1. The good ol' file name of a block device: /dev/sdaX However, if you swap drives around, don't be surprised if your drive has been renamed/renumbered. The /dev/sdaX device file name will now point to a different disk/partition. 2. Partition UUID: PARTUUID=xxx-xxx-xxx-xxx This is permanent and won't change when you swap disks around, unless you repartition your disk. You need a GPT table type for this method. 3. Filesystem UUID: UUID=xx-xxx-xxx-x This is permanent and will also not change, unless you reformat your filesystem. 4. Filesystem LABEL: LABEL=MySWAP This won't change unless you reformat the filesystem, or change its LABEL. 5. Partition PARTLABEL: PARTLABEL=SWAP1 This won't change unless you repartition the disk, or change its PARTLABEL. Finally, I don't think you can use the hardware specific ID, found under /dev/ disk/by-id/wwn-xx-part1, which is a symlink to the /dev/sda1 name. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Testing ebuilds
On jeu. 19 mars 11:17:51 2020, Ian Zimmerman wrote: > But have you tried the _install_ step this way? I don't mean the "real" > install into the filesystem, just the staged install that "ebuild foo > install" does. > > I get: > > >>> Install net-mail/mu-1.3.9 into /tmp/portage/net-mail/mu-1.3.9/image > /usr/bin/install: cannot change ownership of > '/tmp/portage/net-mail/mu-1.3.9/image/usr/bin/mu': > Operation not permitted > * ERROR: net-mail/mu-1.3.9::foolinux failed (install phase): > * dobin failed > > And yes, I am in the portage group. Of course this doesn't help here - > only root can do chown(). Yes and it has always worked. `dobin` shouldn’t try to chown in theory, it’s done during the merge. Here with another ebuild because the previous one needs deps: alarig@pikachu ~ % ebuild /var/db/repos/SwordArMor/dev-libs/libcli/libcli-1.10.2.ebuild install * libcli-1.10.2.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking libcli-1.10.2.tar.gz to >>> /var/tmp/portage/dev-libs/libcli-1.10.2/work >>> Source unpacked in /var/tmp/portage/dev-libs/libcli-1.10.2/work >>> Preparing source in >>> /var/tmp/portage/dev-libs/libcli-1.10.2/work/libcli-1.10.2 ... * Applying libcli-Makefile.patch ... [ ok ] >>> Source prepared. >>> Configuring source in >>> /var/tmp/portage/dev-libs/libcli-1.10.2/work/libcli-1.10.2 ... >>> Source configured. >>> Compiling source in >>> /var/tmp/portage/dev-libs/libcli-1.10.2/work/libcli-1.10.2 ... make -j2 gcc -O2 -pipe -march=native -mtune=native -g -O3 -Wall -std=c99 -pedantic -Wformat-security -Wno-format-zero-length -Werror -Wwrite-strings -Wformat -fdiagnostics-show-option -Wextra -Wsign-compare -Wcast-align -Wno-unused-parameter -fPIC -o libcli.o -c libcli.c gcc -O2 -pipe -march=native -mtune=native -g -O3 -Wall -std=c99 -pedantic -Wformat-security -Wno-format-zero-length -Werror -Wwrite-strings -Wformat -fdiagnostics-show-option -Wextra -Wsign-compare -Wcast-align -Wno-unused-parameter -fPIC -o clitest.o -c clitest.c gcc -o libcli.so.1.10.2 libcli.o -Wl,-O1 -Wl,--as-needed -shared -Wl,-soname,libcli.so.1.10 -lcrypt ar rcs libcli.a libcli.o rm -f libcli.so libcli.so.1.10 ln -s libcli.so.1.10.2 libcli.so.1.10 ln -s libcli.so.1.10 libcli.so gcc -O2 -pipe -march=native -mtune=native -g -O3 -Wall -std=c99 -pedantic -Wformat-security -Wno-format-zero-length -Werror -Wwrite-strings -Wformat -fdiagnostics-show-option -Wextra -Wsign-compare -Wcast-align -Wno-unused-parameter -o clitest clitest.o -L. -lcli >>> Source compiled. >>> Test phase [not enabled]: dev-libs/libcli-1.10.2 >>> Install dev-libs/libcli-1.10.2 into >>> /var/tmp/portage/dev-libs/libcli-1.10.2/image make -j2 DESTDIR=/var/tmp/portage/dev-libs/libcli-1.10.2/image install install -d /var/tmp/portage/dev-libs/libcli-1.10.2/image/usr/include /var/tmp/portage/dev-libs/libcli-1.10.2/image/usr/lib64 install -m 0644 libcli.h /var/tmp/portage/dev-libs/libcli-1.10.2/image/usr/include install -m 0644 libcli.a /var/tmp/portage/dev-libs/libcli-1.10.2/image/usr/lib64 install -m 0755 libcli.so.1.10.2 /var/tmp/portage/dev-libs/libcli-1.10.2/image/usr/lib64 cd /var/tmp/portage/dev-libs/libcli-1.10.2/image/usr/lib64 && \ ln -fs libcli.so.1.10.2 libcli.so.1.10 && \ ln -fs libcli.so.1.10 libcli.so >>> Completed installing dev-libs/libcli-1.10.2 into >>> /var/tmp/portage/dev-libs/libcli-1.10.2/image * Final size of build directory: 1044 KiB (1.0 MiB) * Final size of installed tree: 488 KiB strip: x86_64-pc-linux-gnu-strip --strip-unneeded -N __gentoo_check_ldflags__ -R .comment -R .GCC.command.line -R .note.gnu.gold-version /usr/lib64/libcli.a /usr/lib64/libcli.so.1.10.2 alarig@pikachu ~ % ls -lh /var/tmp/portage/dev-libs/libcli-1.10.2/image/ total 4.0K drwxr-xr-x 5 alarig alarig 4.0K Mar 19 20:10 usr alarig@pikachu ~ % ls -lh /var/tmp/portage/dev-libs/libcli-1.10.2/image/usr/ total 12K drwxr-xr-x 2 alarig alarig 4.0K Mar 19 20:10 include drwxr-xr-x 2 alarig alarig 4.0K Mar 19 20:10 lib64 drwxr-xr-x 3 alarig alarig 4.0K Mar 19 20:10 share alarig@pikachu ~ % ls -lh /var/tmp/portage/dev-libs/libcli-1.10.2/image/usr/include/ total 12K -rw-r--r-- 1 alarig alarig 9.5K Mar 19 20:10 libcli.h alarig@pikachu ~ % ls -lh /var/tmp/portage/dev-libs/libcli-1.10.2/image/usr/lib64/ total 140K -rw-r--r-- 1 alarig alarig 74K Mar 19 20:10 libcli.a lrwxrwxrwx 1 alarig alarig 14 Mar 19 20:10 libcli.so -> libcli.so.1.10 lrwxrwxrwx 1 alarig alarig 16 Mar 19 20:10 libcli.so.1.10 -> libcli.so.1.10.2 -rwxr-xr-x 1 alarig alarig 63K Mar 19 20:10 libcli.so.1.10.2 alarig@pikachu ~ % ls -lh /var/tmp/portage/dev-libs/libcli-1.10.2/image/usr/share/ total 4.0K drwxr-xr-x 3 alarig alarig 4.0K Mar 19 20:10 doc alarig@pikachu ~ % ls
Re: [gentoo-user] Re: swaps mounted randomly [not out of the woods yet]
On 2020-03-19 19:43, Michael wrote: On Thursday, 19 March 2020 18:32:12 GMT n952162 wrote: On 2020-03-19 19:04, Michael wrote: On Thursday, 19 March 2020 17:03:15 GMT Ian Zimmerman wrote: On 2020-03-19 10:59, n952162 wrote: I changed the UUID of all the partitions of the second drive and now all my devices are linked to in /dev/disk/by-uuid. I still have no/dev/disk/by-label, though. Also, my swap file on a mounted drive wasn't mounted, which was my original problem ;-( Do they in fact have labels? Just checking. Also, you're not not clear if your _partition_ still isn't getting mounted, or just the swap file not getting activated. For a problem like this, there _has_ to be something in the log. We're using the term 'partition' here, but to avoid confusion, we have GPT partition table UUIDs (PARTUUID) and we have filesystem UUIDs (UUID). Similarly, we also have filesystem labels and GPT partition labels. Therefore it helps if there is consistency in the IDs being used to mount partitions. I used the UUID column of blkid(8) on the fstab entry, with UUID=. If that is the partition UUID, where, how, and wherefore are filesystem UUIDs? lsblk -o +PARTUUID,UUID will show both, but blkid also print filesystem UUID and partition table PARTUUID. Okay, then I got it backwards: both blkid(8)'s UUID and /etc/fstab's UUID are the filesystem UUID. What is the partition UUID used for?
Re: [gentoo-user] Re: swaps mounted randomly [not out of the woods yet]
On Thursday, 19 March 2020 18:32:12 GMT n952162 wrote: > On 2020-03-19 19:04, Michael wrote: > > On Thursday, 19 March 2020 17:03:15 GMT Ian Zimmerman wrote: > >> On 2020-03-19 10:59, n952162 wrote: > >>> I changed the UUID of all the partitions of the second drive and now > >>> all my devices are linked to in /dev/disk/by-uuid. I still have > >>> no/dev/disk/by-label, though. Also, my swap file on a mounted drive > >>> wasn't mounted, which was my original problem ;-( > >> > >> Do they in fact have labels? Just checking. > >> > >> Also, you're not not clear if your _partition_ still isn't getting > >> mounted, or just the swap file not getting activated. > >> > >> For a problem like this, there _has_ to be something in the log. > > > > We're using the term 'partition' here, but to avoid confusion, we have GPT > > partition table UUIDs (PARTUUID) and we have filesystem UUIDs (UUID). > > > > Similarly, we also have filesystem labels and GPT partition labels. > > > > Therefore it helps if there is consistency in the IDs being used to mount > > partitions. > > I used the UUID column of blkid(8) on the fstab entry, with UUID=. If > that is the partition UUID, where, how, and wherefore are filesystem UUIDs? lsblk -o +PARTUUID,UUID will show both, but blkid also print filesystem UUID and partition table PARTUUID. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: swaps mounted randomly [not out of the woods yet]
On 2020-03-19 19:04, Michael wrote: On Thursday, 19 March 2020 17:03:15 GMT Ian Zimmerman wrote: On 2020-03-19 10:59, n952162 wrote: I changed the UUID of all the partitions of the second drive and now all my devices are linked to in /dev/disk/by-uuid. I still have no/dev/disk/by-label, though. Also, my swap file on a mounted drive wasn't mounted, which was my original problem ;-( Do they in fact have labels? Just checking. Also, you're not not clear if your _partition_ still isn't getting mounted, or just the swap file not getting activated. For a problem like this, there _has_ to be something in the log. We're using the term 'partition' here, but to avoid confusion, we have GPT partition table UUIDs (PARTUUID) and we have filesystem UUIDs (UUID). Similarly, we also have filesystem labels and GPT partition labels. Therefore it helps if there is consistency in the IDs being used to mount partitions. I used the UUID column of blkid(8) on the fstab entry, with UUID=. If that is the partition UUID, where, how, and wherefore are filesystem UUIDs?
Re: [gentoo-user] How to set up a website
On Thursday, 19 March 2020 17:53:53 GMT J. Roeleveld wrote: > On 19 March 2020 18:19:38 CET, Peter Humphrey wrote: > >Hello list, > > > >I want to set up a web server on a local box, and I'm following the > >Gentoo > >guide[1]. I'd like two sites: one under /var/www/localhost and the > >other under > >/var/www/mydomain, in which mydomain is registered to me. > > > >The main problem I'm having is that all the Gentoo documents I've found > >assume > >far too much familiarity with apache. I've installed NextCloud using > >webapp- > >config; this is the layout: > > > >$ tree -L 3 /var/www > >/var/www > >├── localhost > >│ └── htdocs > >│ ├── fcgid-bin > >│ ├── index.orig > >│ └── index.php > >└── mydomain > > > >├── cgi-bin > >├── error > >├── htdocs > >│ ├── cloud > >│ ├── fcgid-bin > >│ ├── index.orig > >│ └── index.php > >└── icons > > > >Is this a suitable layout? Once I get past this I may be asking for > >help with /etc/apache2/vhosts.d/* . There is nothing wrong with your layout. It is easier to have the webroot of multiple domains hosted under /var/www, each in their respective directory; e.g. /var/www/mydomain1/htdocs/ /var/www/mydomain2/htdocs/ ... /var/www/mydomain-n/htdocs/ and leave /var/www/localhost/htdocs as the default catch-all apache webpage to be served for testing purposes. Then set separate configuration files (/etc/apache2/vhosts.d/* and /etc/ apache2/modules.d/*) for each domain, which you can easily clone/copy thereafter. > Is there a specific reason you are using Apache? > I found it far simpler to use Nginx when dealing with different websites, > incl. seperate SSL certificates per site even though it is 1 server and > public IP. > > -- > Joost nginx has a smaller footprint and it is faster than apache, especially when serving static websites. I understand NextCloud works with WebDAV and nginx also comes with WebDAV modules to allow this functionality. For low user numbers either will do, but if we're talking about a home grown embedded device acting as the server I would lean towards nginx or other light-footed servers. signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: How to set up a website
On 2020-03-19 18:53, J. Roeleveld wrote: > I found it far simpler to use Nginx when dealing with different > websites, incl. seperate SSL certificates per site even though it is 1 > server and public IP. +1 -- Ian
[gentoo-user] Re: Testing ebuilds
On 2020-03-19 08:40, Alarig Le Lay wrote: > alarig@pikachu ~ % ls -lhd /var/tmp/portage/ > drwxrwxr-x 8 portage portage 4.0K Mar 19 08:37 /var/tmp/portage/ > alarig@pikachu ~ % ebuild > /var/db/repos/SwordArMor/net-misc/FORT-validator/FORT-validator-1.2.0.ebuild > prepare > * FORT-validator-1.2.0.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ] > >>> Unpacking source... > >>> Unpacking FORT-validator-1.2.0.tar.gz to > >>> /var/tmp/portage/net-misc/FORT-validator-1.2.0/work > >>> Source unpacked in /var/tmp/portage/net-misc/FORT-validator-1.2.0/work > >>> Preparing source in > >>> /var/tmp/portage/net-misc/FORT-validator-1.2.0/work/FORT-validator-1.2.0 > >>> ... > * Applying FORT-validator-skip-online-test.patch ... [ ok ] > * Running eautoreconf in > '/var/tmp/portage/net-misc/FORT-validator-1.2.0/work/FORT-validator-1.2.0' ... > * Running aclocal ... [ ok ] > * Running autoconf --force ... [ ok ] > * Running autoheader ... [ ok ] > * Running automake --add-missing --copy --foreign --force-missing ... [ ok ] > * Running elibtoolize in: FORT-validator-1.2.0/ > >>> Source prepared. But have you tried the _install_ step this way? I don't mean the "real" install into the filesystem, just the staged install that "ebuild foo install" does. I get: >>> Install net-mail/mu-1.3.9 into /tmp/portage/net-mail/mu-1.3.9/image /usr/bin/install: cannot change ownership of '/tmp/portage/net-mail/mu-1.3.9/image/usr/bin/mu': Operation not permitted * ERROR: net-mail/mu-1.3.9::foolinux failed (install phase): * dobin failed And yes, I am in the portage group. Of course this doesn't help here - only root can do chown(). -- Ian
Re: [gentoo-user] Re: swaps mounted randomly [not out of the woods yet]
On Thursday, 19 March 2020 17:03:15 GMT Ian Zimmerman wrote: > On 2020-03-19 10:59, n952162 wrote: > > I changed the UUID of all the partitions of the second drive and now > > all my devices are linked to in /dev/disk/by-uuid. I still have > > no/dev/disk/by-label, though. Also, my swap file on a mounted drive > > wasn't mounted, which was my original problem ;-( > > Do they in fact have labels? Just checking. > > Also, you're not not clear if your _partition_ still isn't getting > mounted, or just the swap file not getting activated. > > For a problem like this, there _has_ to be something in the log. We're using the term 'partition' here, but to avoid confusion, we have GPT partition table UUIDs (PARTUUID) and we have filesystem UUIDs (UUID). Similarly, we also have filesystem labels and GPT partition labels. Therefore it helps if there is consistency in the IDs being used to mount partitions. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] How to set up a website
On 19 March 2020 18:19:38 CET, Peter Humphrey wrote: >Hello list, > >I want to set up a web server on a local box, and I'm following the >Gentoo >guide[1]. I'd like two sites: one under /var/www/localhost and the >other under >/var/www/mydomain, in which mydomain is registered to me. > >The main problem I'm having is that all the Gentoo documents I've found >assume >far too much familiarity with apache. I've installed NextCloud using >webapp- >config; this is the layout: > >$ tree -L 3 /var/www >/var/www >├── localhost >│ └── htdocs >│ ├── fcgid-bin >│ ├── index.orig >│ └── index.php >└── mydomain >├── cgi-bin >├── error >├── htdocs >│ ├── cloud >│ ├── fcgid-bin >│ ├── index.orig >│ └── index.php >└── icons > >Is this a suitable layout? Once I get past this I may be asking for >help with >/etc/apache2/vhosts.d/* . > >1. https://wiki.gentoo.org/wiki/Apache > >-- >Regards, >Peter. Is there a specific reason you are using Apache? I found it far simpler to use Nginx when dealing with different websites, incl. seperate SSL certificates per site even though it is 1 server and public IP. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[gentoo-user] How to set up a website
Hello list, I want to set up a web server on a local box, and I'm following the Gentoo guide[1]. I'd like two sites: one under /var/www/localhost and the other under /var/www/mydomain, in which mydomain is registered to me. The main problem I'm having is that all the Gentoo documents I've found assume far too much familiarity with apache. I've installed NextCloud using webapp- config; this is the layout: $ tree -L 3 /var/www /var/www ├── localhost │ └── htdocs │ ├── fcgid-bin │ ├── index.orig │ └── index.php └── mydomain ├── cgi-bin ├── error ├── htdocs │ ├── cloud │ ├── fcgid-bin │ ├── index.orig │ └── index.php └── icons Is this a suitable layout? Once I get past this I may be asking for help with /etc/apache2/vhosts.d/* . 1. https://wiki.gentoo.org/wiki/Apache -- Regards, Peter.
[gentoo-user] Re: swaps mounted randomly [not out of the woods yet]
On 2020-03-19 10:59, n952162 wrote: > I changed the UUID of all the partitions of the second drive and now > all my devices are linked to in /dev/disk/by-uuid. I still have > no/dev/disk/by-label, though. Also, my swap file on a mounted drive > wasn't mounted, which was my original problem ;-( Do they in fact have labels? Just checking. Also, you're not not clear if your _partition_ still isn't getting mounted, or just the swap file not getting activated. For a problem like this, there _has_ to be something in the log. -- Ian
[gentoo-user] gentoo-user+unsubscr...@lists.gentoo.org
Re: [gentoo-user] Re: swaps mounted randomly [not out of the woods yet]
I changed the UUID of all the partitions of the second drive and now all my devices are linked to in /dev/disk/by-uuid. I still have no/dev/disk/by-label, though. Also, my swap file on a mounted drive wasn't mounted, which was my original problem ;-( On 2020-03-19 09:36, n952162 wrote: On 2020-03-19 09:33, Neil Bothwick wrote: On Thu, 19 Mar 2020 08:17:58 +0100, n952162 wrote: A couple of years back, I bought these drives to install RAID on them, but gave up on that. Now, I've decided to do "manual" RAID, but I'm wondering if the fact that the two drives have the same UUID is causing whoever it is who sets up /dev/disk (I'm still trying to find that culprit) is croaking on two different devices with the same UUID. udev creates /dev Where is the UUID determined? I'd presumed that it was derived from some characteristics of the drive, determined by the device controller, but now I'm wondering if my initial RAID configuration set some drive-internal variable to be identical? And, how does one /*reset*/ it? tune2fs -U [UUID] /dev/sdX UUID can be either a string in the standard format or the word random. Cool! I missed that about the "random" keyword.
Re: [gentoo-user] Re: swaps mounted randomly [not out of the woods yet]
On 2020-03-19 09:33, Neil Bothwick wrote: On Thu, 19 Mar 2020 08:17:58 +0100, n952162 wrote: A couple of years back, I bought these drives to install RAID on them, but gave up on that. Now, I've decided to do "manual" RAID, but I'm wondering if the fact that the two drives have the same UUID is causing whoever it is who sets up /dev/disk (I'm still trying to find that culprit) is croaking on two different devices with the same UUID. udev creates /dev Where is the UUID determined? I'd presumed that it was derived from some characteristics of the drive, determined by the device controller, but now I'm wondering if my initial RAID configuration set some drive-internal variable to be identical? And, how does one /*reset*/ it? tune2fs -U [UUID] /dev/sdX UUID can be either a string in the standard format or the word random. Cool! I missed that about the "random" keyword.
Re: [gentoo-user] Re: swaps mounted randomly [not out of the woods yet]
On Thu, 19 Mar 2020 08:17:58 +0100, n952162 wrote: > A couple of years back, I bought these drives to install RAID on them, > but gave up on that. Now, I've decided to do "manual" RAID, but I'm > wondering if the fact that the two drives have the same UUID is causing > whoever it is who sets up /dev/disk (I'm still trying to find that > culprit) is croaking on two different devices with the same UUID. udev creates /dev > Where is the UUID determined? I'd presumed that it was derived from > some characteristics of the drive, determined by the device controller, > but now I'm wondering if my initial RAID configuration set some > drive-internal variable to be identical? > > And, how does one /*reset*/ it? tune2fs -U [UUID] /dev/sdX UUID can be either a string in the standard format or the word random. -- Neil Bothwick The careful application of terror is also a form of communication. pgpLQGsWQX0w3.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Testing ebuilds
On mer. 18 mars 19:20:23 2020, Jack wrote: > On 2020.03.18 18:59, Ian Zimmerman wrote: > > After a hiatus I am trying to create my own ebuild repository again. I > > need a way to test the separate steps (fetch, prepare, comiple, install > > etc.) and I would like to do all of them as a regular user (not root, > > not portage). I tried what I thought was the most natural attempt - run > > the ebuild program under fakeroot, but it still breaks trying to change > > permissions of things in PORTAGE_TMPDIR (of course override the value of > > this variable). I don't understand this - it looks just like what > > fakeroot was intended to help with? Anyway, I'm not married to > > fakeroot, > > just looking for a way to do these test runs. > > > > I remember that I could do this the first time, a couple of years ago. > > But I don't remember how :-( > This is from memory - not currently tested, but I often do the various > ebuild steps as myself, without a fakeroot, and not overriding the system > PORTAGE_TMPDIR.. Again, from memory, as long as I opened permissions on > PORTAGE_TMPDIR so I could create the necessary directories, I could do all > steps as myself except for the final qmerge. Once you create the group and > package directories under PORTAGE_TMPDIR, there shouldn't be any problems. > The final qmerge step clearly requires root, unless you are using a chroot > to install somewhere other than the real system directories. > > Jack I’m also invoking ebuild as a regular user, the only thing that needs permissions is when using git. However, you have to be part of the portage group to do this. alarig@pikachu ~ % ls -lhd /var/tmp/portage/ drwxrwxr-x 8 portage portage 4.0K Mar 19 08:37 /var/tmp/portage/ alarig@pikachu ~ % ebuild /var/db/repos/SwordArMor/net-misc/FORT-validator/FORT-validator-1.2.0.ebuild prepare * FORT-validator-1.2.0.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking FORT-validator-1.2.0.tar.gz to >>> /var/tmp/portage/net-misc/FORT-validator-1.2.0/work >>> Source unpacked in /var/tmp/portage/net-misc/FORT-validator-1.2.0/work >>> Preparing source in >>> /var/tmp/portage/net-misc/FORT-validator-1.2.0/work/FORT-validator-1.2.0 ... * Applying FORT-validator-skip-online-test.patch ... [ ok ] * Running eautoreconf in '/var/tmp/portage/net-misc/FORT-validator-1.2.0/work/FORT-validator-1.2.0' ... * Running aclocal ... [ ok ] * Running autoconf --force ... [ ok ] * Running autoheader ... [ ok ] * Running automake --add-missing --copy --foreign --force-missing ... [ ok ] * Running elibtoolize in: FORT-validator-1.2.0/ >>> Source prepared. alarig@pikachu ~ % ls -lhd /var/tmp/portage/net-misc/FORT-validator-1.2.0/ drwxr-xr-x 6 alarig portage 4.0K Mar 19 08:38 /var/tmp/portage/net-misc/FORT-validator-1.2.0/ -- Alarig
Re: [gentoo-user] Re: SDD, what features to look for and what to avoid.
David Haller wrote: > Hello, an addendum without digging up the details ... > > On Tue, 17 Mar 2020, David Haller wrote: >> On Tue, 17 Mar 2020, Grant Edwards wrote: >>> I've put five Samsung SATA drives into various things in the past few >>> years with flawless results. Samsung is one of the big manufacturers >>> of flash chips, so I figure they should always end up with 1st choice >>> quality chips in their own drives... >> And they produce and use their own controllers, so they additionally >> know the ins and outs of those, i.e. they can easily optimize the >> whole SSD from Flash-Chip over controller up to the firmware... > [..] >> AFAIgathered, Samsung is the only one producing the whole product. > I guess Intel did (still does?) that too, but you'll have to check > that, ISTR that Intel now sells SSDs with non-Intel controllers and/or > non-Intel/"IM-Flash" flash-chips... Oh, wait, yes, Intel still does, > but those "pure Intel" SSDs come with a *very* hefty price (like 4 > times as much) and all the "normal" priced ones are those with either > and/or non Intel flash-chips and/or -controllers... But please go > check that yourselves though! > > The second thing I remembered: the german "c't"[2] magazine did a > torture test in late 2018 (IIRC), basically grabbing a few then > current SSDs and run their own testtool[1] on them until they died. Or > so was the plan. That was a "write till it dies" test. > > First of all: all SSD exceeded their specs, some IIRC just barely. The > bulk by a factor of 2 or more. ISTR some of those "just barely", but > wont name them without digging out the actual results, which I'll do > upon requests. > > The test had one problem though: a (IIRC) Samsung 850 Pro just refused > to die ;) They aborted the test after something like over 4 months > (all other drives had died inside of about a month) of _continous_ > writes (or write-verify cycles) to that one remaining SSD, which was > still happily chugging along... > > I do remember though, that even the Samsung EVO came out at the top of > the bunch > > (Note: c't does not award a "test-winner" or anything. Just data and > an conclusion aka "Fazit", the reader has to digest the data and make > up his own mind for _her/his_ own usecase). > > All IIRC, I can dig out and translate the details though! (and it's > month's later followup on what became of that Samsung ;) > > HTH, and please do PM (no need to clog the ML) if you want me to go > digging for the details, > -dnh > > [1] which name escapes me ATM, but tried and tested since 199[0-5] or > so ;) > > [2] https://en.wikipedia.org/wiki/C%27t (that page is sadly woefully > outdated) > I wouldn't mind seeing the info posted to the list myself. I'm interested and I suspect some others may be as well. After all, several people have SSDs now and buying good ones is something we all are interested in. Dale :-) :-) P. S. Sorry for the typo in the subject line. I just noticed I typed it in as SDD instead of SSD. I generally proof the body part but given my age, eyes getting bad, plus just being me, I may need to proof the subject line as well. o_O
Re: [gentoo-user] Re: swaps mounted randomly [not out of the woods yet]
On 2020-03-19 08:17, n952162 wrote: I just discovered that two of my disks have exactly the same UUIDs. A couple of years back, I bought these drives to install RAID on them, but gave up on that. Now, I've decided to do "manual" RAID, but I'm wondering if the fact that the two drives have the same UUID is causing whoever it is who sets up /dev/disk (I'm still trying to find that culprit) is croaking on two different devices with the same UUID. Where is the UUID determined? I'd presumed that it was derived from some characteristics of the drive, determined by the device controller, but now I'm wondering if my initial RAID configuration set some drive-internal variable to be identical? And, how does one /*reset*/ it? Okay, I found this: http://www.sudo-juice.com/how-to-change-the-uuid-of-a-linux-partition/ Any thoughts will be appreciated.
Re: [gentoo-user] Re: swaps mounted randomly [not out of the woods yet]
I just discovered that two of my disks have exactly the same UUIDs. A couple of years back, I bought these drives to install RAID on them, but gave up on that. Now, I've decided to do "manual" RAID, but I'm wondering if the fact that the two drives have the same UUID is causing whoever it is who sets up /dev/disk (I'm still trying to find that culprit) is croaking on two different devices with the same UUID. Where is the UUID determined? I'd presumed that it was derived from some characteristics of the drive, determined by the device controller, but now I'm wondering if my initial RAID configuration set some drive-internal variable to be identical? And, how does one /*reset*/ it? On 2020-03-19 07:08, n952162 wrote: On 2020-03-19 00:12, Ian Zimmerman wrote: On 2020-03-18 22:57, n952162 wrote: Well, some new recognitions ... It turns out that those /dev/disk subdirectories don't necessarily have all the disk devices represented: 1. by-id/ 2. by-partuuid/ 3. by-path/ 4. by-uuid/ There is also by-label, which you can reference from fstab like LABEL=foobar /home ext4 defaults ... If predictability and readability is the goal, I think using labels is the best option, because you have complete control over them, unlike the device IDs. For example: LABEL=my-machine-home-part /home ext4 defaults ... This doesn't solve your underlying timing problem, of course. Just apropos. I had by-label/ in the back of my mind, thinking that was always available as a fall-back, but then forgot about it because it's /not there/! That list above I got with ls(1). I wonder if whatever process it is that builds /dev/disk (/udev/?) is getting aborted, because I can't imagine a reason that /dev/disk/by-uuid/* -> /dev/sda* shouldn't be there.
Re: [gentoo-user] Re: swaps mounted randomly [not out of the woods yet]
On 2020-03-19 00:12, Ian Zimmerman wrote: On 2020-03-18 22:57, n952162 wrote: Well, some new recognitions ... It turns out that those /dev/disk subdirectories don't necessarily have all the disk devices represented: 1. by-id/ 2. by-partuuid/ 3. by-path/ 4. by-uuid/ There is also by-label, which you can reference from fstab like LABEL=foobar /home ext4 defaults ... If predictability and readability is the goal, I think using labels is the best option, because you have complete control over them, unlike the device IDs. For example: LABEL=my-machine-home-part /home ext4 defaults ... This doesn't solve your underlying timing problem, of course. Just apropos. I had by-label/ in the back of my mind, thinking that was always available as a fall-back, but then forgot about it because it's /not there/! That list above I got with ls(1). I wonder if whatever process it is that builds /dev/disk (/udev/?) is getting aborted, because I can't imagine a reason that /dev/disk/by-uuid/* -> /dev/sda* shouldn't be there.
