[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-list
Subject:    Re: imminent /boot problem.
From:       home user <mattisonw () comcast ! net>
Date:       2024-02-24 20:58:31
Message-ID: 53e45abe-8851-44aa-b66e-c8d960f4af6e () comcast ! net
[Download RAW message or body]

On 2/23/24 3:31 PM, Felix Miata wrote:
> Samuel Sieb composed on 2024-02-23 16:48 (UTC-0500):
> 
> > home user wrote:
> 
> > > -bash.4[~]: fdisk -l
> > > Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
> > > Disk model: ST2000DM006-2DM1
> > > Units: sectors of 1 * 512 = 512 bytes
> > > Sector size (logical/physical): 512 bytes / 4096 bytes
> > > I/O size (minimum/optimal): 4096 bytes / 4096 bytes
> > > Disklabel type: dos
> > > Disk identifier: 0xfde8da65
> 
> > > Device     Boot      Start        End    Sectors   Size Id Type
> > > /dev/sda1  *          2048     206847     204800   100M  7 HPFS/NTFS/exFAT
> > > /dev/sda2           206848 1859026943 1858820096 886.4G  7 HPFS/NTFS/exFAT
> > > /dev/sda3       1859026944 1860050943    1024000   500M 83 Linux
> > > /dev/sda4       1860050944 3907029167 2046978224 976.1G  5 Extended
> > > /dev/sda5       1860052992 1876436991   16384000   7.8G 82 Linux swap /
> > > Solaris
> > > /dev/sda6       1876439040 1981296639  104857600    50G 83 Linux
> > > /dev/sda7       1981298688 3907028991 1925730304 918.3G 83 Linux
> 
> > You could take 1GB off your swap partition and move the /boot partition
> > to there.
> 
> That, or any other size that pleases, though if the swap is routinely used for
> hibernating and requires it all, complications grow among the possibilities.
> 
> > If you had live boot capability, I would suggest moving the space up to
> > where /boot is now, but I don't think you can do that while running it.
> 
> With swap off and /boot unmounted, swap could be deleted, boot enlarged to
> whatever size desired, then swap recreated in whatever remains unused. If live
> boot is truly impossible, this process should be easy enough to do by temporarily
> moving the disk to some other computer.
> 
> Another option would be to shrink either sda7 or sda2. With the latter option,
> move sda3 then enlarge. With the former it's more complicate because of the MBR
> partitioning, create a new partition. The new boot at the end of disk would have
> to be created after deleting sda3 if you wish the new to remain a primary, because
> you can't have more primaries than you already have. If you're OK to have the new
> boot be a logical, then it's not an issue. Personally that wouldn't happen, as my
> boot partitions are always ever primary, because that's where I put Grub, not on
> the MBR, where Windows compatible code always stays.
> 
> To be clear, sda4 here is a special case. It defines a location within which
> logical partitions live, but it doesn't need to be manually or consciously taken
> into account for these processes. Better partitioning tools automatically recreate
> it as and if required to fit any legal group of logicals. Therefore, adjusting it
> shouldn't require it be given any thought beyond the fact that it consumes a
> primary partition table entry. It can be pretended to not exist notwithstanding
> existence of its partition table entry.

No other computer.
No live boot.  Tried making one multiple times with multiple sticks and multiple \
ports.  Even a local youngish professional programmer (specializing in embedded and \
micro) could not figure it out.

I'm heavily leaning on being satisfied with space recovered by deleting one old \
                kernel and limiting the system to one old kernel henceforth.
--
_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue


[prev in list] [next in list] [prev in thread] [next in thread]